Your app was rejected. Here is what to do.

The notice in App Store Connect says which guideline the app broke and what App Review saw. Start there, not with guesses.

App Review notifies users with the Admin, App Manager or Developer role of rejection issues. The full reason is the App Review message in App Store Connect (Apple, App and submission statuses, checked 22 October 2026).

Apple's guidelines ask for a complete, usable submission, an accurate listing, working reviewer access where the app needs it, and honest privacy disclosures. These are some of Apple's official criteria. They're not a ranking, and we don't rank them.

Diagnose by cause. Find the guideline number in your notice, then look for the row that matches.

Source: Apple, App Review Guidelines, checked 22 October 2026.

Change what the notice cites, and nothing else first. Then test the exact path that failed, on a supported device.

Our working sheet. This is our advice, not an Apple form. One row per rejection:

• Store, app and build version.
• The full cited guideline.
• How the reviewer reproduced the problem.
• What you changed.
• Proof it is fixed: a screenshot or a short recording of the failing path working.
• Listing and disclosure changes.
• Next action.

Three kinds of fix. Name yours before you act.

• A clarification. The reviewer misread the app. Reply to App Review with the detail. Nothing changes in the app.
• A metadata-only fix. The problem is in your listing or disclosures, not the app. Apple says a metadata-only fix may reuse the same build (Apple, Reply to App Review messages, checked 22 October 2026).
• A build fix. The problem is in the app's code or flow. Upload a new build. If the notice cites 4.2 (the app is little more than a website), reply only if the reviewer missed features the app already has. Otherwise it needs a build fix that adds real use beyond the website.

Our advice, not Apple's rule: don't resubmit unchanged. If you are only clarifying, reply instead.

We won't give a review time. Apple's review page reports an average, not a deadline (checked 22 October 2026).

If Apple missed something, reply to App Review with detail in App Store Connect. If you disagree with the outcome of the review, you can submit an appeal to the App Review Board. Nobody can promise the result.

Apple says an appeal "may help" get your app on the store. It doesn't promise an outcome (Apple, App Review Guidelines, After You Submit, checked 22 October 2026).

A reply fits when you are sure the reviewer missed something, or you want to give more information. Apple asks you to use App Store Connect to talk to the App Review team directly.

A fix fits when the notice is right. Replying won't change a rule.

Keep a reply short and specific:

• The guideline number.
• What you did.
• How to reproduce it.
• Your evidence.

Sources: Apple, App Review Guidelines and Appeal to the App Review Board, checked 22 October 2026.

Open Policy status in Play Console, read the policy it cites, fix that, then resubmit. Repeated unchanged submissions are not a fix.

From Google Play Console Help, checked 22 October 2026:

• The Functionality, Content and User Experience policy lists limited utility or content, and broken or crashing behaviour, as violations.
• The User Data policy requires transparent data handling and the right disclosures, including for third-party code.
• A rejected update leaves your previous published version available. Removal and suspension are different outcomes.

Our advice: don't make a new account to get around a rejection.

If what you got is a request for more testing before production access, that is Google's testing gate, not a policy rejection. See Get 12 testers for Google Play.

Sources: Google Play Console Help, Policy status, Functionality, Content and User Experience, User Data and Enforcement Process, checked 22 October 2026.

If your app lets people create an account, both stores want a way to delete it from inside the app, with some exceptions. If your app uses another company's login for the main account, Apple wants an equivalent login option too, with some exceptions. Not every app needs Sign in with Apple.

Apple, account deletion (5.1.1(v)). If the app supports account creation, users must be able to start deletion inside the app. Deactivation alone is not enough. Delete the account data, except what the law requires you to keep, and explain the process. Apple's support page covers confirmation steps, finishing on a website and regulated industries. Source: Apple, Offering account deletion in your app, checked 22 October 2026.

Apple, login services (4.8). This applies when the app uses a third-party or social login for the primary account. Then it needs an equivalent login option that limits data collection to name and email, lets the user keep their email private, and doesn't use their interactions for advertising without consent. Exceptions include apps that only use their own account system, required education or enterprise accounts, and clients for a specific third-party service. That list is partial. Read the full guideline: 4.8 Login Services, checked 22 October 2026.

Google Play, account and data deletion. For in-scope apps that allow account creation, you need a discoverable route to request deletion inside the app, and a web link to a deletion request, set in Play Console. Delete the associated data and explain any legitimate retention. Deactivation does not count. Exceptions exist, for example certain private or enterprise apps and non-mobile surfaces. Sources: Google Play, User Data policy and Understanding Google Play's app account deletion requirements, checked 22 October 2026.

This is store policy, not legal advice. How long you must keep data depends on where you operate, and we state no deadline.

Treat each new notice as a new row in your sheet. Don't assume the old fixes still hold.

A developer posted in r/iOSProgramming on 22 March 2026 about being rejected five times before approval. They make a social app, and they describe several different issues across repeated reviews. It is a self-reported account from a developer, not a no-code founder, and not a standard path. Nothing in it promises an outcome for you.

What it shows is worth taking:

• Read each notice fresh. A new rejection may cite a new cause.
• Separate the new cause from the last fix. Check that the earlier fix still works.
• Keep a record. One row per notice, as in the sheet above.

Then run the loop again: read the notice, name the cause, fix or reply, test the failing path, resubmit. We can't tell you how many rounds, or when.

If the notice points at a problem you can't judge from outside, get someone to look at the whole app. For the full path to the stores, see Getting your app into the stores.

The Free Build Audit is free. A person on our team records a walkthrough of your app, showing what stays, what needs fixing and what blocks launch, and sends you a one-page note. It doesn't promise approval and it isn't an appeal.

If the app needs repairs, Finish and Launch is our service for that.