What this covers
- Customer apps for booking, ordering, account management, and loyalty
- Field and workforce tools for staff working on sites, in vehicles, or anywhere the connection is unreliable
- Offline-first behaviour so work continues without signal and syncs cleanly once it returns
- Push notifications that are genuinely useful rather than the reason someone uninstalls the app
- App Store and Google Play submission, including the review rejections almost every first submission collects
- Taking over an existing app that has stopped building, stopped updating, or lost its original developer
How we approach it
We usually recommend one shared codebase across both platforms, because most apps do not need two. Where a feature genuinely benefits from native code we write native code for that piece — the decision is made per feature, with reasons, rather than as a blanket rule chosen before we understand the app.
A phone is a device that gets lost, so we treat it as one. Nothing sensitive is cached where another app could read it, credentials go in the platform keychain, and every request is authorised again by the server. The app is a convenient interface to your system, never the thing enforcing the rules.
Store submission is planned into the timeline instead of discovered at the end. Privacy declarations, permission wording, and account deletion requirements are handled before we submit, because each of them will otherwise cost you a rejection and a week.
Tools we use for this
The platforms we reach for on this kind of work. The right choice depends on what you already run, and we will tell you when your existing tooling is the better answer.
- Flutter
- Dart
- Kotlin
- Swift
- React
- Expo
- Ionic
- Capacitor
- Android
- iOS
- Android Studio
- Xcode
- Fastlane
- Firebase
- PostgreSQL
- Sentry
Common questions
Do we need separate iOS and Android apps?
Rarely. One shared codebase covers both for most applications and roughly halves the cost of every future change. Apps leaning heavily on the camera, Bluetooth, or background processing sometimes justify going native, and we will say so when yours is one of them.
Can the app work without a connection?
Yes, and for field tools it should. Work is stored on the device and synced when the connection returns, with a defined rule for what happens when two people edited the same record — that rule is a business decision we agree with you up front, not something we guess at.
Do you handle publishing to the stores?
We do, publishing under your developer accounts so you own the listings. We handle the submission process and the review responses, and set up builds so future releases go out without ceremony.
Talk to us about mobile apps
Tell us what you are trying to achieve and we will tell you honestly whether we are the right fit. We reply within 1 - 2 business days.
Start a conversation →