Mobile app development
iOS, Android and cross-platform — designed for the devices and connections your users actually have, not the flagship on the developer's desk.
A mobile app is only partly the thing on the phone. The visible app is usually a third of the work; the rest is the backend it talks to, the sync logic that copes with a dropped connection, the authentication, the push infrastructure, and the release process that gets updates past two app stores.
That's why apps quoted purely as screens overrun. A login screen is an afternoon; login that handles token refresh, device changes, biometric unlock and a forgotten password across two platforms is a fortnight.
We build for real conditions — mid-tier devices, intermittent connectivity, and users who won't wait for a slow first load. Offline tolerance is designed in, not bolted on after the first complaint.
The first real decision, and the one that most affects cost. Here's how we choose.
| Native (Swift / Kotlin) | Cross-platform (React Native / Flutter) | Progressive web app | |
|---|---|---|---|
| Best when | Heavy device integration, or performance is the product | Standard app features, two platforms, one budget | Reach matters more than device features |
| Relative cost | Highest — two codebases | Moderate — one codebase, some platform work | Lowest — it's a website |
| Device access | Everything, immediately | Almost everything; new OS features may lag | Limited — no deep hardware access |
| App store presence | Yes | Yes | No (installable, but not listed) |
| Update speed | Store review each time | Store review, plus over-the-air for JS changes | Instant — you control the deploy |
| Typical fit | AR, video processing, complex offline sync | Most business and consumer apps | Internal tools, low-frequency use |
We recommend cross-platform for most business apps and say so plainly — building the same app twice is rarely justified by the result.
Apps that people use to do a job, more often than apps people browse.
Field and operations apps
For staff working away from a desk — job lists, capture, signatures, photos, barcode scanning — designed to keep working when the signal doesn't.
Customer apps
Accounts, orders, bookings, tracking and support in the place customers already look. Usually the mobile face of a portal we've also built.
Commerce apps
Browsing, cart and checkout with the payment methods your market expects, plus push notifications tied to real order events rather than marketing blasts.
Backend & APIs
The server side of the app — data model, API, auth, push and the admin interface your team runs it from. Built together with the app, by the same team.
App modernisation
Rescuing apps stuck on unsupported frameworks or abandoned by a previous team, including reclaiming store listings and signing keys.
Release & store management
Store listings, review submissions, staged rollouts, crash monitoring and the ongoing OS-upgrade work that keeps an app from silently breaking.
Every one of these is scoped explicitly in our estimates, because leaving them implicit is how app projects double.
Offline and sync
Deciding what works without a connection, what queues, and what happens when two devices edited the same record. This is the single most underestimated area in app work.
Authentication across devices
Token refresh, biometric unlock, session expiry, device changes and account recovery. Simple on the happy path, and a long tail of cases elsewhere.
Push notifications
Two platforms, two delivery services, permission flows, deep links into the right screen, and the difference between a useful alert and an uninstall.
Store review and releases
Apple and Google both reject builds for reasons that aren't in your code. We budget review cycles into the plan instead of treating rejection as a surprise.
Five stages. You see the app on a real device from the third one.
- 01
Scope
What the app must do, who uses it in what conditions, and which platforms genuinely need covering. We recommend a build approach and size the work.
- 02
Design
Flows first, then screens, following each platform's conventions rather than forcing one design onto both. Clickable prototype before code.
- 03
Build
Two-week iterations with a test build on your device at the end of each. Backend and app develop together, so integration isn't a phase at the end.
- 04
Beta
TestFlight and Play internal testing with real users on real devices. Crash reporting and analytics wired up before launch, not after.
- 05
Launch & maintain
Store submission, staged rollout, then the ongoing work: OS updates, SDK deprecations, and the changes that come out of actual usage.
Apps need maintenance in a way websites don't — both platforms ship breaking OS changes annually. We'll be explicit about that ongoing cost before you start.
For most business and consumer apps, cross-platform with React Native or Flutter gives you both platforms for close to the cost of one, with no difference users would notice. Go native when the app depends on heavy device integration, sustained high performance, or platform features the moment they ship. We'll recommend one in the scoping session and explain the trade-off rather than defaulting to whichever is more billable.
Start a project
Who uses it, where, and on what. We'll come back with a build approach, a rough cost, and the parts that will be expensive.
- Reply within one business day
- Free scoping session, no obligation
- You keep the scope document either way