Software engineering · Mobile and cross-platform
Apps that survive their second year
Native and cross-platform applications, built with the release process, store operations and device reality handled from the beginning. Shipping the first version is the straightforward part.
Where this starts
The build is a fraction of the commitment
A mobile application is not a website in a different shape. It is a binary sitting on hardware you do not control, distributed through a process you do not own, on operating systems that change on someone else’s schedule, used by people who will not update when asked. Teams routinely budget for the build and not for the two years afterwards, which is where most of the work actually is.
What we usually find
- A first version shipped, then nothing, because nobody owns the release process
- A store rejection nobody anticipated, blocking a launch date
- Old versions still in the field calling an API that has moved on
- Crash reports arriving with no way to tell which release or which device
- One codebase per platform, drifted far enough apart to be two products
- Offline behaviour never designed, so the app is useless on a train
Our position
The question to settle before any mobile code is written is not which framework. It is who releases this in eighteen months, and how.
What the work covers
Build it, release it, keep it running
Technology choice matters less than most conversations about it suggest. What matters is whether the whole lifecycle has an owner and a repeatable process.
Native and cross-platform
Swift and Kotlin where the application genuinely needs platform behaviour, React Native or Flutter where a shared codebase serves the product better. We will say which fits and why rather than defaulting to whichever we prefer.
Offline and unreliable networks
Local state, conflict resolution and synchronisation designed deliberately, because a mobile device is intermittently connected by definition and pretending otherwise produces a demonstration rather than a product.
Device and platform reality
Testing across the devices and operating system versions your users actually hold, with screen sizes, text scaling and accessibility settings treated as requirements rather than as edge cases.
Release engineering
Automated builds, signing, staged rollout and a process anyone on the team can run. Store submission and review treated as a known scheduled step rather than a recurring surprise.
Versioning against your API
A contract that keeps supporting the versions still in the field, because you cannot force an update and the tail is always longer than anyone expects it to be.
Crash reporting and product analytics
Attribution to release, device and operating system, so a spike in failures is diagnosed within the hour rather than discussed across a week.
How a release becomes routine
The measure of a healthy app is a boring release
Everything below exists to move a release from an event that needs planning to a step that needs a commit.
- Build
- Signed builds produced by the pipeline from a tagged commit and never from a laptop, which is also what makes the process survive somebody leaving.
- Test
- Automated testing on a device set covering the operating system versions in your install base, rather than only the current one.
- Distribute
- Internal and beta distribution wired in, so the business sees a change before customers do and feedback arrives before the store does.
- Release
- Staged rollout with an automatic halt on a crash rate threshold, which turns a bad release into a contained one affecting a small percentage.
- Observe
- Crash and performance data attributed to release and device, feeding the same dashboards the rest of the estate already uses.
What you are left holding
- Applications in both stores, released from a pipeline rather than a laptop
- A release process documented and runnable by your own team
- Automated testing across the operating system versions your users are on
- Staged rollout with a crash rate halt
- A versioning policy your API and your apps both honour
Tell us who uses it and what happens when the signal drops
That answer decides more of the architecture than the choice of framework ever will.