What Happens to Your App If You Never Update It

An app you stop maintaining does not break on any particular Tuesday. It degrades in stages, and most of those stages are scheduled by Apple and Google rather than by anything in your code. Once you know the schedule, you can decide how much maintenance you actually need instead of paying for a retainer you have no way to evaluate.

Here is the honest sequence, in the order it happens.

Stage one: nothing, for a while

For the first several months after launch, an app that nobody touches usually keeps working exactly as shipped. The binary your users installed runs on their phones. Your backend keeps serving requests. Nothing on the store changes.

This is the part that misleads people. The absence of visible failure in month three is not evidence that maintenance is optional. It only means the clocks that matter have not run out yet.

Stage two: you lose the ability to ship an update

The first hard deadline is not about your app being removed. It is about your app becoming frozen.

Both stores require that anything you submit is built against a recent toolchain, and both enforce it at the upload step. As of August 2026:

• Apple. Since April 28, 2026, apps and updates uploaded to App Store Connect must be built with the iOS 26 SDK or later, per Apple's own developer announcement. Apple repeats a requirement in this shape roughly every spring, keyed to the previous autumn's OS release.
• Google. Since August 31, 2026, new apps and updates must target Android 16 (API level 36) or higher, per Google Play's target API level policy. Standard apps could request an extension to November 1, 2026.

Neither rule takes your app off the store. Both stop you from changing it. That distinction matters more than it sounds, because the moment you need an urgent fix — a broken login, a payment provider that changed its API, a crash on a new phone — you discover that shipping the fix now requires a toolchain upgrade first. A one-day fix becomes a two-week project, and it starts on the worst possible day.

We covered the Android side of this in detail when the deadline landed, in the Google Play target API post.

Stage three: new users quietly stop finding your Android app

Google's target API policy has a second effect that is easy to miss, because nothing appears broken. If your published app targets an older API level, Google Play's policy states that it will stop being available to Google Play users whose devices run Android versions newer than your app's target API level. Users who already installed it are explicitly unaffected — they can keep using it and re-install it.

So your reviews stay up, your existing users stay happy, and your install rate declines month over month as more of the market moves to newer Android versions. There is no error message and no email announcing it. If you only watch crash reports, you will not see this at all. Watch installs by Android version instead.

Stage four: Apple may pull the listing

Apple does remove long-abandoned listings, but the criteria are narrower than the rumour suggests. Per Apple's App Store Improvements page, an app is flagged only when it meets both conditions: it has not been updated in the last three years, and it fails a minimal download threshold, meaning it has had no or extremely few downloads over a rolling twelve months. Flagged developers get an email and 90 days to submit an update.

If your app has real users, that rule will probably never touch you. The sentence on the same page that should worry you is the other one: apps that crash on launch are removed immediately, with no grace period. An unmaintained app that stops launching on a new iOS release is exactly the app that hits that rule, and by then you are also stuck in stage two and cannot ship the fix quickly.

The bills that run whether or not anyone opens the code

Maintenance is not only developer time. These are the recurring line items, checked against each vendor's own page as of August 2026:

• Apple Developer Program: 99 USD per year. If the membership lapses, your apps come off the App Store.
• Google Play developer account: a 25 USD one-time registration fee, not recurring.
• Backend hosting and storage: anywhere from nothing on a free tier to hundreds per month, scaling with usage rather than with time.
• Third-party services: maps, SMS, email, payments, analytics. Each has its own pricing page and its own deprecation schedule.
• Domain and marketing site: small, but it lapses silently.

Every one of those lives in an account, and whose name is on the account decides whether you can pay a bill without asking permission first. That is why we put them in the client's name before writing code, which we explain in who owns your app.

What actually rots in the code

Store policy is the scheduled part. The code has its own decay, and it is less predictable:

• Certificates and keys expire. Signing certificates, push notification credentials and API keys all have end dates. An expired push certificate stops notifications with no code change and no crash to report.
• Dependencies go stale. The libraries your app leans on ship new versions and drop support for old ones. Leave it long enough and upgrading one forces upgrading five.
• Integrations change under you. A payment or login provider deprecates an endpoint on its own timetable, not yours.
• New hardware exposes layout assumptions. A screen size or aspect ratio nobody tested against turns a clean screen into a clipped one.

As an illustrative scenario, take an app built in early 2025 and untouched since. Today it would need an SDK and target-API upgrade before any change could be uploaded to either store. It would likely need several dependency bumps before it compiles at all. And it might have a lapsed push certificate that nobody has noticed, because nothing generates a report when notifications simply stop arriving. None of that is a defect in the original build. It is the cost of standing still while two platforms move.

What a maintenance plan should actually cover

If you are evaluating a retainer, the useful question is not how many hours it includes. It is which of these are named in writing:

1. One toolchain and target-API upgrade per platform per year, timed to the store deadlines rather than to a crisis.
2. Dependency and certificate renewals, with the expiry dates tracked somewhere you can see them.
3. A defined response time for crashes and store rejections, and who pays for the fix.
4. Someone watching installs and crash rates, not only the support inbox.
5. A named place your source code and accounts live, so a lapsed retainer is inconvenient rather than fatal.

For budgeting, we tell clients to set aside roughly ten to twenty percent of the original build cost per year for an app the business depends on, and more in the first year while early issues surface. Our build ranges are on the pricing page, and the reasoning behind them is in our cost breakdown.

When you genuinely do not need a retainer

We are the wrong fit for some of this, and it is worth saying plainly.

If your app is a small internal tool with a known user group, no payments and no backend, a scheduled annual upgrade is enough and a monthly retainer is money you should keep. If you already have a competent in-house developer, you do not need us running dependency upgrades — you need them to have the store deadlines on a calendar. And if the app was a marketing experiment that never found users, the honest advice is to let it lapse deliberately rather than pay to keep alive something nobody opens.

A retainer earns its keep when the app is load-bearing: it takes payments, holds customer data, or is how your customers reach you. There, being frozen for two weeks at the wrong moment costs more than a year of maintenance.

If you want a second opinion on which of those describes your app, book a call and bring the date of your last store submission. That single number tells us most of what we need to know.

---

Your app. In the stores. Done for you. US APP Team designs, builds, and launches your iOS and Android app for a fixed price. Start your app brief or book a free intro call — both are free.

Want to poke around first? Every tool in our free tool library runs in your browser with no signup: an app cost calculator, an app name generator, and a privacy policy generator.