Why do half my customers still have the old version?

Because the update depends on the phone: automatic update settings, wifi, free space, OS version. On iOS, phased release only reaches users with automatic updates, 1 % on the first day and 100 % on the seventh; on Android, you choose the percentage. A well-built app does not need everyone to be up to date: the API serves several versions at once, and the minimum version is raised only after adoption.

Can the update be forced?

Yes, but by the server, not by the app: every call carries the version, and below the minimum version the API answers “version too old” and the app shows the update-required screen, with the immediate in-app update on Android. The minimum version is raised only after 90 % adoption and a stable crash rate, and never to a version not yet visible in both stores.

How long to fix a critical bug?

One day for the patch version, then review: Apple says it handles at least 50 % of submissions in under 24 hours and 90 % in under 48, and an expedited review can be requested for a critical bug. Meanwhile, the faulty function is switched off by a flag served by the API, without submission, and the app keeps working.

Must everything go through the stores?

No. Texts, screen order, promotions and content go through flags and the API, live the same day for every version. A new field is added to the API without submission. Only what really changes the installed code, a new screen, a changed local database, a crash fix, goes through a version.

How do you test on phones you cannot see?

The log of calls per version and device says which phones and OS versions are actually present among your customers; we test on those models, including old ones, and on a slow network. Then the staged rollout does the rest: 5 % of customers are the last test, and the crash threshold decides what comes next.

What happens with Google Play every year?

Every 31 August, Google Play raises the Android target version required for updates, Android 16 by 31 August 2026 per its help page; a lagging app stops being offered to new users whose phone is newer than its target, existing users keeping it. It is one more version in the train, planned in June, and a line in the maintenance contract.

Updating a mobile application without breaking what your customers have installed in Algeria in 2027: versions, API compatibility, staged rollout, forced update, and the hotfix that ships in a day

Short answer. You control neither when a customer updates nor whether they do; you control what the app does at startup and what the API answers. So: every call carries the app version, the API adds fields and never removes one without a date, old routes are kept until a written date, and the server decides who sees a soft banner and who sees an update-required screen. The new version ships on both stores by staged rollout, 5 % then 20 % then 100 % on Android, seven phased days on iOS, with a crash threshold written beforehand and a halt if it is crossed. Texts, screens and promotions go through flags and the API, not through a submission. A critical fix ships in a day, by the same path. The minimum version is raised only after 90 % adoption, never on release day.

This guide is for the manager whose app is installed on hundreds of customers’ or couriers’ phones, the founder settled in France who cannot test on their users’ phones in Algeria, and the person who must compare two maintenance quotes. It does not repeat what an app costs every year, described in the guide on keeping an app alive, nor how a web platform is delivered without breaking it, described in the delivery guide; it describes what is built so that a mobile update is a risk-free event, and extends our page on mobile applications.

What the stores say

Review is faster than people think, and slower than a hotfix needs. Apple writes that App Review handles “at least 50 % of submissions in less than 24 hours and 90 % in less than 48 hours”, and that an expedited review can be requested “to fix a critical bug”, with reproduction steps. What this imposes: a critical iOS fix is a one-to-two-day affair even with the expedited request, which is why the app must keep working meanwhile, with the faulty function switched off by a flag served by the API.

Staged rollout exists on both stores, but not the same way. On the App Store, phased release “will release your app’s update gradually over 7 days”, 1 %, 2 %, 5 %, 10 %, 20 %, 50 % then 100 % of users with automatic updates, can be paused “for up to 30 days”, and does not stop anyone downloading the version manually. On Google Play, the staged rollout is driven by hand: you pick the percentage, you raise it, and you can “halt a staged rollout” if you find an issue, in which case “no additional users will receive” the version while those who have it keep it. What this imposes: on iOS you watch and pause; on Android you decide each step, and the next step is taken only when the day’s crash rate is under the threshold.

The store can offer the update inside the app itself. Google Play in-app updates, supported “on devices running Android 5.0 or higher”, offer two flows: the “flexible” flow, background download while the user carries on, and the “immediate” flow, a full-screen flow that “requires the user to update and restart the app in order to continue”. Apple has no equivalent: on iOS the update-required screen is yours, and it links to the App Store. Finally, every year Google Play raises the target API required for updates, Android 16 by 31 August 2026 per its help page, and a lagging app “will stop being available to all new users” whose phone runs a newer Android than its target, existing users keeping it. What we did not find: a public breakdown of Android versions in Algeria; what we see on our projects is still 2019 phones, and we say so as an observation.

A mobile update, in five layers

Before the day by day, the five layers, and the one that makes the other four possible.

Figure 1 · The accented layer is what makes everything else possible: as long as the API serves several versions at once, the rollout can be slow, halt, resume, and nobody is blocked. An app whose API breaks old versions has no choice: it must update everyone at once, which is exactly what you cannot do on phones you do not control.

The customer’s phone: the installed app, its version, its local database, the OS, sometimes a 2019 Android; you decide neither when they update nor whether they do. The stores: review, staged or phased rollout, halt or pause, in-app update, and the yearly target-version requirements. Your API: the app version read on every call, the minimum accepted version, fields added never removed, old routes kept until a date; it is the layer that must talk to every installed version at once, and it decides who must update.

Observability: crashes per thousand sessions per version, adoption per day, API errors per version, devices and OS versions actually present; the threshold is written before the rollout, and the figure is read every morning for ten days, on a screen built like the manager’s dashboard. Process: code freeze, tests on old devices, release train on fixed dates, release notes, one-day hotfix, feature flags. An app whose API breaks old versions has no choice: it must update everyone at once, which is exactly what you cannot do on phones you do not control; everything else follows from that sentence.

«An app whose API breaks old versions must update everyone at once, which is exactly what you cannot do on phones you do not control.»

One update, day by day, on both stores

A version is understood over ten days, two tracks, and one halt.

Figure 2 · Ten days, two tracks, one halt. On Android the percentage is chosen by hand and rises in steps; on day 3 the new version’s crash rate crosses the threshold, the rollout is halted at 20 %, the hotfix ships the next day, and the climb resumes. On iOS the phased release follows Apple’s seven-day curve and can be paused. The crash figures are a constructed example, not a project measurement.

Day 0: internal tests on Android through the internal track, submission on iOS. Day 1: 5 % of Android customers receive the version; iOS is approved. Day 2: 5 % held, the crash rate is 0.5 per thousand sessions, under the 1.0 threshold; iOS starts its phase at 1 %. Day 3: step to 20 % on Android, and the morning figure says 2.1: a crash at payment on some old Androids, which the 5 % had not shown because they did not include enough of those phones. The rollout is halted; nobody beyond 20 % will receive this version. Day 4: hotfix 2.4.1, tested on an Android 8, submitted; the payment function in question had already been switched off by flag the evening before, without submission, for the 20 % affected.

Day 5: 2.4.1 ships at 20 %, the rate drops to 0.3. Day 6: 50 %. Day 7: 100 % on Android; iOS is at 50 % of its curve and finishes on day 8. During these ten days the API served 2.3 and 2.4 at the same time: nobody was blocked, and the 71 % of customers still on 2.3 kept ordering. The crash figures in this story are a constructed example; what is not constructed is the order of decisions, and the fact that the halt was decided by a figure read in the morning, not by a customer on the phone.

Six kinds of change, and the path each one takes

Not everything goes through the stores, and most changes should not.

Figure 3 · Four of the six changes do not go through the stores, or not right away. The reflex “we ship a version” is the most expensive and slowest; it is reserved for what really changes the installed code, and even then the old version must keep working.

A text, a colour, a screen: feature flag or content served by the API; live the same day, for every version. A new field: added to the response, never required; the old version ignores it without error, the new one reads it; it is the most frequent change and costs nothing when the rule holds. A critical fix: patch version the same day, expedited review requested with reproduction steps, immediate update offered in the app on Android, update screen on iOS once the build is visible.

The local database changes: versioned migration run at startup, tested on a full database and on an old device, never a column removal in the same version; it is the fragile part of an app that works offline, described in the synchronisation guide. A screen disappears: flag turned off for everyone first, code removed two versions later. The API changes shape: new v2 route, v1 kept until a written date, minimum version raised after 90 % adoption. Four of the six changes do not go through the stores, or not right away; the reflex “we ship a version” is reserved for what really changes the installed code.

One API, three versions installed at the same time

Compatibility is not decided in the app but in the API, and it shows on three phones.

Figure 4 · Every call carries the app version, and the server answers each one differently: the oldest is sent to the update-required screen, the current one receives its data and a banner, the new one reads the new fields. The shares are an example; what does not change is that the minimum version is raised only after adoption, never on release day.

Every call carries the app version in a header, and the server answers each one differently. Version 2.2, on a 2019 Android never updated, is below the minimum: it receives an answer saying “version too old”, and the app shows the update-required screen, with the link to the store and, on Android, the immediate in-app update. Version 2.3, current for 71 % of customers, receives its data and a soft banner; the field added by 2.4 is present in the response and it ignores it without error. Version 2.4 reads the new fields on the v2 route.

Three rules hold this drawing. Fields are added, never removed without a date: as long as a served version reads a field, it stays. Old routes are kept until a date written in the contract, not “once everyone has migrated”. The minimum version is raised by the server, after 90 % adoption and a stable crash rate, never on release day, and never to a version not yet visible in both stores. The shares in the drawing are an example; the log of calls per version, read every week, gives the real ones, and it is what says when to raise the minimum version.

«Fields are added, never removed without a date; and the server decides who must update.»

Six update failures, and what the architecture does

Six failures we see on the apps we take over, and the defence for each.

Figure 5 · The first two failures come from the API and the OS, the next two from the local database and the server, the last two from the process. All are visible at 5 % before they are visible at 100 %, and that is the only reason for a staged rollout.

The app refuses to start on 2019 phones: the minimum OS version is decided on the devices actually present in the log, not on worldwide statistics, and the old app keeps being served. A field removed from the API crashes every old version the same morning: contract tests run against the last three versions before every production release. The local migration corrupts the database and the week’s offline orders vanish: migration tested on a full database, local backup before migration, 5 % first.

Forced update to a missing version: the server requires 2.4 still in review, everyone is blocked; the minimum version is raised only once the build is visible in both stores and adopted. The fix makes it worse: shipped untested at 100 %; same path as any version. Nobody is watching: the rate doubles and you learn it from a customer; per-version board read every morning, alert above the threshold. All these failures are visible at 5 % before they are visible at 100 %, and that is the only reason for a staged rollout; an app taken over from a vanished supplier, as in the dedicated guide, starts with that board.

Seen elsewhere: the stores’ documentation, and what transposes

Three sources say the essentials. Apple documents the seven-day phased release, the pause up to thirty days, review times and expedited review for a critical bug; what transposes is that an iOS fix is a one-to-two-day affair, and the app must hold that long with the function switched off by flag. Google documents the hand-driven staged rollout, the halt, and in-app updates, flexible or immediate; what transposes is that each Android step is a decision taken on the morning figure, and that the immediate update is the tool of the minimum version. Google also documents the yearly target, Android 16 by 31 August 2026; what transposes is one more version in the train every summer, planned in June.

What these sources do not say: which phones your customers have, which crash threshold you accept, and how many versions you serve at once; the log of calls per version answers the first question, the specification the other two.

The rules of an update you can ship without flinching

Six rules, written before the first version. Every call carries the app version. The API adds and never removes without a date. The server decides the minimum version, after adoption, never on release day. Staged rollout on both stores with a crash threshold written beforehand and a possible halt. Tests on the devices actually present, including old ones, and on a full local database. Texts, screens and promotions go through flags, not through a submission.

A seventh rule concerns the quote: “app maintenance and updates” is not a requirement, it is a sentence; the requirement reads “app version in every call; add-without-remove rule and routes kept until a date; minimum version decided server-side after adoption; staged rollout with crash threshold and halt; in-app update on Android and update-required screen on iOS; feature flags; versioned local migrations tested on a full database; contract tests against the last three versions; crash and adoption board per version; one-day hotfix by the same path; Android target version every summer”, and it is checked as the specification guide recommends. A quote that prices “publishing to the stores” has priced day 0 of a ten-day process.

Six apps, and the update they fear most

Six apps we often maintain, and for each the update that needs the most care.

The field sales app, described in the dedicated guide. A local database full of the round’s orders; the local migration is tested on a phone back from three days without network.
The couriers’ app, described in the dedicated guide. Two hundred heterogeneous phones; the minimum OS version is decided on the log, and the immediate update is done at the depot, on wifi, not on the road.
The gym app, described in the dedicated guide. Access control must work with the old version on release day; the new badge format is added, the old one stays served.
The payment app, described in the online payment guide. A payment fix ships in a day, and the function is cut by flag meanwhile.
The Umrah agency app, described in the dedicated guide. Pilgrims are abroad during the season; no forced update during the trip, flags only.
The app run from France, described in the dedicated guide. The founder does not see their customers’ phones; the per-version board is their only eye, and they read it every morning for ten days.

The 2027 calendar

The calendar is that of a version delivered in eight weeks, only one of them rollout.

Figure 6 · Eight weeks for a version, only one of them rollout: the rest is what makes the rollout safe, tests on the devices your customers really have, and patience before raising the minimum version. Every year on 31 August, Google Play also raises the required Android target version; that is one more version in the train, planned in June.

Week 0 to 1 freezes the code and writes the release notes, for the client and for the stores. Week 1 to 2 tests on old devices, Android 8 and 10, a six-year-old iPhone, a slow network, the local migration on a full database, and runs contract tests against the last three versions. Week 2 to 3 submits to both stores, with the Google Play internal track in parallel. Week 3 to 4 is the staged rollout, 5 %, 20 %, 50 %, 100 % on Android and the iOS phases, halted if the threshold is crossed.

Weeks 3 to 5 watch, crashes and API errors per version every morning, and ship a hotfix in a day if needed, by the same path. Weeks 6 to 8 raise the minimum version, after 90 % adoption and a stable rate; stragglers see the update-required screen. Every version is demoed to the client before submission, as the delivery guide describes; and every summer, on 31 August, the Android target required by Google Play is one more version in the train, planned in June. The choice between a native app and an installable web app, described in the dedicated guide, changes this calendar: an installable web app has no week 2 to 3.

What makes a mobile update fail

The apps we take over almost always failed on an update for one of these reasons.

The API that does not know the app version. Impossible to know who crashes, impossible to force anyone cleanly.
A field removed “because nobody uses it any more”. The 6 % who used it call the next day.
100 % in one go. The crash shows on every customer instead of 5 %.
The minimum version raised on release day. The build is not yet visible on the App Store; everyone is blocked.
Tests on the developer’s phone. A recent model, on wifi, in Algiers; customers have 2019 Androids, on 3G, in Sétif.
The local migration with no backup. The week’s offline orders vanish and do not come back.
Nobody watches the board. The crash rate doubles, and you learn it from a customer.

Frequently asked questions

The questions we receive from managers, founders and IT managers.

Why do half my customers still have the old version?: Because the update depends on the phone: automatic update settings, wifi, free space, OS version. On iOS, phased release only reaches users with automatic updates, 1 % on the first day and 100 % on the seventh; on Android, you choose the percentage. A well-built app does not need everyone to be up to date: the API serves several versions at once, and the minimum version is raised only after adoption.
Can the update be forced?: Yes, but by the server, not by the app: every call carries the version, and below the minimum version the API answers “version too old” and the app shows the update-required screen, with the immediate in-app update on Android. The minimum version is raised only after 90 % adoption and a stable crash rate, and never to a version not yet visible in both stores.
How long to fix a critical bug?: One day for the patch version, then review: Apple says it handles at least 50 % of submissions in under 24 hours and 90 % in under 48, and an expedited review can be requested for a critical bug. Meanwhile, the faulty function is switched off by a flag served by the API, without submission, and the app keeps working.
Must everything go through the stores?: No. Texts, screen order, promotions and content go through flags and the API, live the same day for every version. A new field is added to the API without submission. Only what really changes the installed code, a new screen, a changed local database, a crash fix, goes through a version.
How do you test on phones you cannot see?: The log of calls per version and device says which phones and OS versions are actually present among your customers; we test on those models, including old ones, and on a slow network. Then the staged rollout does the rest: 5 % of customers are the last test, and the crash threshold decides what comes next.
What happens with Google Play every year?: Every 31 August, Google Play raises the Android target version required for updates, Android 16 by 31 August 2026 per its help page; a lagging app stops being offered to new users whose phone is newer than its target, existing users keeping it. It is one more version in the train, planned in June, and a line in the maintenance contract.