Every year a new iOS lands in September, a new Android at about the same time — and with them, the same worry: are you supposed to do something so your app keeps up? Short answer: no. Here is what actually changes underneath an app when the operating system moves, and who takes care of it.
Day 1,095 — what happens to an app in the three years after you launch it.
The September question
You know the small unease. The keynote makes headlines, your phone updates itself overnight, and the next morning a thought crosses your mind: what about my app? Does it still work? Was I supposed to prepare something?
The instinct is not wrong. Something does change: your app rests on hundreds of functions provided by the operating system — showing a map, sending a notification, asking for a permission — and that foundation is precisely what just moved. So the question is not "is anything happening?" — something is happening. The question is: whose job is it?
What a new operating system changes underneath your app
Two movements, almost always.
Functions stop. Not with a bang: a function your app relied on simply stops being available, and whatever leaned on it stops responding. Nothing "crashes" on screen; something just no longer happens. It is the sneakiest kind of failure, because it leaves no visible trace.
Others become mandatory. The system introduces a new way of doing things — safer, more privacy-conscious — and gradually makes it unavoidable. Not overnight: a deadline is set, sometimes months ahead, and it always ends up arriving.
The point that reassures and worries at the same time: most of these movements are announced in advance. Apple and Google publish what is going to stop and what is going to become mandatory well before it takes effect. Everything is readable — provided someone reads it. And the rhythm never pauses: two operating systems, one major version each per year, adjustments in between.
What happens on your behalf
This is where being on a platform changes the nature of the problem.
Someone reads those announcements — before they take effect, because that is their job. When a function is on notice, the component that uses it is rewritten once, in the engine that builds the apps. When a requirement becomes mandatory, it is integrated in that same place, once. And every app on the platform inherits those adaptations at its next build — yours like all the others.
What you did not do deserves to be spelled out, because that is the product: you did not read the release notes. You did not go looking for which of the affected functions your app used. You did not weigh the old way against the new one. You did not even know there was a decision to make.
One honest note, because it matters: this watch is nothing like an all-risk insurance policy. It only catches what was announced or spotted — it is continuous work, done by people, not a magic guarantee. But that is exactly what makes it valuable: it exists, it never stops, and it is not your burden.
The same year, for whoever maintains their own code
Worth laying out the counterpoint, because it sets the scale. If you are the one maintaining your app's source code — written by a contractor, or generated from a prompt — September looks very different. You have to read what changed, find what concerns you among hundreds of announcements, edit the code, rebuild, resubmit. Then do it again for Android. Then again next year. Whether you have anything new to publish or not: the appointment is set by the operating systems, not by your calendar.
That yearly appointment exists on a platform too — it just lives on our side. That is the whole difference between owning a problem and benefiting from its solution.
What stays yours: nothing — and that is the point
Articles in this series usually end with the list of what nobody can do in your place — the full map is in the first article. For iOS and Android evolutions, that list has one peculiarity: it is empty.
No decision to make, no deadline to track, no setting to change. Of all the forces that weigh on an app over the years, this is the only one where your share of the work is zero — and that is exactly why this article exists: so you know that this particular question is one you are allowed to stop asking.
The one gesture that remains yours is the one that always was: deciding when to publish an update. The adaptations are ready and waiting — your app takes them on board at its next build, whether you publish for that reason or for any other.
September becomes a normal month again
The benefit fits in one image: the keynote goes back to being a show. You can watch it out of curiosity, get excited about a new feature, or ignore it entirely — none of the three choices has any consequence for your app. The month when the whole mobile ecosystem holds its breath is, for you, a month like any other.
For those curious about the mechanics, I have written from the engineering side about what three years of operating system changes actually do to an app — and the unglamorous work that absorbs them.
And if you do not have an app yet, you might as well build it somewhere September will never be your problem: create my app with GoodBarber.
Frequently asked questions
Can a function my app relies on stop working overnight?
Rarely. Most removals are announced in advance by Apple and Google, with a deadline — which is what makes the watch possible: reading those announcements before they take effect, and replacing the affected component upstream, for every app on the platform. The "everything stops one morning without warning" scenario is precisely the one this work exists to prevent.
What happens to my app the day a new iOS or Android comes out?
On your side, nothing to do. A new operating system does not remove your app and does not erase anything. The adaptations it calls for are prepared in the engine that builds the apps, and yours takes them on board at its next build — whether that build is motivated by this or by a routine update.
Can my app fall several iOS versions "behind"?
It can, if it has not been rebuilt in a long time — and it is not a dead end. The engine kept up in the meantime: at the next rebuild, your app comes out adapted to the current system, however many versions went by. Catching up does not cost you in proportion to the delay.
Can a new Android version make something mandatory for my app?
Yes — it is even the most common movement: a new requirement, often tied to security or privacy, gradually becomes unavoidable, with a deadline. On a platform, that requirement is integrated once, upstream, for every app; yours complies at its next build, without you ever having to know it existed.