We’re continuing to make progress and wanted to share an update on where things stand.

Mobile App Updates

Over the past six weeks, we’ve been forced to upgrade our mobile app to a newer version of React Native due to app store requirements. Without this upgrade, we would have been blocked from publishing any new updates to the iOS and Android stores. Unfortunately, this task — which we were told would take about 10 days — ended up taking nearly 6 weeks and consumed a significant amount of development time, which temporarily slowed down progress on feature enhancements and bug fixes.

To make matters worse, after completing the upgrade, we discovered that some features we had previously built and tested over the past few months didn’t carry over correctly. Since then, the team has been going through everything carefully to identify and reimplement anything that was missing or broken after the update. While we haven’t seen new app progress in the last few weeks, we expect that to change and be reflected in the next update.

Safe Progress & Challenges

The OTA issue still has not been fully resolved. As mentioned previously, we’ve decided to implement a rollback mechanism as a temporary solution for any failed OTAs. If an OTA update fails, the safe will attempt to reinstall several times – and if it still fails, instead of the safe ending up bricked, the system will automatically roll back to the previous working version. We’re hoping to have this implemented by the next update.

Aside from the rollback, until we can dedicate more time to digging into the root OTA issue, we’re putting the remainder of the OTA work on the back burner. As you all know, we’ve already spent months troubleshooting the OTA, and while we have resolved many related bugs, the core cause is still unclear. As long as the rollback works, then we’ll revisit and dig into the root cause of the OTA once we have more resources.

Furthermore, we believe we’ve successfully removed all of the Chinese malicious software that was embedded in our firmware. Since the firmware files total over 200gb, there’s always a chance something slipped through, but for now, everything looks clean and we’ll continue monitoring just in case.

Since the last update, we had to temporarily pause the work on the OTA rollback implementation to focus on some more urgent priorities. Here’s what we tackled;

• Factory Testing App Enhancements
  We’ve been making updates and changes to our internal testing applications. These apps allow the factory employee to individually test each piece of hardware to ensure it’s working correctly with the system after. This is a critical step to make sure your safes are fully functional before they leave the factory. Although each electronic component is tested once we receive it, we test it again after the electronics are assembled into the safe using this application to ensure that everything is properly connected and communicating with the system.
  
  
  
• “Door Left Open” Bug Fixes
  When the door is left open, a message appears on the safe to alert the user. We found several bugs in how this flow behaved and we have fixed them to ensure it now functions reliably.
  
  
  
• Tamper-Triggered Lockdown Fixes
  After a new safe is set up, lockdown activation via tampering is enabled by default. This means if someone moves the safe, lockdown will trigger automatically. We tested different default settings and decided that the middle sensitivity level would work best for most users, so we’ve selected that as the default. If you want to change your sensitivity level, you can — either in the settings under Security or from the mobile app. Users can choose between three preset sensitivity options or disable the feature entirely. Furthermore, we discovered that, in some cases, lockdown wasn’t activating specifically from tamper events — we believe we’ve resolved the bugs affecting tamper-triggered lockdown.
  
  
  
• Mobile App Tamper Sync
  In addition to changing the tamper sensitivity level directly on the safe, users can also adjust it from the mobile app. Sensitivity levels are labeled as 1 for Low, 2 for Medium, and 3 for High. We discovered that changes made through the app weren’t syncing correctly to the safe. This issue took several days of debugging across our APIs and Safe OS, but it’s now fully resolved. Now, if you change the level from the mobile app, the safe will update — and vice versa.
  
  
  
• Crash Notification Flow
  From time to time, certain actions may cause the system to crash due to bugs or poorly written code — this is normal with any complex software. As we continue to identify and fix these bugs, those crashes stop occurring. However, if there are bugs we haven’t caught, other users may still encounter them. To handle this better, if a crash occurs, we’ve implemented a crash notification popup that displays and lets the user know the system is restarting — without any security gaps. This took a while to build out, but it’s worth it, as it will give users a smoother experience if anything goes wrong. Once you receive your safes, if at any time you do encounter this popup, please just email us and let us know what you did that caused the system to crash so we can investigate and fix the issue — ensuring that you and others don’t encounter it.
  
  
  
• Camera Stability Fixes
  We encountered an issue where the camera feed stopped loading. While it wasn’t triggered by any specific action, it appeared to be widespread across units. After identifying the root cause in our API and AWS-side logic, we made the necessary fixes to restore functionality both on the AWS side and on the system side. Since our fix, all cameras have remained stable and fully operational.
  
  We also implemented timeout handling to address cases where the camera feed continued running long after a user disconnected from the live stream. These changes not only fixed the core issue but also helped improve overall camera performance and resource efficiency. We believe this issue is now fully resolved and should not return.

Anything else we should be aware of? Yes, at this stage, we believe the earliest we will see a mass production run will be around August/September. We are still actively seeking outside investment to sell part of the company, which would help support mass production and offset some of the losses we’ve absorbed throughout development.

We kindly request your cooperation in refraining from sending emails requesting delivery dates and any negative messages, as we no longer plan to respond to those individual inquiries. Rest assured, we're actively working to expedite the process and will provide updates as soon as they become available. Your understanding and patience during this time is greatly appreciated.

Sorry for the delay. Thank you for your unwavering support, your understanding and patience during this time are greatly appreciated.

TLDR - SUMMARY

• Rollback implementation is temporarily paused while we address more urgent fixes.
• After rollback is implemented, full OTA debugging will be on hold until we have more resources. (In the meantime, rollback would ensure your safe won’t brick.)
• Firmware has been cleaned of Chinese malicious software; monitoring continues.
• Testing apps improved to ensure all components are validated before safes ship.
• “Door Left Open” bugs fixed for better reliability.
• Lockdown tamper detection bugs fixed; by default, it is set to medium sensitivity.
• Sensitivity level sync between safe and mobile app is now fixed.
• Crash recovery popup added to improve user experience and help us fix issues faster.
• Camera feed issue fixed with improvements to AWS logic, system handling, and resource efficiency.