Fig. 19 — Mobile apps
Mobile development
An app on a phone, in both stores, built once. The part nobody warns you about is not the building — it is everything between a finished build and a customer installing it.
One codebase, two stores
We build with React Native, so iOS and Android share the work instead of doubling it. That is the right trade when the product is broadly the same on both platforms, and the wrong one when it lives on heavy graphics or deep platform integration — we will tell you which case you are in before the budget is committed, including when the answer costs us the work.
Release is a phase, not a button
Shipping to a store is its own project: signing, provisioning, review, staged rollout, and a bug that now takes days to replace rather than minutes. We treat it as part of delivery, because a build that cannot be released on demand is not finished.
- Store accounts, certificates and provisioning set up properly rather than borrowed
- Release builds automated, so a submission is repeatable instead of remembered
- Staged rollout and crash reporting from the first version, not after the first bad review
- A path to fix without waiting for review, for the changes that can live server-side
The app is half of it
Most of what breaks in a mobile product happens between the app and the API — and those bugs are hardest to fix when two companies own the two halves. We build the backend as well, share types across both, and change them together.