Will your app still work in three years?

Launch day is the easy part: you watched your app run. It is in the stores, the first users are downloading it, everything responds. The question that actually matters does not come up that day.

It comes up much later — the morning someone writes in to say that something has stopped working. In between, three years went by and you did not touch a thing.

Your app has not changed by a comma. The world around it has. That is the paradox: an app can stop working without a single line inside it moving.

Four movements, mostly. The stores tighten their rules — privacy declarations, minimum versions, permission policies. Operating systems drop capabilities along the way, and make others mandatory. Some things carry an expiry date: certificates and some service credentials run out — a domain's SSL certificate, for instance. And data piles up, until what was instant turns sluggish.

Pierre-Laurent has written up the detailed inventory of what degrades in silence, store policies and deadlines included. I am not going to redo it here. What interests me in this article is the question that comes next: once you know all that, who handles it?

Saying that a platform "handles maintenance" is vague to the point of being empty. The actual mechanism fits in one sentence: the problem is fixed once, at the platform level, and every app inherits the fix at its next build.

When a new privacy requirement comes into force, it is not thousands of app creators reading Apple's documentation each in their own corner. It is one team, once, updating the engine that builds the apps. When a system drops a capability, the component that used it is rewritten once, in that same place. You read nothing, migrated nothing, decided nothing.

It is worth spelling out the alternative, because it is the entire argument for building on a platform rather than maintaining your own code base. If you have to maintain the source code of the app yourself — code written by a developer you hired, or generated from a prompt in an afternoon — that same sentence describes your afternoon. You have to notice the rule changed, work out what it demands, change the code, rebuild, resubmit. Nobody did it once for everyone: it gets done once for you, then again for the next change, and the one after that. Producing an app has become remarkably cheap, and that is genuinely good news. Keeping one current has not moved an inch. Pierre-Laurent has walked through that gap in detail.

One point of honesty, because it counts: no amount of watching catches what nobody anticipated. Reading the rules before they take effect, rewriting a component before a removal turns into an outage — that is a job done continuously, not an automatic guarantee.

Everything above holds for a living app, one that gets republished now and then. But the real worry sits elsewhere, and nobody puts it into words: I left my app alone for two years. Is it lost?

No. And the reason lies in the way the work stacks up: the fixes wait for your app; they do not chase it. An app nobody touches does not repair itself overnight — nothing lands on it while it sleeps. But over those two years, every rule change and every capability dropped by iOS or Android was handled once, upstream, for every app on the platform. That work did not evaporate because yours went quiet. It is there, stacked up, waiting for it.

The consequence is very concrete: when you come back, you are not catching up two years by hand. You rebuild, and your app comes out to the standards of today's world, not those of the world it was born into. Catching up is not a project. It is a build. You do not have to know what was in it.

This is exactly what does not happen when you are the one maintaining the source code. Nothing accumulated on your behalf while it slept. Two years of changes are still two years of changes, waiting for someone — you, or someone you pay — to work through them one at a time before the app can go out again.

This is the real answer to the question in the title, and it fits in two columns.

On our side: the engine that builds the apps, kept current permanently. Reading the store rules before they apply. Rewriting components before a removal turns into an outage. The chain that delivers your notifications. The SSL certificate of your domain, renewed ahead of every deadline. None of it asks you for a decision, or even asks you to know about it.

On your side, and nobody can do it in your place:

• Your Apple and Google developer accounts. They are in your name — that is what makes the app yours — and they come up for renewal. An expired account pulls the app from the stores, however good what is inside it may be.
• The declarations that describe your content and your data practices. They are about your business, not ours: we can prepare them from the features you actually switched on, but we cannot decide in your place what you do with your users' data.
• The act of sending the update. Every new version goes through store review: the platform gets everything ready, you pull the trigger. If that last one weighs on you, GoodBarber Takes Care is the option where we submit updates to the stores for you.

The list is short. That is deliberate — and each of those lines deserves an article of its own, which is what this series will do.

The real benefit is not technical: it is time. The hours you do not spend reading Apple's release notes, working out what a privacy declaration is, or hunting down why a certificate expired — you spend them on your content, your audience, your business.

It is a hard benefit to advertise, because it does not show: when it works, nothing happens. No demo can prove it; only time verifies it. It is what the platform has been doing, quietly, since 2011.

If the technical detail interests you, I have described elsewhere, from the engineering side, what actually breaks over three years.

The simplest way to see what an app built on this mechanism looks like is to start your own: create my app with GoodBarber.

Will my app still work in three years?

An app left strictly untouched eventually falls behind its environment, and that is true anywhere. The difference is what catching up costs: on a platform that absorbs the changes, the fixes have already been made and are waiting for your app. Bringing it up to date is a rebuild, not a project.

I left my app alone for two years. Is it lost?

No. Nothing lands on an app while it sleeps, but all the work done at platform level in the meantime is waiting for it: at the next rebuild, it comes out to current standards. That is the difference with an app whose source code you have to maintain yourself, where nothing accumulated on your behalf.

Who is responsible for what between the platform and me?

The platform takes on what is common to every app: the engine that builds them, compliance with store rules, replacing dropped components, and the notification infrastructure. You keep your Apple and Google developer accounts, the declarations that describe your content, and the decision to publish updates.

Do you need technical skills to keep an app running over the years?

No, and that is the point: the part that requires them is done once, upstream, for every app. What stays on your side is administrative and editorial — renewing accounts, describing your content, choosing when to publish — not code.

Why is my app slower than it was at launch?

Most of the time nothing has broken: the volume has changed. What was instant on a small catalogue takes more work once it has been growing for years. It is the one movement out of the four that comes from your own success rather than from the outside — and the subject of a coming article in this series.