Mobile Application Development
An app your users install, rate and update — shipped through review queues and onto devices you don’t control.
Plan the app launch ↗Should we build native or cross-platform?
A mobile application is code that runs on hardware you have no access to, distributed by two companies with their own opinions about it. That reframing matters more than the language choice: the hard parts are patchy connectivity, four-year-old devices, background limits, permissions prompts and a release you can’t hotfix in ten minutes.
For most products a single React Native or Flutter codebase is the right economics — two stores, one team, one set of business logic. We recommend fully native when the app leans on the camera, Bluetooth, background location or heavy on-device processing, and we’ll say so at scoping rather than discovering it in week eleven.
What a mobile build includes
Device and OS floor
We agree the oldest OS versions and cheapest test devices in scope. Supporting one more OS generation is measurable work, so it gets decided, not assumed.
Offline behaviour
What the app does on a train, in a lift and on 200ms of signal — local cache, queued writes and conflict rules defined per screen.
Store submission
Listings, screenshots, privacy declarations, data-use disclosures and the review notes that stop a reviewer bouncing you for something avoidable.
Push and deep links
Notifications that respect permission state, plus links that open the right screen whether or not the app is installed.
Staged rollout
Phased release to 1%, then 10%, then everyone, with crash rates watched at each gate and a rollback path ready.
Real-device test pass
Manual passes on a small physical device set — including one old, slow Android — because simulators hide the bugs that get you one-star reviews.
How a mobile build runs
Decide the platform bet
A short discovery on device features, offline needs and team skills, ending in a native-versus-cross-platform recommendation with the reasoning written down.
Design to platform grain
Flows that follow iOS and Android conventions where users expect them, and diverge only where there’s a reason worth explaining.
Build with internal builds
TestFlight and Play internal testing from week two, so stakeholders are holding the app on their own phone long before launch.
Submit early, deliberately
We put a build through review well before it needs to ship, so the first rejection costs a week of buffer rather than your launch date.
Roll out and watch
Phased release with crash and ANR dashboards open, then a stabilisation window for the issues only 10,000 real devices produce.
Mobile Application Development FAQ
Cross-platform builds typically run $35k–$110k; fully native iOS plus Android is roughly 1.6 to 1.8 times that because you maintain two codebases forever, not just once. Offline sync and background work are the two features that most often double an estimate.
The tools we build with
We optimise for one shared codebase and native escape hatches, so the 90% that’s ordinary stays cheap and the 10% that touches hardware stays possible.
App layer
Backend & sync
Device services
Ship & observe
Related work
Related reading
Shipping to the stores this year?
Tell us what the app has to do on a bad connection. We’ll come back with a platform recommendation, a scoped build and a realistic first submission date.





