Mobile App Development
Applications that hold up outside the office network
We build iOS and Android applications for customer-facing products and field teams, with offline behaviour, background synchronisation, and store submission handled as part of the engagement rather than left until the end.
- Typical timeline
- 10 to 16 weeks to store release
- Platforms
- iOS and Android from one codebase
- Includes
- Store submission and release pipeline
(01)Overview
What this covers
Mobile projects tend to be estimated as though they were a website with a different layout. The screens are the straightforward part. The work that determines whether an application is usable is everything around them: what happens when the connection drops mid-task, how a queued action is reconciled when it returns, how permissions are requested without losing the user, and how an update reaches a device that has not been opened in a month.
We plan for those conditions from the start. Local state is treated as the source of truth while offline, writes are queued and replayed with conflict rules you have agreed, and the interface tells the user what has been saved and what has not. For field and logistics teams this is usually the difference between adoption and abandonment.
Release is part of the engagement. Store accounts, signing certificates, provisioning, review submission, staged rollout, and crash reporting are set up and documented, and the first release goes through them with your team present so the second one does not depend on us.
(02)Capabilities
Capabilities
Covering the application, the services behind it, and the release process.
- 01
Cross-platform application build
A single Flutter or React Native codebase targeting iOS and Android, with platform-specific behaviour where users expect it. Native modules are written when a capability genuinely requires them.
- 02
Offline operation and synchronisation
Local persistence, a durable write queue, background synchronisation, and explicit conflict resolution rules. The interface shows synchronisation state so users know what has reached the server.
- 03
Device capabilities
Camera, location, Bluetooth, biometrics, push notifications, and file handling, each with permission flows designed so a denied prompt does not leave the user stuck in a dead end.
- 04
Backend services
The APIs, authentication, and data storage the application depends on, built with mobile constraints in mind: small payloads, pagination, incremental synchronisation endpoints, and versioning so older installs keep working.
- 05
Release engineering
Automated builds, signing, internal distribution for testers, and submission to the App Store and Google Play. Staged rollout and release notes are part of the pipeline, not a manual afterthought.
- 06
Crash reporting and performance
Crash and error reporting broken down by version and device, startup and interaction timing, and alerting on regression after a release reaches production.
(03)What you get
What you receive
A released application and a release process your team can operate.
- Applications live on the App Store and Google Play under your developer accounts
- Source code in your repository, covering the application and its backend services
- Signing certificates and provisioning profiles documented and stored in your password manager
- An automated build and submission pipeline, used for the first release with your team present
- Crash reporting and performance monitoring, configured with alerting
- A handover document covering architecture, synchronisation rules, and the release checklist
(04)Process
How we work
Builds reach your testers' devices from early in the engagement, so feedback comes from real use rather than screenshots.
- 01
1.Scope and platform decisions
One to two weeks. We establish the core tasks, the conditions the application has to work in, and which device capabilities are required. Platform approach, offline strategy, and store requirements are decided and written down.
- 02
2.Foundations and first build
Navigation, authentication, local persistence, and the build pipeline. By the end of this stage your testers have the application installed on real devices through internal distribution.
- 03
3.Feature build
Two-week increments, each ending with a build distributed to your testers and a review of what came back. Synchronisation and offline behaviour are tested under deliberately poor network conditions rather than assumed.
- 04
4.Store release
Store listings, screenshots, privacy declarations, and review submission. We handle the first review cycle including any rejections, run a staged rollout, and monitor crash rates before widening it.
(05)Technology
Technology
Platform choice is made during scoping based on the capabilities you need and the team that will maintain the result.
- Application
- Flutter
- React Native
- Swift
- Kotlin
- Local data
- SQLite
- Drift
- WatermelonDB
- MMKV
- Services
- Node.js
- PostgreSQL
- Firebase
- AWS AppSync
- Release
- Fastlane
- Codemagic
- Firebase Crashlytics
- Sentry
(06)Questions
Questions we are asked
Cross-platform or native?
Cross-platform for most products, because one codebase covering both stores is materially cheaper to build and maintain. We recommend native when the application depends on sustained high-performance graphics, low-level hardware access, or platform features that lack a reliable bridge. The recommendation comes with reasoning during scoping.
Do you handle store submission?
Yes, including the parts that commonly cause delay: privacy declarations, data use disclosures, screenshots at the required sizes, and responses to review rejections. The first release goes through the pipeline with your team watching, and the checklist is left behind.
Who owns the developer accounts?
You do. Apple Developer and Google Play accounts are registered to your organisation and we are added as members. Signing certificates are generated into your account and documented. Removing our access does not affect your ability to release.
What happens when the application loses connectivity?
Reads come from local storage and writes go into a durable queue that replays when the connection returns, under conflict rules agreed during scoping. Synchronisation state is visible in the interface so users are never guessing whether their work was saved.
Can you take over an existing application?
Often, yes. We start with a technical review of the codebase, build process, and store configuration, then give you a written assessment of what is maintainable, what should be replaced, and what it would cost either way before any development is committed.
Other services
Start a project
Discuss your application
A call to establish what the application needs to do, the conditions it has to work in, and what reaching the stores involves.