Mobile apps built to survive their second year

The build is the cheap part

A website can be left alone for a year and still work. A mobile app cannot. Apple and Google each ship a major operating system release annually, each enforces a minimum target API level for anything you want to keep publishing, and each will quietly stop distributing a build that falls behind.

Google’s current rule shows the shape of the problem plainly. From 31 August 2026, new apps and app updates on Google Play must target Android 16 (API level 36) or higher, and apps left on older targets stop being available to new users on devices running newer Android versions. Nothing crashes. Nothing is deleted. The app simply becomes uninstallable for a growing share of the market, and the first anyone notices is a confused support email.

That is why we scope mobile app development as a multi-year commitment rather than a delivery. The interesting question is almost never whether something can be built — it usually can. It is what the thing will cost to keep alive once real people depend on it, and whether it deserves to exist in the first place.

Whether you need an app at all

We talk clients out of apps more often than we talk them into one, and the reason is nearly always the same: the idea does not need to be installed.

Installation is an enormous ask. Someone has to find you in a store, trust you enough to grant permissions, accept an update cadence, and keep an icon on a finite home screen. In exchange, an app must offer something a good mobile website cannot: dependable offline use, background behaviour that survives the app being closed, deep hardware access, push as a genuine part of the product rather than a marketing afterthought, or a habit frequent enough that the icon earns its space.

If your concept is essentially a catalogue, a booking flow, a set of forms or a content library, a well-built responsive site will be cheaper, instantly available, indexable by search engines, and changeable without waiting for review. Apple is unusually direct about this: its minimum functionality guideline exists precisely to reject apps that are repackaged websites with nothing added. Wrapping a site in a shell is not a cheap route to the App Store; it is a rejection with a delay attached.

Where an app is right, that same test tells you what version one should contain. The features that justify installation come first. Everything else can wait, and most of it should.

Consumer, B2B and internal apps are three different projects

They are usually procured as though they were one thing, which is where a good deal of misalignment starts.

A consumer app competes for attention with everything else on the device. Its hardest problems are acquisition and retention, not features: the store listing has to convert, the first session has to deliver something before the user decides, and the onboarding has to ask for permissions in an order that does not feel like an interrogation. Rating prompts, push strategy and the empty state on day one matter more than the twelfth screen. Discovery is a discipline in itself, which is why we treat it separately.

A B2B or client-facing app is usually chosen by someone who will not use it. The buying decision runs on procurement criteria — security posture, single sign-on, data residency, an audit trail — while the adoption depends on people who were handed it in a meeting. Both audiences have to be designed for, and the second is the one that determines whether the contract renews. Accessibility obligations are frequently contractual here rather than optional, and enterprise device management adds constraints that are cheaper to learn about at the start.

An internal app has the smallest audience and often the clearest return, because you can measure the process it replaces. It also has the most forgiving distribution: managed deployment can sidestep public store review entirely, which changes the calculus on release cadence and on how much design polish is worth buying. The risk it carries instead is that requirements come from whoever asked loudest, so scope discipline matters more here than anywhere else.

The shape of the project — how much research, how much design, how much store work, how much integration — follows from which of these you are building. Being explicit about it in the first conversation prevents most of the arguments that happen later.

Native, cross-platform or somewhere between

There is no universally correct answer here, only a trade you should make deliberately rather than inherit from whoever you happened to hire.

Cross-platform, honestly assessed

React Native and Flutter both let one team ship to both stores, and for content-led, form-led and commerce apps the results are frequently indistinguishable from native to anyone who is not looking for the seams. They work in different ways, and the difference matters. React Native renders real platform views, and its New Architecture — the Fabric renderer, TurboModules and the JavaScript Interface that replaced the old asynchronous bridge — has been the default since version 0.76. Flutter takes the opposite approach and draws everything itself through its own rendering engine, shipping its own implementations of platform controls rather than deferring to the system.

The consequence is practical. Flutter gives you an interface that is identical everywhere, which is either the point or the problem depending on your product. React Native inherits platform behaviour more naturally, and inherits platform quirks along with it.

The cost rarely priced in either case is the abstraction layer itself. You are now maintaining a framework version as well as two operating systems, and when a platform ships a new capability you either wait for framework support or write native code anyway.

When native earns its keep

Native is the right call when the app lives close to the hardware or close to the platform: sustained camera and sensor work, complex background processing, widgets, watch and car surfaces, tight integration with system features, or anything where you need a new OS capability on the day it ships. It is also the pragmatic choice when only one platform matters commercially, which is more common than agencies tend to admit. Building for both because a single-platform app feels incomplete is one of the more expensive habits in this industry.

We keep separate pages for Android app development and iOS app development because the two disciplines genuinely diverge below the surface, plus one on shared-codebase work for when that trade is worth making. The recommendation comes after the feature list exists, not before.

Scope is the whole project

Most app overruns are not engineering failures. They are the accumulated cost of features that arrived without a decision, each individually reasonable and collectively fatal.

So we write the list down. Every feature gets a line, a size, and a note recording whether it is in version one and why. The deferred list is kept visible rather than deleted, because the useful artefact is not the plan — it is the record of what was consciously left out, which is what stops the same conversation happening four times.

The discipline that pays for itself most reliably is asking what happens when things go wrong. Empty states, no network, a failed payment, an expired session, a permission the user denied, a device on three per cent battery in a lift. Designing those paths early is unglamorous, and it is where apps are actually won or lost, because the happy path is the easy portion of the work and everybody remembers to build it.

Designing to the platform, not around it

Android and iOS are not two skins over the same product. They differ in navigation model, back behaviour, typography, motion, and where users expect a control to live. An app that imposes one platform’s conventions on the other feels subtly wrong in a way users rarely articulate and reliably punish in reviews.

Practically, that means designing twice at the level of interaction while designing once at the level of brand: shared visual language, platform-appropriate structure. It also means treating accessibility as a design constraint rather than a remediation phase. Android’s core app quality guidelines set a minimum touch target of 48dp and contrast ratios of 4.5:1 for small text and 3:1 for large text. Apple sets comparable expectations and adds Dynamic Type, which means your layout has to survive a user who has turned the system text size up considerably. Layouts designed at one text size that clip at another are the most common accessibility failure we find in inherited apps, and they are cheap to prevent and tedious to retrofit.

Where the interaction design is the substantial part of the project, our product design practice leads it rather than treating it as a phase inside the build.

Backend, sync and the offline problem

Most apps are a client for something. The quality of that something determines more of the app’s behaviour than the app code does.

The decision carrying the most weight is how much has to work without a connection. “Works offline” ranges from caching the last screen the user saw — cheap, sensible, worth doing almost always — to full local writes with synchronisation and conflict resolution, which is one of the genuinely hard problems in software and should be scoped as such. Being clear about which one you need, early, prevents the most expensive mid-project pivot in mobile work.

Alongside that sit the parts users never see: authentication and token refresh, secure credential storage in the platform keystore rather than in preferences, certificate handling, background work scheduling, and push delivery through Apple Push Notification service and Firebase Cloud Messaging. We review these against the OWASP Mobile Application Security Verification Standard, which groups mobile security into concerns such as storage, cryptography, authentication, network and platform interaction. Using a published standard means the security discussion refers to a document you can read and audit us against, rather than to our reassurance.

Testing on the devices people actually hold

Simulators are a development convenience. They are not evidence, and they will not reproduce a manufacturer’s memory management, a three-year-old mid-range chipset, or a network that drops halfway through a payment.

A serious test plan covers a device matrix drawn from your own analytics rather than from whatever the team happens to own, the oldest OS version you have committed to supporting, screen shapes from compact phones to tablets and foldables, throttled and offline networks, and interruption cases: an incoming call, a backgrounded app killed by the system, a rotation mid-form.

Beta distribution is where this becomes real. TestFlight allows up to 100 internal testers and up to 10,000 external testers, with external builds requiring Apple’s Beta App Review before they reach anyone. Google Play offers internal testing for up to 100 testers, plus closed and open tracks for progressively wider groups. Used properly these are not a formality — they are the cheapest bug reports you will ever receive, because they come from real devices in real hands before the public listing exists.

What “launched” looks like in the data

An app is not finished when it is approved. It is finished when the numbers behave, and both stores now measure you against thresholds that affect distribution.

Google Play’s Android vitals treats an app as exceeding its bad-behaviour threshold when the user-perceived crash rate rises above 1.09% or the user-perceived ANR rate above 0.47%, assessed over a rolling 28-day window. Apps beyond those thresholds can have their store visibility reduced, and may have a warning shown to users on the store listing. That is worth sitting with for a moment: stability is not only an engineering quality measure, it is a distribution input. An app that crashes for one user in fifty is not merely annoying, it is harder to find.

So crash reporting is configured before launch, not after the first incident, with alerting thresholds set and a named person receiving them. The first fortnight after release is monitored daily. Most of what you learn in that window is unglamorous — an SDK misbehaving on one OS version, a timeout that only appears on slow networks — and fixing it quickly is the difference between a stable base and a review section you spend a year recovering from.

The annual maintenance nobody budgets for

Every year, without exception, a new iOS and a new Android version change behaviour, deprecate APIs and occasionally alter how your existing screens look. Every year, store requirements move on published dates: target API levels, billing library versions for apps selling digital goods, privacy declaration formats. None of this is optional, and none of it produces a new feature, which is exactly why it gets omitted from budgets and then discovered as an emergency.

We map those published deadlines onto a calendar at the start of an engagement, so the maintenance conversation is about a date on a schedule rather than a surprise. If you take nothing else from this page: the useful question to ask any prospective app partner is not what the build costs, but what the second year costs, and what happens if you decide to work with somebody else.

Where this fits with our other work

An app rarely arrives alone. The listing it launches into is its own discipline, and store listing optimisation largely decides whether anyone finds it once it is live. If the app is a client for a service that does not exist yet, the server side sits with our web application team. And where the harder problem is the interaction model rather than the engineering, design leads and the build follows.

If you are not yet sure which of those you need, that is a reasonable place to begin a conversation — and a better one than arriving with a specification you have already committed to.