Mobile App Development
Mobile app development for iOS and Android
App review, OS upgrades, device fragmentation, crash triage, release trains. We build for the two years after launch, not just the launch.
- iOS + AndroidOne codebase
- +15Launched startups
- Store-readyWe handle review
What we build
Apps people keep on the first screen
Cross-platform with React Native
One codebase for both stores where the app is UI and data. Roughly halves the build and, more importantly, halves the maintenance.
Native where it earns it
Swift or Kotlin when you are pushing hardware: camera pipelines, Bluetooth, background location, heavy graphics.
Offline-first behaviour
Local state and sync that survives a lift, a tunnel and a bad hotel network without losing the user's work.
Backend and APIs
The service layer, auth, push notifications and admin tooling. An app with no backend is half a project.
Store submission and review
Metadata, screenshots, privacy declarations, and the review round-trips if they happen. We have handled these before.
Release engineering
CI-built signed artefacts, staged rollouts, crash reporting and analytics wired in from the first release.
How we work
From idea to installed
Define the one job
Successful apps do one thing users open them for. We push hard to cut the first version down to that.
Prototype the core flow
A clickable version of the main journey on a real device, before production code exists. Cheap to change at this stage.
Build to a release train
Sprints ending in an installable build you can put on your own phone. Feedback comes from using it, not reading about it.
Launch and iterate
Staged rollout, crash and funnel monitoring, and a queue prioritised by what real users do rather than what we assumed.
Common questions
What buyers ask about app projects
Cross-platform or native: which should we choose?
For most business and consumer apps, cross-platform with React Native is the correct default: one team, one codebase, both stores, and performance that users cannot distinguish.
Go native when the app's value is in the hardware: sustained camera processing, low-level Bluetooth, background location, or graphics-heavy interaction. We will tell you which side of that line you are on rather than defaulting to whichever is more billable.
What happens if Apple rejects the app?
We handle the response. Rejections are usually about metadata, privacy declarations or account-deletion requirements rather than the code. Knowing the common causes in advance is most of what avoids a two-week review loop.
Do we need to maintain it after launch?
Yes, and budgeting for that from the start is the difference between an app that lasts and one that breaks on the next OS release. Both platforms ship a major version annually, and each one deprecates something. We offer ongoing maintenance, or we hand over cleanly to your team.
Can you take over an existing app?
Often, and we start with an audit rather than a promise: dependency health, build reproducibility, test coverage and store account state. If the honest recommendation is a rewrite we will say so and explain what specifically makes it cheaper than continuing.
Who owns the store accounts?
You do. The apps are published under your Apple and Google developer accounts, not ours. This matters enormously the day you want to change supplier.
Got an app idea, or an app that needs rescuing?
One call with a senior mobile engineer. Bring the messy version.