Removal and suspension: what to do, in order
A removal is not a rejection. It takes down the live app, and it happens without a review cycle in front of it.
The order to work in, and the first step is the one people skip:
1. Read the notice properly and write down exactly what it cites. The policy or guideline named, and the specific behaviour or asset described. Not what you assume it means.
2. Reproduce it. Does the app actually do what the notice says. Frequently it does, in a way you had not framed that way, and that framing is the fix.
3. Fix it, then appeal. In that order. An appeal that says "we have removed the thing" is a different document from one that says "we disagree."
4. Tell your users, through a channel that is not the app.
Appeal factually. What was cited, what the app does, what changed, and evidence. Arguing that the policy is unfair, or that other apps do the same thing, does not work and consumes the one submission where your credibility matters most.
Plan for the outage, not for a fast reversal. Neither store guarantees appeal timing and appeals are frequently slower than ordinary review.
And the preparation that makes all of this survivable is boring: a data export path, and a way to reach your users that does not depend on the app being installable.
Removal versus suspension
App removal. One app comes down. The installed copies generally keep working; the listing is gone, so no new installs. Serious and recoverable.
Account suspension or termination. Everything you have published is affected. This is a different order of problem, it usually follows repeated violations or something treated as egregious, and it is the reason not to treat individual warnings as noise.
The escalation path is the thing to notice. Stores do not usually jump to account action without prior signals. Warnings are the cheap part of this process, and the developers who end up at the expensive end are frequently the ones who dismissed the cheap part.
The appeal that works
Short, factual, structured so a busy reviewer can act:
Notice received [date] citing [policy], regarding [specific thing].
What the app does: [two lines, plainly]
What we found: [the actual behaviour, honestly, including if the
notice was right]
What we changed: [specific, with version number]
Evidence: [screen recording, the code path, the removed asset]
We are not asking for an exception. Version 2.4.1 no longer [does the
thing], and we would like the listing reinstated."We are not asking for an exception" is doing real work in that template. It signals that you understood the policy rather than that you would like it waived, and those are the two categories every appeal gets sorted into.
What to leave out: other apps, your revenue, your timeline, how long you have been a developer, and any characterisation of the reviewer's judgement.
Telling your users
This is where preparation decides the outcome.
If you can email your users, do it the same day. Plain, factual, no blame. What happened, what it means for them, what you are doing, and when you will update them.
If you cannot reach them, you have found your real problem, and it is worth fixing regardless of how this resolves. An app whose only channel to its users is the app itself has no channel at all in the situation where it matters.
Give them their data. An export path that works without the store is the difference between a policy problem and a betrayal. It is also increasingly expected by regulators and by users independently of any of this.
The preparation, in advance
Four things, none of which is expensive before you need them:
A data export path. In-app, and a documented way to request it if the app is unavailable.
A contact channel that is not the app. Email, or a website with a working address. Guideline 1.2 requires published contact information anyway if you have user content.
A status page or a website you control. Somewhere to say what is happening that does not depend on either store.
Backups of your listing assets and metadata. Descriptions, screenshots, keywords, previews. Rebuilding a listing from memory during an outage is a bad afternoon.
The causes worth pre-empting
Removals cluster around a small number of things, all of which have their own page here:
- Guideline 5.2, intellectual property — often triggered by a rights holder's complaint after release rather than at review.
- Guideline 1.2, user-generated content — missing safeguards, usually surfaced by a report.
- Guideline 4.3, spam and 4.1, copycats.
- Guideline 3.2.2, unacceptable business practices — including manipulated reviews.
- Play policy areas, particularly data safety mismatches and permissions.
The pattern across all of them: the thing that gets you removed is usually something that was true at submission and was not noticed. Which is the argument for running the full pass rather than only fixing what you were last told about. After a rejection. · The first-submission checklist.
shipcheck runs that pass over the project and cites the clause for each finding. What it checks.
More in this section
About shipcheck
shipcheck is a pre-submission checker from Baker Ventures LLC that runs inside Claude Code. It reads your React Native or Expo project, finds the things that get apps rejected or blocked at upload, cites the exact App Store Review Guideline or Google Play policy clause, and names the file and line to fix.
It exists because React Native and Expo apps fail for reasons that are invisible in the code you wrote: capability arriving through a dependency, purpose strings added by a config plugin, a privacy manifest missing from an SDK you never chose directly, and a generated ios/ directory that discards your edits on the next prebuild. shipcheck checks what the binary and the config actually declare, not what you intended. The rejection references on this site are free, need no account, and link to the primary Apple or Google document for every claim.
Questions and answers
What is the difference between a rejection and a removal?
A rejection blocks a new version and leaves the live app alone. A removal takes the live app down, which stops new installs and can affect existing users' ability to reinstall, and it happens without a review cycle in front of it.
Can you appeal an app removal?
Both stores provide appeal routes. What works is a factual submission: what the notice cited, what the app actually does, what you have changed, and evidence. What does not work is arguing that the policy is unfair or that other apps do the same thing.
What gets an account suspended rather than an app removed?
Repeated policy violations, attempts to circumvent review, fraudulent activity, and violations Google or Apple treat as egregious. An account-level action affects everything you have published, which is why it is a different order of problem.
Do users lose their data if the app is removed?
The app usually keeps working on devices where it is installed, and it disappears from the store. Whether users can reinstall, and what happens to your backend, depends on the situation and on how your app is built, which is exactly why a data export path matters before anything goes wrong.
How long does an appeal take?
Neither store guarantees a time, and appeals frequently take longer than a normal review. Plan for the outage rather than for a fast reversal, because the timing is not something you control.
What is the single best preparation?
An export path for user data and a way to reach your users that is not the app. If you cannot email your users and they cannot get their data out, a removal turns a policy problem into a relationship problem you cannot repair.
shipcheck. “Removal and suspension: what to do, in order.” Baker Ventures LLC, September 7, 2026. https://shipcheck.bakerventuresstudio.com/guides/handling-an-app-removal-or-suspension/