Your app was rejected by Apple, and the email is short, references a numbered guideline, and does not tell you what to change. Somewhere in your team someone is already saying the reviewer must have misunderstood, and somebody else is talking about appealing. Before either of those: the rejection almost certainly contains the answer, and the most expensive mistake available right now is replying quickly.
Most rejections are one of five things, only two of them require code changes, and each resubmission puts you back in the queue. So the order that works is read it properly, work out which category it is, fix or reply deliberately, and appeal only when you genuinely believe the guideline has been misapplied. Approval is a reviewer's judgement and nobody, including us, can promise it. What you can do is stop losing a week per round.
Read the rejection properly first
Open App Store Connect rather than working from the email. The message in the Resolution Center is usually longer, and it is where the reviewer's actual evidence sits: the screenshots they took, the device and system version they used, and sometimes a video. Three things to extract before you do anything else.
- The guideline number, exactly, including any letter after it. The letters matter: two parts of the same guideline can mean completely different problems with completely different fixes.
- Whether they are asking a question or reporting a defect. A request for information is answered with a reply. A defect is answered with a new build. Getting this backwards is the single most common way to waste a review cycle.
- What they actually did. The screenshots tell you which screen, which device and often which region. A surprising number of rejections are a feature failing only on an iPad, only in a particular country, or only for an account with no data in it yet.
Why apps get rejected by Apple: the five categories
| Category | What the reviewer is saying | What it needs |
|---|---|---|
| Information needed | They could not fully test it: a login they cannot get past, a feature behind a code, a permission whose purpose is unclear, or a question about how something works. | A reply, not a build. Provide a working demo account that does not expire, notes explaining where to find the feature, and answer the question directly. This is the most common rejection and the cheapest to clear. |
| Minimum functionality | The app does not do enough to justify being an app, most often because it repackages a website with nothing a browser could not already do. | Genuine native capability, not argument: notifications, offline use, the camera, biometric sign-in, wallet passes, deep links. Or ship it as a web app instead, which is a legitimate outcome rather than a defeat. |
| Spam or duplicate | It looks like a reskinned template, one of many near-identical apps, or a new entry in a saturated category with nothing meaningfully different about it. Apple has been explicit that this applies to apps produced quickly with modern tooling as much as to anything else. | A real reason to exist: original branding, features that are actually yours, and a purpose a reviewer can see in thirty seconds. If you genuinely have several near-identical apps, consolidating them into one with options is usually the fix. |
| Privacy and data | Declarations do not match behaviour: the privacy labels, the reasons given for accessing sensitive interfaces, third-party components that collect more than you declared, or a missing privacy policy. | Accuracy rather than persuasion. Audit what every component in the app actually collects, including analytics and crash reporting, and make the declarations true. This is the fastest-growing category and the least negotiable. |
| Developer conduct | A trust and safety concern about the account or the submission itself rather than the app's features. This is the most serious category and the one to treat most carefully. | A careful, factual reply and, if the account itself is at stake, professional advice. Do not resubmit repeatedly hoping for a different reviewer. |
Guideline numbering changes as Apple updates the rules, so work from the number in your own rejection rather than one you read in an article, including this one. The categories above are stable; the digits are not.
Fix, reply, or appeal
Three different responses, and choosing the wrong one is what turns a two-day problem into a three-week one.
- Reply when they asked for information or misunderstood where a feature lives. No new build, no new queue position for a fresh review of everything, just an answer in the Resolution Center. Be specific, be polite, and include a demo account and step-by-step directions to the feature.
- Fix and resubmit when there is a genuine defect or a missing capability. Change the thing, then say plainly in the submission notes what you changed and where to see it. A resubmission with no explanation is a reviewer starting from scratch.
- Appeal when you believe the guideline has been misapplied to your app, and you can explain why in terms of the guideline rather than in terms of your business plan. There is a formal route for this. Use it once, calmly, with evidence. Appealing because you disagree with the rule rather than its application is not a route to a different answer.
What not to do: resubmit the same build unchanged in the hope of a different reviewer, argue commercial hardship, or send five messages in a day. None of them help, and the last one measurably hurts.
Every rejection restarts the clock
This is the practical cost and the reason to slow down. Updates to an approved app usually clear review quickly, often within a day or two. A first submission normally takes longer, and every resubmission goes back into the queue rather than resuming where it left off.
So two rounds of rejection is not two days, it is potentially two weeks of a launch date. Which means the highest-value thing you can do is make each response complete: fix everything they mentioned, not the easiest item; provide the demo account before being asked twice; and read the rest of the guidelines for the same category, because a reviewer who found one problem often finds its neighbour on the next pass. This is exactly why our app store launch work assumes at least one rejection round in the plan rather than hoping for none.
The rejection you cannot argue your way out of
If your app is a website in a frame, the objection is correct and no amount of correspondence will change it. Apple's position on this has been consistent for years and has tightened, not loosened.
There are two honest ways forward. Add real native capability, which is a genuine piece of work rather than a setting: notifications that people will accept, useful offline behaviour, camera or scanning, biometric sign-in, wallet passes, proper deep linking. That is what our website-to-app work actually consists of, and the wrapper is the small part. Or accept that an installable web app is the right answer for your business: no store, no review, instant updates, and for plenty of companies genuinely sufficient.
Deciding that in week one is far cheaper than discovering it in week nine, which is the more common sequence.
Preventing the next one
None of these are clever. They are the checklist we run before submitting any customer app, and between them they remove most of the rejections that are actually avoidable.
- A demo account with the submission, every time. Permanent, with realistic data in it, and credentials in the review notes. This alone removes the most common rejection.
- Review notes that explain the unusual. Where the feature is, why you need that permission, what a reviewer should tap to see the thing working. Assume they have ninety seconds and no context.
- Declarations audited against reality, including what every analytics and crash-reporting component collects. Sign-off from whoever added them, not a guess.
- Test on an iPad and on an old system version, and as a brand-new account with no data. Three of the most common defects live in exactly those places.
- Read the guidelines for your category before submitting, not after. They are readable, they change a few times a year, and half an hour there is worth a fortnight of queue.
- Build the buffer into your launch date. Assume one rejection. Announce nothing you cannot move.
Not for you if
One last thing, because the first rejection genuinely rattles people. Being rejected is routine rather than a verdict on your app: it happens to large companies with dedicated teams, several times a year. The teams that ship smoothly are not the ones who never get rejected. They are the ones who read the message properly, respond completely the first time, and budget for the round.