Mobile apps
The hard part of a phone app is rarely the screens. It is that the device is sometimes offline, the operating system can kill you mid-task, and shipping a fix takes days rather than minutes.
Native or cross-platform is the first question and the one most often answered by habit. The honest version is a trade: React Native and Flutter give you one team and one codebase, and they are entirely adequate for the large majority of products. Native earns its cost when the app leans hard on the platform — sustained background work, tight camera or sensor access, widgets and system integrations, or animation that has to hold sixty frames under load. Choosing native for a form-and-list app is paying twice for nothing.
Then there is the network, which on a phone is a fact rather than an assumption. Connections drop in lifts and basements, requests are retried on a train, and the app is suspended by the operating system halfway through an upload. An app that treats the server as always reachable does not fail loudly; it produces a duplicate order, a lost draft, or a spinner that never resolves. Local state that survives a cold start, idempotent writes, and a queue that drains when signal returns are not advanced features. They are what separates an app from a website in a frame.
Release is the third constraint, and it changes how you build. A web bug is fixed in minutes; a mobile bug is fixed whenever review approves it and whenever users update, which for some of them is never. So anything that might need changing quickly — copy, thresholds, feature flags, endpoints — is served rather than compiled, and the oldest version you still support is a decision you make deliberately instead of discovering from a crash report.
How we work
- The platform decision is written down with its reasons before any code, because it is the one choice that is expensive to revisit.
- Offline behaviour is designed in the first week, not retrofitted after the first complaint about a duplicated order.
- Anything that might need to change without a release is served from the backend, so a wrong number is a config edit rather than a two-week review cycle.
What this includes
Pick what you need and send it over.
Questions
- Do we need separate iOS and Android teams?
- Usually not. One cross-platform codebase covers most products, and where a single screen genuinely needs native behaviour it can be written natively and embedded. Two full teams is the right answer far less often than it is the chosen one.
- How long does app review take?
- Usually a day or two once the account and metadata are in order, which is why we set those up early rather than on the day you want to launch. Rejections are common on the first submission and are almost always about account deletion, permissions copy or payment rules — all avoidable if they are read before the build rather than after.