Mobile App Development
iOS and Android apps that feel native, pass review the first time, and keep shipping after v1.
- Cold start on mid-range devices
- <1.5sCold start on mid-range devices
- First-submission approval rate
- 100%First-submission approval rate
- Crash-free session rate
- 99.7%Crash-free session rate
How we approach this
We build mobile products for teams who need one codebase and two first-class platforms. That means native-feeling navigation and gestures, offline-first data, push notifications people do not mute, and a release pipeline that gets a build in front of testers the same day you write the code.
Cross-platform, without the tell
React Native and Flutter both produce apps indistinguishable from native when they are built with care, and obviously cross-platform when they are not. The difference is in the details: platform-correct navigation transitions, respecting the iOS back-swipe and the Android hardware back button, haptics that fire on the right events, and typography that follows each platform's dynamic type settings.
We budget explicitly for that polish rather than treating it as a nice-to-have, because it is the entire difference between an app that feels like a product and one that feels like a website in a shell.
Offline is the default assumption
Phones lose connectivity constantly — in lifts, on trains, in hospital basements. An app that shows a spinner whenever the network drops will be deleted. We design the data layer around a local store that the interface reads from, with sync and conflict resolution happening behind it.
That decision has to be made at the start. Retrofitting offline support onto an app built around direct API calls means rewriting nearly every screen, which is why we treat it as an architectural question rather than a feature.
Store review, planned for rather than hoped for
Rejections are almost always predictable: account deletion missing, permission prompts without a clear justification string, subscription terms not surfaced before purchase, sign-in options that fall foul of Apple's rules. We work through the current review guidelines as a checklist before the first submission.
We also handle the submission itself — store listings, screenshots at every required size, privacy nutrition labels and data-safety declarations — and we stay on the account through the first few releases so a rejection does not become your problem to decode.
Shipping does not stop at launch
Mobile release cycles are slower than web, so the pipeline matters more. We set up automated builds, TestFlight and Play internal testing distribution, staged rollouts and over-the-air updates for the JavaScript layer where the platform allows it.
Crash reporting and analytics are wired in before launch, not after, so when something breaks on a specific Android device you have the stack trace rather than a one-star review to work from.
What you get
- Cross-platform iOS and Android builds
- Offline-first data and sync strategy
- Push notifications and deep linking
- In-app purchases and subscription billing
- App Store and Play Store submission
- Crash reporting, analytics and release automation
Is this the right service for you?
We would rather tell you no early than take on work we would do badly. Here is where this service earns its keep, and where it doesn't.
A good fit if
- Your users need the product in their hand, not in a browser tab
- You need push notifications, offline access, camera or location
- You want iOS and Android without funding two separate teams
- You have an existing app that has stalled or been abandoned
Probably not if
- A web app would genuinely serve your users better
- You need heavy real-time 3D or console-grade graphics
- You cannot commit to maintenance — apps decay faster than websites
How a mobile apps project runs
- 01
Define the core loop
One sentence describing what a user opens the app to do. Everything in v1 either serves that loop or waits for v2.
- 02
Prototype on device
An interactive build on a real phone in the first fortnight. Gesture and navigation decisions cannot be judged in a browser preview.
- 03
Build with testers watching
TestFlight and Play internal builds from sprint one. Your team is using the app throughout, not reviewing screenshots of it.
- 04
Submit and stage
Store assets, privacy declarations, review-guideline checks, then a staged rollout so a bad build reaches 1% of users rather than all of them.
Ways to work with us
Starting prices, not quotes. You get a fixed number in writing after discovery — these are here so you can tell early whether we're in your range.
App rescue
An audit of an existing app — crash rates, review blockers, dependency debt and build pipeline — with a costed plan to get it releasable again.
- From
- $9,000
- Typical timeline
- 2–3 weeks
- Best for
- Apps that have stopped shipping
First release
A focused app on both platforms covering one core loop, submitted to both stores, with analytics and crash reporting live from day one.
- From
- $55,000
- Typical timeline
- 12–16 weeks
- Best for
- Getting a real product into users' hands
App + backend
The mobile apps plus the API, admin surface and infrastructure behind them, built together so the sync model and the data model agree.
- From
- $120,000
- Typical timeline
- 5–7 months
- Best for
- Products with no existing backend
Mobile Apps questions
The ones that come up on nearly every call for this service.
- React Native or Flutter — how do you choose?
- Mostly on your team. If you already have React and TypeScript engineers, React Native means they can contribute and eventually own it. Flutter tends to win when the app is graphically ambitious or when there is no existing web team to inherit it. We will recommend one and explain the reasoning; the decision is not close enough to agonise over in most projects.
- Do we need separate iOS and Android designs?
- No, but you need platform-aware ones. The layout and visual language stay shared; navigation patterns, system fonts, date pickers, share sheets and back behaviour follow each platform's conventions. Shipping an iOS-shaped app on Android is one of the fastest ways to attract poor reviews.
- How long does App Store review take?
- Typically 24 to 48 hours once your account is established, though a first submission from a new developer account can take longer. We build the review guidelines into a pre-submission checklist, which is why we have not had a first-submission rejection — but nobody can promise Apple's outcome, so we plan the launch date with a buffer.
- What does maintenance actually involve?
- Apple and Google both ship annual OS releases that break things, and both periodically raise the minimum SDK version you must target to stay in the store. Realistically an app needs a few days of attention each quarter plus a larger update once a year. We can hold that on a light retainer or hand it to your team with the runbook.
- Can you take over an app another agency built?
- Usually. We start with an audit covering dependency versions, crash rates, build reproducibility and store account access — that last one is the most common blocker, and it is worth confirming you actually control your developer accounts before anything else.
Need mobile apps help?
Send us the brief, the half-written brief, or just the problem. We'll come back with what we'd do and what it costs.