Service
Mobile app development
Apps that keep working when the network does not.
For teams whose users are not at a desk - field staff, site supervisors, delivery teams, sales on the road - and for customer-facing apps where the first minute decides whether it is kept. The engineering that matters here is offline behaviour and sync, not the screens.
The decision
When this is the right call.
Most mobile apps are demonstrated on office wifi and used on a patchy 4G connection at a site gate. That gap is where they fail. An app that assumes connectivity will be blamed for losing data it never received, and once field staff stop trusting it they go back to paper - which is the outcome the project was funded to prevent.
Sync is the hard part and it is usually the part that was scoped in a sentence. What happens when two people edit the same record offline, when a phone comes back online after three days, when the server has since changed the rules. These are design decisions, and if nobody makes them the app makes them badly by default.
We decide the conflict model before building, make offline the normal case rather than the error case, and test on a throttled connection rather than on wifi. The screens are the easy half.
What you get
What the work covers.
Offline-first data
Local storage as the source of truth for the session, with a queue that survives the app being killed and a conflict rule chosen deliberately.
Sync you can inspect
Sync state visible to the user and to support, so 'it did not save' becomes a question with an answer.
Native or cross-platform
Kotlin and Swift where hardware, background work or performance demand it; a shared codebase where the app is mostly screens and the saving is real.
Background work that survives
Scheduled sync and upload that keeps working under Android's battery restrictions, tested on the vendor skins that break it.
Authentication that fails safely
Token expiry handled properly - an expired session signs the user out rather than retrying a dead request forever.
Release engineering
Signed builds, staged rollout, crash reporting and in-app update prompts, so a bad release can be stopped.
Stack
What we build it with.
Chosen per project. Nothing here is applied by default, and the team who will maintain it counts as much as the problem.
Android
Kotlin with Jetpack Compose, Room for local storage, WorkManager for background sync.
iOS
Swift with SwiftUI, and the platform's own persistence rather than a bridged layer.
Cross-platform
React Native or Flutter where the app is screen-led and one codebase genuinely halves the work.
Backend
The same API your web platform uses, versioned so an old app in the field keeps working.
Distribution
Play Store and App Store, or managed enterprise distribution where the app is internal.
Comparison
Cross-platform vs native.
The first real decision on a mobile project. We build both, so this table is the actual reasoning rather than a pitch for whichever we prefer.
| Aspect | Cross-platform | Native |
|---|---|---|
| Best fit | Forms, lists, sync - apps that are mostly screens over an API | Camera, background location, Bluetooth or sustained performance |
| Cost for two platforms | Roughly one build plus platform-specific polish | Close to two builds, and two codebases to maintain afterwards |
| Offline and sync | Entirely achievable; the sync design matters far more than the framework | Same - this is a data-model decision, not a platform one |
| Hardware and OS features | Fine for the common ones; anything unusual needs a native module anyway | Direct access, and no bridge to debug when a vendor changes behaviour |
| Background work under Android battery rules | Workable, but the aggressive vendor skins need testing either way | Easier to control, and easier to diagnose when a device kills the process |
| Long-term maintenance | One codebase, plus a framework that has its own upgrade cycle | Two codebases, but each on the platform's own well-documented path |
How it runs
From first conversation to live.
Indicative for work of this shape. The pilot is not optional — nothing is switched over until the people using it say it holds.
- 1 week
Discovery
We decide the conflict model and what happens offline before anything is designed. Retrofitting either is close to a rewrite.
- 4-8 weeks
Core build
Local storage, the sync queue and the main task path first, tested on a throttled connection rather than office wifi.
- 2-3 weeks
Field pilot
Real users on their own phones - including the cheap ones - while the paper process continues. This is where offline assumptions get corrected.
- 1-2 weeks
Release
Store submission or managed distribution, staged rollout, crash reporting, and an in-app update prompt so a bad build can be stopped.
After launch
What changes.
- Field staff keep using it after the second month, which is the only real measure of a field app.
- ‘It did not save’ becomes a question with an answer, because sync state is visible to the user and to support.
- A phone that has been offline for three days reconciles without anyone losing work.
- An old version still in the field keeps working, because the API is versioned rather than assumed current.
Described qualitatively on purpose. We do not publish percentage improvements we cannot attribute to a named client with their agreement.
Questions
Common questions.
Native or cross-platform - which should we choose?
If the app is mostly forms, lists and sync, cross-platform is usually the right economics. If it depends on camera, background location, Bluetooth hardware or sustained performance, native repays the extra cost. We make the recommendation from what the app actually does, not from a house preference.
Will it work without internet?
That is designed in from the start where the use case needs it. Records are written locally, queued, and synced when a connection returns, with the queue surviving the app being closed or the phone restarting.
Do you publish to the stores for us?
Yes, including store listings, screenshots and review responses. The accounts stay in your name - we never hold a client's store account.
Can it work alongside our existing system?
Yes. Most mobile apps we build are a field-facing surface over a system that already exists, rather than a separate product with its own data.
Can you take over an app someone else built?
Usually. We start with a short review of the codebase, the release setup and the store accounts, and come back with what it would take. If the honest answer is that a rewrite is cheaper than the handover, we will say so and show the reasoning.
Do we need an app at all, or would a mobile site do?
A responsive site handles a great deal and costs far less. An app earns its cost when you need offline capability, hardware access, background work or push notifications. If none of those apply, we will point you at the cheaper answer.