Overview
Mobile punishes assumptions. Your users are on the move, on patchy networks, watching their battery, and you cannot hotfix a mistake — a fix waits for store review. We build with that reality in front of us rather than discovering it after launch.
Native or cross-platform
We make this decision on requirements, not preference. Native (Kotlin, Swift) when the app is performance-critical, leans on platform capabilities, or is your primary product. Flutter for one codebase with a consistent custom-designed UI on both platforms. React Native when you already have a React team and code worth sharing.
For a typical business app, cross-platform usually wins on economics. We recommend native without hesitation when the requirements call for it, and we tell you which requirement drove the answer. Read more in our mobile technology notes.
Offline first
The difference between an app that feels solid and one that feels fragile is almost always how it behaves without a signal. We use a local database as the source of truth for the UI, a sync queue for pending changes, deliberate conflict resolution, and designed states for offline, slow and failed — not a spinner that never resolves.
Performance, battery and size
- Cold start measured and kept short, with heavy work off the startup path.
- Lists virtualised and images cached at display size, so scrolling stays smooth and memory stays flat.
- Network requests batched — frequent small requests drain batteries fast.
- Background work scheduled through the platform's own schedulers rather than fighting power management.
- Install size kept down, because it measurably affects install conversion.
Security and release
Credentials in Keychain or Keystore, never in preferences files. No secrets in the binary. Authorisation enforced server-side. On release we handle privacy manifests, data-safety declarations, permission strings and account-deletion requirements, then roll out in stages with crash monitoring so a bad build reaches a fraction of users rather than all of them.
What you get
- A platform recommendation with the reasoning written down.
- An app that works offline and syncs reliably on reconnect.
- Measured cold start, frame rate and install size.
- Store submission handled, with staged rollout and crash reporting.
- A plan for the annual OS updates, so the app does not quietly rot.
Build for the lift with no signal and 8% battery. Everything after that is easier.