Service Mobile apps
An app that holds up on a real phone, in a real hand.
Native where it matters, cross-platform where it pays. We've built iOS and Android apps for clients across the US, UK and Europe — including apps that talk to hardware over Bluetooth — and taken them the whole way: first screen, push, offline behaviour, review, release.
01 What we build
Six shapes this usually takes.
Native iOS
Swift and SwiftUI, built the way the platform expects — so gestures, navigation, dark mode and accessibility work without being reinvented.
Native Android
Kotlin and Jetpack Compose, tested across the screen sizes and OS versions your actual users are on, not just the newest Pixel.
One codebase, both stores
React Native when the app is mostly screens, forms and data. Half the surface area to maintain, with native modules dropped in where it needs them.
Companion apps for hardware
Bluetooth LE pairing, live telemetry, firmware settings and updates — the phone side of a physical product, including the reconnection edge cases.
Offline-first field apps
For vans, sites, warehouses and basements. Work is captured locally, queued, and reconciled when signal returns — with a clear rule for who wins a conflict.
Release engineering
Signing, certificates, TestFlight and internal tracks, store listings, privacy declarations, phased rollout and crash reporting — set up once, in your accounts.
02 How it works
From first screen to the store, and back again.
A mobile build is not a website with rounded corners. The app runs on a device that loses signal, dies at 3%, and belongs to someone who will not read your instructions — and it can only reach the public through a review queue you do not control.
Fig. — Design to store and back: an app that works offline, a sync and push layer behind it, real-device testing before review, and crash data feeding the next version.
03 The build
From "we need an app" to live in both stores.
Cut version one down
Every app idea arrives with twenty screens. We find the three that carry the value, and park the rest in writing so nothing is lost — just sequenced.
Prototype the flow
Screens and navigation you can tap through on your own phone before we build them. Changing a flow here costs an afternoon; changing it in week four costs a week.
Build the core loop
The main journey first, wired to real data — including what the app does with no signal, a dead API, or a permission the user declined. Those cases are the app, not edge cases.
Test on real devices
TestFlight for iOS, internal track for Android, on the handsets your users actually own. Old phones, small screens, bad networks. Simulators are optimists.
Submit, release, watch
Store listings, privacy declarations and signing set up in your accounts, then a phased rollout with crash reporting on from day one — so a bad build is caught at 5% of users, not 100%.
04 Fit
This is for you if…
- You have a web product and customers keep asking where the app is.
- You sell hardware that needs a phone to set it up, read it, or update it.
- Your team works in places with no signal, using a tool that assumes there is.
- You need to reach people with a notification, not an email they'll never open.
- A previous build stalled in review, or was never submitted at all.
- You want the App Store and Play Console accounts in your company's name.
05 Questions
What clients ask first.
What happens if the app gets rejected?
We fix it and resubmit — that's included, not a change request. Most rejections are predictable (missing privacy declarations, an unclear demo account, a permission prompt without a reason string) and we clear those before submitting. What nobody can promise is the clock: review is typically a day or two, occasionally longer, and it belongs to Apple and Google. We plan launches with that slack built in rather than pretending it isn't there.
Native or React Native — which do we need?
If the app is mostly screens, forms and synced data, React Native gets you both platforms for close to the cost of one, and we'd recommend it. If it leans on Bluetooth, background processing, camera or sensor work, or has to feel unmistakably like an iOS app, native is worth the extra weeks. We've shipped both, and we'll tell you on the call which one your app is — including when the answer is "you don't need an app yet, you need a good mobile web app".
Who owns the developer accounts?
You do. The Apple Developer Program membership and Google Play Console account are registered to your company, paid on your card, with us added as a member we can be removed from. That means the listing, the reviews, the signing keys and the users stay yours — and you're never in the position of asking an agency for access to your own app.
What does the app do with no connection?
Whatever we agree it should — but we agree it explicitly. Usually reads come from a local store so the app opens instantly, and writes go into a queue that replays when signal returns. The part that needs a decision is conflicts: if the same record changed on two devices, does the last write win, does the server win, or does a person choose? We settle that in week one, because retrofitting it later means touching everything.
What about new OS versions?
iOS and Android ship a major version every year, and roughly once a year a change is significant enough to need work — a new permission model, a deprecated API, a store policy with a deadline. A working app doesn't rot overnight, but it does drift. Some clients handle it in-house with the repository we hand over; others keep us on a Partner plan that covers the annual pass and keeps the app on supported SDKs.
06 Related
Often built together with:
Tell us what the app has to do.
A couple of sentences about who uses it and what it replaces is enough. You'll get an honest read on native versus cross-platform, what version one should contain — and a fixed quote within 48 hours.
Book a free discovery call