Sunsetting a mobile app — how to remove it from the store and shut down the backend safely

Not every app has to live forever. The product didn't find its market, the company changed its business model, the features moved to a web app, or the maintenance cost stopped making sense. Deciding to sunset an app can be a perfectly rational call — the trouble starts when sunsetting means clicking "Unpublish" in the console and switching off the server.

An app removed from the store doesn't disappear from phones. Users who have it keep opening it, subscriptions may keep renewing, and personal data still sits in your database and in third-party services. Below we describe how to sunset an app step by step without leaving behind complaints, legal risk, or a domain that a stranger can pick up.

First, check whether sunsetting is the only option

Before you plan a shutdown, compare it with cheaper alternatives. Often the problem isn't the app itself, but what its current maintenance costs.

If you're considering minimal maintenance, a good reference point is our article on how much mobile app maintenance costs. Handing an app over to another company is covered in the article on transferring an app to another Google Play and App Store account.

What actually happens after you remove an app from the store

This is the most important point of the whole process: removing an app from the store blocks new users, but doesn't cut off existing ones.

The practical takeaway: for a long time after removal, the app still runs on phones and calls your backend. If you shut down the server without warning, users will see errors, blank screens, or crashes — and leave one-star reviews for an app that's no longer in the store.

Removing an app from sale is not the same as deleting it from your account. Deletion can't be undone, so don't do it at the start of the process — ideally not at all, especially since both platforms let you keep a removed app in the console at no cost beyond the developer account fee.

Sunset plan, step by step

Order matters. The schedule below assumes roughly three months from decision to backend shutdown — for apps with paid annual subscriptions, it needs to be longer.

Subscriptions and payments

This is where complaints and store-policy trouble come from most easily.

App Store. Apple's App Store Connect documentation recommends removing the subscription from sale ("Removing from Sale") before discontinuing the service — this stops new sign-ups and renewals. At least 31 days must pass between removing the subscription from sale and stopping the service, so that monthly subscriptions can expire. The Paid Apps Agreement requires you to deliver content for the full paid period; for subscriptions longer than a month, if you can't do that, Apple asks you to contact support. Apple also recommends notifying subscribers at least 31 days in advance.

Google Play. Google Play's user help says that when an app is removed from Google Play, future subscription renewals are cancelled. Still, don't build your plan on removing the app alone. It's safer to stop sales in the console first and cancel active subscriptions through the Google Play Developer API, ahead of time and with a message to users. Users keep access until the end of the paid period, so the backend has to support them.

Payments outside the stores (cards, bank transfers, BLIK in apps selling physical goods or services) are handled under your own terms and your agreement with the payment provider. Plan refunds for unused periods and check whether your terms provide for ending the service at all.

The final app version

The last update is the most important release in the sunset process. It should include:

• A service-ending notice with the date and what will happen to the data.
• Data export, if users keep something valuable in the app (history, documents, photos). The GDPR right to data portability doesn't cover every case, but a user who didn't manage to download their data will complain anyway.
• A remote switch (remote config or an endpoint with a flag) that shows a "service ended" screen instead of network errors once the backend is off. We described the same mechanism in the article on forcing updates and a minimum supported version — if the app already has it, just use it.
• Disabling SDKs that no longer need to send anything: analytics, ads, marketing automation.

Remember that this release goes through normal store review and must meet current requirements, including the target API level on Android. If the app hasn't been updated for a long time, preparing the final version alone may take more work than the notice itself — we explain why in the article on deprecated SDKs and APIs.

Personal data and GDPR

Ending the service doesn't end your obligations as a data controller. Sunsetting is a good moment to put them in order, and a bad moment to forget about them.

• Decide what you delete and what you must keep. User account data usually loses its legal basis together with the service. Accounting records — invoices, transaction data — must be kept as tax law requires; in Poland this is usually 5 years from the end of the year in which the tax payment was due.
• Don't forget backups. Deleting records from the production database doesn't remove them from backups. Write down when the last copies containing the data will expire.
• Go through your processors. Firebase, analytics and crash reporting tools, email and push providers — each of them holds your users' data. Delete the projects or data and keep the confirmations.
• Update the privacy policy and tell users when and what data will be deleted.
• Keep the account deletion path working as long as the data exists. Google Play requires apps with user accounts to offer account deletion outside the app as well — details in our article on privacy requirements in Google Play and the App Store.
• Document the whole process. The accountability principle means that if asked, you have to show what you did with the data and when.

Backend, domains and accounts

Shutting down infrastructure has its own order too.

1. Limited mode first, then shutdown. For a few weeks, the backend handles login, reading, and data export, but doesn't accept new writes or payments.
2. Keep a permanent endpoint with a message. Even after the real API is off, it's worth keeping a simple response for a while, which the app turns into a "service ended" screen. The cost is negligible.
3. Don't let the domain go. Apps on phones will keep sending requests to the API address hard-coded in them for years — sometimes with session tokens. If the domain expires and a stranger buys it, they get that traffic. Paying for the domain for a few more years is the cheapest safeguard in the whole process.
4. Revoke keys and secrets. API keys for third-party services, push certificates, service accounts — anything that could have ended up in the app's code or the repository.
5. Cancel services in dependency order. First whatever costs money and processes data; the domain and developer accounts go last.
6. Archive the project. Keep the code, documentation, signing keys, and the account register in one place. If someone decides to bring the product back in a year, the technical documentation will decide whether that takes a few days or a few months.

It's worth keeping the Apple developer account at least until the subscription period ends: apps from an account whose membership has expired are no longer available on the App Store. The Google Play account has no annual fee, so just make sure more than one person has access to it.

How much does sunsetting an app cost

For a typical app with user accounts and a backend, sunsetting usually takes 20–60 hours of work: inventory, the final app version, the backend's limited mode, and cleaning up data and services. At an example rate of PLN 180 net per hour, that's roughly PLN 3.6k–10.8k net. On top of that come running costs during the transition (hosting, domain, Apple account) and any refunds for subscribers.

The amount goes up if the app hasn't been updated for a long time and the final version needs an SDK upgrade, if data is scattered across many services, or if nobody has a complete list of accounts. The rate and scope are indicative — the real cost depends on the state of the project.

The most common mistakes

• Shutting down the backend on the day the app is removed from the store.
• Leaving active subscriptions that keep renewing for a service that no longer works.
• Deleting the app from the account instead of removing it from sale — with no way back.
• Deleting the production database without checking what has to be kept for accounting.
• Letting the domain lapse while installed apps still send requests to it.
• No message for users — they learn about the shutdown from an error.

Summary

A good mobile app sunset is a few weeks of planned work, not a single click. First stop sales and warn users, then ship the final version with a notice and data export, remove the app from the stores, and shut the backend down gradually. Finally, clean up personal data, revoke keys, keep the domain, and archive the project so it can be revived.

If you're not sure whether to sunset the app or keep it on minimal maintenance, request a free app analysis — we'll assess the state of the mobile app and suggest which option makes sense. We also carry out sunsets as part of mobile app maintenance, and when the team that built the app is no longer available, we start with an app takeover. We'll work out the details via contact.