Four of the five store choices people call permanent are written down. One is not.

Which of these does the documentation actually call permanent?

Seven actions, each with the sentence the store publishes and the page it sits on. Six have a quotable rule. One has nothing, and the honest answer there is that the question is not addressed rather than that the answer is no.

What does Apple say about a bundle ID and an SKU after you remove an app?

It says both are spent, in one warning, on one page. Apple's Remove an app page carries a block that begins by telling you that if you remove an app, you will lose ownership of the app name, and ends: the SKU can't be reused in the same organization and if you've uploaded a build, your bundle ID can't be reused. Three separate consequences in one warning, and no reversal offered for any of them.

The clause worth reading twice is the conditional one. Your bundle ID is not retired by releasing an app. It is retired by uploading a build. That means the identifier is gone for an app that never left TestFlight, never passed review and never had a customer. The same rule appears from the other direction in Apple's App information reference, which says of the bundle ID property that you can't change this property after you upload a build. The upload is the point of no return in both sentences.

The SKU is stricter still, because it is fixed earlier. The same reference page says you can't change the SKU after you add the app to your account. So the SKU is locked at the moment you save the record, and retired for your whole organisation at the moment you remove it. Nobody outside your company ever sees it, which is exactly why it gets typed carelessly. Pick a scheme that survives a restart, something with a date or a counter in it, so that the obvious value is never the one you need twice.

The app name is the softest of the three and still not free. Apple says removed apps can only be restored if the name isn't currently in use by another developer account. So the record is recoverable in principle, from the Removed Apps view, and unrecoverable in practice the moment somebody else registers the name. Apple puts no hold on it for you. The page adds that if the app name is no longer available, the app cannot be restored.

One more permanent flag lives on the App information reference and catches people who build for children. Once an app marked as Made for Kids is approved by App Review, Apple says, this selection cannot be changed, and all subsequent updates will need to follow the Kids category guidelines. That is a product decision disguised as a checkbox, and it changes what you are allowed to ship for the rest of the app's life.

Apple, App Store Connect Help, Remove an app, read 17 October 2026

Can a Google Play package name ever be used again?

Yes, in one case, and Google's two help pages disagree about it. The widely repeated version comes from the Create and set up your app page, which says package names for app files are unique and permanent, so please name them carefully, and that package names can't be deleted or re-used in the future. No exception, no condition.

The Delete an app page, which describes the current self-service deletion flow, splits the same question in two. For a deleted app with zero lifetime installs, it says, the package name will be freed up for reuse by anyone. For a deleted app with any lifetime installs, the package name can't be reused by any other app, including apps created by the developer account that created the deleted app. One install, ever, including your own phone, and the name is retired for everybody.

Both pages are first party and both are live. If you need one answer, the delete page is the one that governs, because it is the page describing the mechanism that frees or retires the name. The blanket sentence on the setup page reads like a safe simplification written before self-service deletion existed. Either way, the practical advice is the same as the blanket version: name it carefully.

Deletion itself is gentler than its name suggests, and the same page says so. You can recover a deleted app within seven days of deleting it, and after the deadline your app is permanently deleted. Google also fences deletion in, though not consistently: the page opens by saying only the account owner has the capability to delete an app, and its requirements list then says you must be an admin of the developer account. Either way the app must be unpublished with no changes in review, it must not be rejected, blocked or suspended, and it must be installed on fewer than 1,000 active devices, where an active device is one turned on at least once in the past 30 days. Monetised apps are excluded from the self-service route unless they have zero lifetime installs.

The upshot for anyone testing an idea: a throwaway Play listing you never installed costs you nothing. One you shipped to a single tester costs you the name. That asymmetry is worth knowing before you reserve a package name for an experiment, and it sits oddly next to what an app costs to maintain, where everything else is a monthly number you can stop paying.

Google, Play Console Help, Delete an app, read 17 October 2026

Does Apple say you can undo a release to all users?

It does not say either way, and that is the finding. Apple does not say the button can be undone, and it does not say it cannot. We read the whole of the Release a version update in phases page on 17 October 2026, plus the two adjacent pages where a reversal would be documented, Select an App Store version release option and Make a version unavailable for download. None of them addresses whether Release to All Users can be taken back. That is an absence in the documentation, and we are not going to dress it up as a rule.

What the page does cover, in detail, is the reversible part. During a phased release you may pause the release for up to 30 days, with no limit on the number of pauses, and Apple gives the arithmetic: pause for 10 days, resume, and you have 20 days of pause left. If you resume a release that was previously paused, the phased release picks up on the day it was left off. A staged rollout is therefore far more controllable than most people think, right up to the button nobody documents.

The page does document one hard stop, for a different trigger. If you remove your app from sale, which includes the case where your Apple Developer Program membership lapses, phased release will stop and will not be available for that version again. When the app is reinstated it becomes available to all users immediately, whatever percentage it had reached. So a lapsed membership does what people fear the button does, and Apple says that one out loud.

There is also a documented way back to a controlled rollout, which is the closest thing to an answer. Apple tells you to make the version unavailable for download and submit a new version update with phased release enabled. Read that as the shape of the real constraint: a new rollout needs a new version. If you want the mechanics of the rollout itself, we cover a phased release separately, including the day by day percentages.

Compare that with the release action Apple does document an undo for. On the version release options page, after you manually release an approved version, Apple says that to cancel the release, select Cancel This Release from the message on the version page. One button has a published escape hatch. The other has silence. Plan as though Release to All Users is final, because nothing tells you it is not, but do not repeat that as a rule, because Apple has not written it.

The rating reset is the clearest sentence of the five

Apple's Reset an app overview rating page puts the permanence in its own note, in plain words: once you release the new version of your app, you won't be able to restore the previous rating. There is no ambiguity to interpret and no adjacent page to check. This is what a documented irreversible action looks like, and it is the standard the other four should be measured against.

The timing matters more than the warning. The reset is a tick box on an unreleased version, labelled to reset the rating when that version is released. Until the version ships it is a setting you can clear. After it ships the old rating is gone. So the decision point is the release, not the tick, which gives you the whole review period to change your mind.

Two more details from that page change whether it is a good idea. The reset applies to all regions or countries simultaneously, so you cannot clear a bad rating in one market and keep a good one in another. And it does not touch written reviews, which carry on displaying on the App Store. Resetting a one star average while seven angry one star reviews stay at the top of your product page is a worse outcome than leaving it alone.

Two narrower limits are worth knowing. For universal apps the reset only applies to the platform version you reset it for, and you cannot reset the rating of app bundles at all. Apple also notes that a message appears on your product page saying the rating was recently reset, so the reset is visible to customers rather than silent, and a new overview rating only appears once enough people have rated the new version.

Documented as permanent, and documented as reversible

Every row below is a sentence in first-party help, read on 17 October 2026. Where a row says not addressed, that is what the documentation does, and the honest answer is that nobody has published one.

The two pages the rows above lean on hardest: Apple, Remove an app and Google, Delete an app. The rows citing Reset an app overview rating, App information, Release a version update in phases and Select a version release option come from those four App Store Connect Help pages, each read on the same day.

Where this lands if a builder generated your app

None of these rules change because an agent wrote the code, and the one who presses the irreversible buttons is still you. App Store Review Guideline 4.2.6 is why: apps created from a commercialized template or app generation service are rejected unless they are submitted directly by the provider of the app's content. That puts the App Store Connect record, the bundle ID, the SKU and the rating reset in your account, not the tool's.

Newly is an AI app builder. You describe an app and it generates a real React Native and Expo project you own. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, builds a standalone Android APK, and keeps two way GitHub sync so the code stays yours. It is $25 a month, with no free tier. It does not submit to the App Store on your behalf, for the reason above.

The one place this intersects a generated app is the first upload. Getting a build to TestFlight is the step that retires a bundle ID, and a builder makes that step cheap enough to do on a whim. So settle the identifier before the first upload rather than after: decide the reverse domain name you actually want, decide an SKU scheme with a counter in it, and keep the throwaway experiments on a package name you are willing to lose. Everything downstream of that first upload has an undo documented somewhere. The identifiers do not.

Questions people ask about irreversible store decisions

Settle the identifiers, then build the thing

Write down the bundle ID, the SKU and the package name you want before you create a single record. Those are the only choices on this page that nobody has published a way back from.