Offline capture verified on real hardware across eleven failure scenarios
The app's offline capture work went onto real phones and watches for a structured round of failure testing. Eleven scenarios, all passing: recording a take with no signal at all, holding that record for minutes before it reaches the server, force-quitting the app mid-capture, locking the phone the instant after tapping, and publishing to multiple audiences while completely disconnected. Every one of them kept the record and kept its true capture time. This mattered because a film set is the worst case for connectivity, and none of it can be faked in a simulator. A crew member taps a button and immediately pockets the phone; the app gets killed to free memory; a whole stretch of the day happens in a dead zone. The round confirmed that what the operator recorded is what gets stored, stamped with when it actually happened rather than when the network finally came back.
Share This Ship
🔬 Shipped: Offline capture verified on real hardware across eleven failure scenarios 🧵
The app's offline capture work went onto real phones and watches for a structured round of failure testing.
Eleven scenarios, all passing: recording a take with no signal at all, holding that record for minutes before it reaches the server, force-quitting the app mid-capture, locking the phone the instant after tapping, and publishing to multiple audiences while completely disconnected.
Every one of them kept the record and kept its true capture time. This mattered because a film set is the worst case for connectivity, and none of it can be faked in a simulator.
A crew member taps a button and immediately pockets the phone; the app gets killed to free memory; a whole stretch of the day happens in a dead zone.
The round confirmed that what the operator recorded is what gets stored, stamped with when it actually happened rather than when the network finally came back.
Follow the build → build-log-five.vercel.app #mobile #reliability #offline #buildinpublic