Retiring an app properly means taking it off sale, because deleting it cannot be undone.
There are three settings, not one. Off sale on the App Store, unpublished on Google Play, and deleted. The first two stop new downloads and leave everyone who already has the app exactly where they were, updates included. The third erases the record, takes the name with it, and on Google Play gives you seven days to change your mind. Almost nobody needs the third one. People reach for it because they are tired of paying for what an app costs to maintain, and off sale solves that without burning anything.
Every screen name, waiting period and limit below comes from Apple and Google's own help pages, read on 16 October 2026. Where their documentation does not answer a question, this page says so rather than filling the gap.
Start hereThe short version
Off sale is a switch. Deleted is a shredder.
Take the app off sale on the App Store and unpublish it on Google Play. That is the whole job for most retirements. New downloads stop. The people who already installed it keep it, keep using it, and keep receiving any update you ship. You can turn both switches back on later.
Deleting is the different thing. Apple removes the record from your account and you give up the app name, the SKU and the bundle ID. Google permanently deletes after a seven day recovery window, and only lets you do it at all if the app is small, unpublished and never made money. Apple also makes you handle the money before the listing: any in-app purchase has to come off sale first, and Apple asks for at least 31 days of notice before you remove one.
What happens to the people who already have your app?
They keep it. Apple is direct about this. On the App Store side you open Pricing and Availability, scroll to the bottom, and click Remove App From Sale, and your app is removed from the App Store in all countries or regions within 24 hours. The sentence that follows is the one worth reading twice: users who previously downloaded your app will continue to receive app updates, and the app can be redownloaded from a customer's purchase history as long as the necessary contract remains active. Nothing is taken off anybody's phone.
Google Play behaves the same way under a different word. Unpublish an app and existing users can still use it and receive app updates, while new users will not find and download it on Google Play. The switch lives in Test and release, Setup, Advanced settings, on the App Availability tab. Google asks for three things first: that you have accepted the latest Developer Distribution Agreement, that the app has no outstanding errors such as an unfinished content rating questionnaire, and that managed publishing is not active for that app.
Pulling out of one country rather than all of them is the same mechanism, scoped. Under App Availability you click Manage, then Manage Availability, and deselect countries. Apple notes that deselecting a country removes the app there, that the same re-download rule applies, and that changes take effect immediately but may require up to 24 hours to be visible to all users. If you only want out of a market because of tax or support load, this is the switch, not the big one at the bottom of the page.
One caveat is buried in Apple's phrasing. Re-download works while the necessary contract remains active, and a lapsed Apple Developer Program membership is not an active contract. Apple's own renewal page says that when a membership expires your apps are no longer available for download, though they still function for users who have already installed or downloaded them. A customer with the app on their phone is fine. The same customer on a new phone is not. If you are about to retire an app, decide the membership question deliberately instead of letting the renewal date decide it for you.
App Store Connect Help, manage availability for your app on the App Store, read 16 October 2026
Pick the outcome
What you want, and the switch that does it
Tick what you are actually trying to achieve. The screen names are the ones each console uses today.
Nothing ticked. Most people who think they want to delete an app want the first row: no new downloads, nobody loses anything.
Is unpublishing the same as deleting?
No, and Google keeps them on separate help pages for a reason. Unpublishing is a toggle. Deleting is a one-way door with a bouncer on it. Play Console Help says only the account owner can delete an app, and lists what the app has to be first. It must be unpublished, with any changes in review resolved. It must be installed on fewer than 1,000 active devices, where an active device is one that has been turned on at least once in the past 30 days. It must not be rejected, blocked or suspended.
There is a further exclusion that catches most apps worth retiring. Self-service deletion does not cover monetised apps, meaning paid apps or apps with in-app purchases or subscriptions, unless they have zero lifetime installs. If your app ever took money and ever had a user, you cannot delete it yourself and have to contact support. Which is a polite way of saying that for a real app, unpublished is the end state, and you should stop looking for the delete button.
If you do qualify, the flow is deliberately awkward. The Delete app section only appears on the App availability tab when the app meets the requirements, and confirming means typing the app's package name and your developer account creation transaction ID, which you dig out of the Developer registration fee receipt or the Google Payments activity log. Then you get a seven day window: Google says you can recover a deleted app within seven days, and after the deadline it is permanently deleted. A deleted app cannot be transferred, console navigation for it becomes restricted, and you lose access to all user data and metrics.
Package names split by install history, and the split is permanent. A deleted app with zero lifetime installs has its package name freed up for reuse by anyone. A deleted app with any lifetime installs has a package name that cannot be reused by any other app, including apps created by the developer account that created the deleted one. So deleting a failed experiment to reclaim its name works. Deleting a shipped app to reclaim its name does not, and you have thrown away the metrics for nothing.
What has to be switched off before you pull the listing?
On the App Store, the money goes first. Before you can remove an app from your main view in Apps, Apple requires you to remove it from the App Store for all countries and regions, even if the app was never released, and to remove any associated In-App Purchases from sale. If you also distribute through an alternative app marketplace, you deselect the app from each marketplace in the Integrations tab under Users and Access. Removing the record needs the Account Holder or Admin role, and the button sits under App Information, in the Additional Information section.
Retiring an in-app purchase has a clock on it. Apple tells you to announce your intention to remove it and to stop merchandising it inside your app at least 31 days before removal, so people can use up any consumable products they already bought. End any promotions of it. Notify Apple, which reserves the right to offer refunds for unfulfilled in-app purchases. That page does not say what happens to an auto-renewable subscriber's renewals, so do not assume either way. If payments were the reason the app existed, revisit which payment layer to use before you wind anything down, because where the subscription lives decides who can cancel it and who issues the refunds.
Some states block removal outright. Apple will not let you remove an app that is Ready for Review, Waiting for Review, In Review, Metadata Rejected or Rejected. Apps actively being transferred to another account cannot be removed, and neither can apps that are part of an app bundle, which has to be dismantled first. App bundles themselves cannot be removed at all. In practice this means waiting out a review you no longer care about before you can tidy up.
Then the warning Apple puts in capital letters. If you remove an app, you lose ownership of the app name. Removed apps can only be restored if the name is not currently in use by another developer account, the SKU cannot be reused in the same organization, and if you have uploaded a build your bundle ID cannot be reused either. Restoring is a real option, under Removed Apps with a Restore App button, but it is conditional on nobody having taken the name while you were gone. If there is any chance you will come back, off sale is where you stop.
App Store Connect Help, manage availability for your app on the App Store, read 16 October 2026
What do you owe the people who used it?
Notice, their data, and a way to reach you. None of that is in the store consoles, which is exactly why it gets skipped. Start with a final update: a plain screen that says the date the app stops being supported, what happens to anything they stored in it, and how to get it out. That update is a release like any other, so a phased release lets you put it in front of a slice of users and watch the support email before the rest see it.
Order matters here, and people get it backwards. Ship the goodbye update while the app is still on sale, then take it off sale. Apple keeps delivering updates to previous downloaders after removal, so the sequence survives either way, but you cannot submit a new version through a lapsed membership, and you cannot push an update to a deleted Play listing at all. One build, then the switches.
Keep the back end alive longer than the listing. An app that is off sale still runs on thousands of phones, and every one of them will call your API until the person deletes it. Turning the server off on the same day you unpublish is how a retirement turns into a support queue. Pick a shutdown date, put it in the app, and keep sign-in and data export working until it passes. Budget for that gap the way you would budget what it costs to publish an app, because retiring one is not free either.
Then take your own records out. Deleting on Google Play means losing access to all user data and metrics, so download your install and revenue reports, your crash history and your reviews first. Keep the developer account itself: the Play registration fee is a one-time US$25 charge, so an account with nothing published costs nothing to hold, and it is the only place your history lives. On the Apple side a lapse is heavier than it looks, because 30 days before expiry you can download your registered test device list and choose whether devices are removed at expiry, and if you do nothing they are removed automatically 180 days later.
The same decision, screen by screen
| The step | App Store | Google Play | Can you undo it |
|---|---|---|---|
| Stop new downloads | Remove App From Sale, under Pricing and Availability | Unpublish, on the App Availability tab | Yes |
| How long it takes | Within 24 hours in all countries or regions | No time stated on the unpublish page | No |
| People who already have it keep it | Yes | Yes | Yes |
| They still get updates you ship | Yes | Yes | Yes |
| Erase the record from the console | Remove App, under App Information | Delete app, under 1,000 active devices | No |
| The name comes back for reuse | No | Only with zero lifetime installs | No |
| A window to change your mind | Restore App, if nobody took the name | Seven days, then permanent | No |
Where this lands if a builder generated your app
The store side is identical. You hold the developer accounts, you click Remove App From Sale, you type the package name into the delete dialog. A builder is not a party to any of it. On iOS that is structural rather than a policy choice, because App Store Review Guideline 4.2.6 rejects apps created from a commercialized template or app generation service unless they are submitted directly by the provider of the app's content. The owner submits, so the owner retires.
What differs is what is left when the listing goes. Newly is an AI app builder: you describe an app in plain English and it writes a real React Native and Expo project that you own, with two-way GitHub sync. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK, and it does not submit to the App Store for you, for the reason above. It costs from $25 a month, with no free tier. Retiring the app does not touch the repository, so the project outlives the listing and a developer can pick it up later.
That is worth checking wherever your app came from. Ask one question of any builder before you commit: if I stop paying tomorrow, what can I download, and does it build without you? The honest limit here is that owning the code solves ownership and nothing else. An app with a server behind it still needs that server running while people still have the app, and no amount of source control changes the shutdown date you owe your users.
Questions people ask about retiring an app
No. App Store Connect Help says that when you remove your app from the App Store in all countries or regions, it is gone from the store within 24 hours, and that users who previously downloaded it will continue to receive app updates. It also says the app can be redownloaded from a customer's purchase history as long as the necessary contract remains active. So the copy on the phone keeps working, a reinstall is still possible, and if you ship a final update it still reaches them. Google says the same thing about unpublishing: existing users can still use your app and receive app updates, but new users will not find and download it on Google Play.
Build the next one so it can be handed over
Own the repository, keep the developer accounts in your own name, and write the shutdown date into the app before you need it. A retirement is then an afternoon of switches instead of a decision you cannot reverse.
Start building