Overview
Mobile is unforgiving in ways the web is not. A user on the move has intermittent connectivity, a battery they are watching, limited storage and no patience. And you cannot hotfix a mistake — a fix goes through store review before anyone gets it. That changes how carefully you build.
Native or cross-platform
This decision is usually made on ideology. It should be made on requirements.
Native — Kotlin and Swift
The right choice when the app is performance-critical, leans heavily on platform capabilities, or is the primary product. Full access to new OS features on release day, best-in-class performance, the richest tooling, and no dependency on a bridging framework's release schedule. The cost is two codebases and two skill sets.
Flutter
Excellent when you want one codebase with a consistent, custom-designed UI on both platforms. It renders its own widgets, so the design is identical everywhere — which is a strength for branded interfaces and a weakness when you want the app to feel natively platform-specific. Performance is genuinely good.
React Native
Strongest where you already have a React team and web code worth sharing. It renders real native components, so the app feels native, and the new architecture has closed much of the historical performance gap.
Our default recommendation for a typical business app is cross-platform, because the economics are usually decisive. We recommend native without hesitation when the requirements call for it, and we will explain which requirement drove the answer.
Offline first
Assume the network is unavailable and design forward from there. This is the single biggest difference between an app that feels solid and one that feels fragile.
- A local database — Room, Core Data, SQLite or Realm — as the source of truth for the UI, so the interface never waits on the network to render.
- A sync layer with a queue of pending changes, retried when connectivity returns.
- Conflict resolution decided deliberately and explained to the user where it matters, rather than last-write-wins by accident.
- Optimistic updates with a clear, recoverable path when a write eventually fails.
- Explicit design for the offline, slow and failed states — not a spinner that never resolves.
Performance and battery
- Cold start measured and kept short; heavy initialisation deferred off the startup path.
- Lists virtualised and images cached at display size, so scrolling stays at 60fps and memory stays flat.
- Network requests batched and coalesced. Frequent small requests are one of the fastest ways to drain a battery.
- Background work scheduled through WorkManager or BGTaskScheduler so the OS can batch it, rather than fighting the platform's power management.
- Location and sensors used at the lowest accuracy and frequency the feature actually needs.
- App size kept down with resource shrinking and on-demand assets — install size measurably affects conversion.
Security
- Credentials and tokens in the Keychain or Android Keystore, never in shared preferences or plain files.
- Certificate pinning where the threat model justifies it.
- No secrets in the binary. A mobile app is a client in the attacker's hands; anything shipped in it is public.
- Biometric authentication for sensitive actions, with a proper fallback.
- Sensitive data encrypted at rest, and excluded from screenshots and backups where appropriate.
- Authorisation enforced on the server, always. Client-side checks are user experience, not security.
Release and store review
Rejections are usually avoidable and always expensive in time. We handle privacy manifests and data-safety declarations accurately, make sure account deletion exists where the stores now require it, get permission usage strings right, and prepare store listings properly. Releases go out through TestFlight and Play internal testing tracks first, then staged rollout with crash monitoring, so a bad build reaches 5% of users rather than all of them.
After launch
Crash reporting and analytics from day one, because you cannot debug a phone you do not have. OS updates are planned work every year — each major Android and iOS release brings behaviour changes, permission changes and deprecations, and an app left untouched for two years becomes expensive to revive.
What you get
- A platform recommendation with the reasoning written down.
- An app that works offline and syncs reliably when it reconnects.
- Measured cold start, frame rate and install size.
- Secure credential storage and server-side authorisation.
- Store submission handled, with staged rollout and crash monitoring.
Design for the lift with no signal and 8% battery. Everything else is easier than that.