Loading page…
An AI assistant is planned. Until it is genuinely useful we would rather point you at the page that actually answers your question.
A mobile app is software installed on a device, distributed through Apple's App Store or Google Play. That distribution channel is the part that surprises teams: it introduces review queues, platform policies and a permanent versioning problem, because users who never update stay on old code indefinitely.
The build itself splits into three viable approaches. Cross-platform frameworks like Flutter or React Native share one codebase across both platforms. Native development uses Swift for iOS and Kotlin for Android separately. A progressive web app skips the stores entirely and runs in the browser.
Some capabilities only exist on a device — push notifications that reliably arrive, camera and sensor access, background location, offline operation in places with no signal. If your product depends on any of those, the browser is not a substitute.
There is also a retention argument. An icon on a home screen gets opened. A bookmarked URL generally does not. For products that depend on habitual daily use, that difference in re-engagement is usually the whole business case.
The counter-argument matters too, and we will make it if it applies: if your app is mostly forms and lists that could run in a browser, the store overhead may cost more than it returns.
Our approach
We decide cross-platform versus native early, in writing, with the reasoning recorded. Flutter suits most products — one codebase, consistent behaviour, near-native performance. Native becomes correct when you need platform-specific hardware access, heavy graphics, or deep integration with system features that lag behind in cross-platform bindings.
Offline behaviour is designed, not retrofitted. Mobile networks fail constantly — lifts, trains, basements, rural areas. We decide up front which actions must work offline, how conflicts resolve when the device reconnects, and what the interface shows while data is stale.
Release process is part of the build, not an afterthought. Signing, provisioning, store metadata, staged rollout and crash reporting are configured before the first submission, because a rejected build late in a project can cost a week.
Capabilities
Flutter or React Native for one codebase across iOS and Android, with platform-specific behaviour where it genuinely differs.
Swift and Kotlin where a feature needs direct platform access — Bluetooth, background processing, biometrics.
Local storage, queued mutations and conflict resolution so the app stays usable without a connection.
Segmented, permission-respectful messaging through FCM and APNs, with delivery tracked rather than assumed.
Store subscriptions, receipt validation on the server, and the restore-purchase flows reviewers specifically check.
Provisioning, signing, listings, review responses and phased rollout — handled rather than handed back to you.
Stack
Process
Cross-platform or native, argued against your actual feature list and recorded with the reasoning.
Flows designed against platform conventions rather than a desktop layout compressed onto a phone.
Navigation, state, data layer and offline behaviour established before feature work spreads across the codebase.
Real hardware across a range of sizes and OS versions, including older mid-range Android devices where problems actually appear.
Listings, screenshots, privacy declarations and review notes prepared before submission rather than during it.
Staged rollout with crash monitoring, so a bad build reaches a small percentage of users rather than all of them.
Use cases
Staff working away from a desk — inspections, deliveries, service calls — where offline capture and sync are mandatory.
Products depending on habitual use, where push notifications and home-screen presence drive the retention numbers.
A mobile surface for an existing web platform, exposing the subset of functionality that genuinely benefits from being on a phone.
Apps pairing with hardware over Bluetooth or local network, where the transport layer is the hard part.
Choosing an approach
This decision affects cost, timeline and what the product can do. It is worth making deliberately rather than by default.
| Approach | Choose when | Cost of the choice |
|---|---|---|
| Flutter / React Native | Standard product features, both platforms needed, budget matters | Occasional native bridging work; new OS features can lag |
| Native (Swift/Kotlin) | Heavy graphics, deep hardware use, or platform-specific UX is central | Roughly two codebases to build and maintain |
| Progressive web app | Mostly forms and content; no store presence required | Limited notifications on iOS, no store discovery, weaker retention |
Outcomes
FAQ
Related