Real App Store Rejections and How Developers Fixed Them

Rejection emails from App Review quote a guideline number and a paragraph of boilerplate, and developers spend the next week guessing what the reviewer actually saw. This article covers the rejection types that dominated r/iOSProgramming, r/iosdev, r/SideProject and the Apple Developer Forums from late 2025 to October 2026, what each developer changed, and how appeals turned out.

What developers are asking

• Guideline 4.3 "Design: Spam" hit my app even though I wrote every line myself. What is "similar", and is the category closed? ^4,6,7,21
• A 2.1 rejection says a feature is broken, but it works for me. What did the reviewer do? ^8,9,10
• Can I sell anything outside in-app purchase without a 3.1.1 rejection? ^11,12,13
• Why was I rejected under 5.1.1 for requiring an account when every competitor requires one? ^12,14
• Should I reply, resubmit, appeal or request a call, and which ever changed an outcome? ^1,5,7

4.3 Spam: the most feared rejection of 2026

4.3(a) says your binary, metadata or concept resembles apps already submitted, by you or others; 4.3(b) says the category is saturated. Both messages are templates that name nothing specific ^5,21. What worked:

• Differentiate, then say so in the notes. A first-time developer rejected under 4.3(a) booked a call with App Review, learned that reviewers lean heavily on the Notes to Reviewer field, added one feature competitors lacked, and was approved. The rejection returned when he cleared the notes during a bug-fix resubmission; restoring the "why this app is different" paragraph fixed it again ⁴.
• Rewrite the store listing. A social app rejected under 4.3(b) appealed and rewrote its description, keywords and screenshots to stop sounding like the saturated category. Apple never answered the appeal, but the next rejection no longer mentioned 4.3 ¹.
• Appeal when it is an existing app. A camera app with two approved versions saw its 1.2 update rejected repeatedly under 4.3(a) after adding payment and analytics SDKs. An App Review Board appeal ruled the rejection invalid ⁵. Whether the SDKs tripped an automated similarity check was debated but never confirmed unconfirmed ⁵.
• Bring documentation. A notes app told it resembled apps from a terminated account, apparently a company that had once copied its branding, was cleared after supplying that history and a call with Apple ¹⁸.
• Remove trigger words. A roguelike card game kept being classified as a fortune-telling app because its copy used words like "Fortune" and "Fate", a category Apple lists as saturated ⁸.

Developers whose analytics showed no reviewer session before a 4.3(b) rejection suspect some spam decisions are made from metadata alone; Apple has not confirmed this unconfirmed ²¹. Resubmitting the same concept with a longer explanation earned one team an account warning ⁷. The consistent advice: stop resubmitting, use the appeal form or the request-a-call link in the rejection, and ask one precise question about which app yours supposedly duplicates ⁷.

2.1 Completeness: crashes, logins and things reviewers could not find

2.1 was the top reason first submissions bounced in a 64-decision log from autumn 2026; the fix was nearly always complete App Review Notes plus a short screen recording ^9,22.

• An app rejected for "doesn't do enough" (4.2) had keyboard and share extensions and widgets, but the reviewer opened it on an empty iPad and saw nothing. Seeding labelled sample content on first launch and recording the extensions in use got it through ⁹.
• A subscription app was rejected for a purchase error, but the reviewer's own screenshot showed a system alert that the test account was on a storefront where the app was not sold; the developer replied asking for a retest on a supported storefront ¹⁰.
• A game was told its "core feature, Lock Screen widgets" did not work; it had never offered widgets. Commenters suspected a leftover widget extension target in the build ⁸.
• Two developers were asked for demo logins for apps with no accounts; both were approved after a reply explaining that, without a new build ^1,22.

Reply in the Resolution Center when clarifying; resubmit only when code or assets changed ¹.

3.1.1 Payments and external links

As of October 2026, Guideline 3.1.1 still requires in-app purchase for digital content and features unlocked inside the app. Since May 2025 apps on the United States storefront may link to external purchase options, but developers report the same link in a globally distributed build is still rejected elsewhere, and that promo-code unlocks get flagged.

• A calling app removed in-app purchase entirely and sold prepaid minutes via Stripe. It was approved first time because the notes named guideline 3.1.3(e), stated that credit unlocks nothing in the app, and openly said the previous version had used IAP incorrectly. This only applies to goods consumed outside the app, not subscriptions or unlocks ¹¹.
• A developer told under 3.1.1 to add IAP for credits bought on his website did so, then was rejected under 5.1.1(v) for requiring an account to buy them. Commenters who had passed the same wall let guests purchase via an anonymous identity and linked the balance on login, or sent one short reply quoting the guideline's exception for account-specific functionality ¹².
• A free ticket-scanning app for event organisers was rejected under 3.1.1 and 3.1.3(c) and lost its appeal. The most useful advice: 3.1.3(c) covers software sold to one organisation's employees, while 3.1.3(f), free companions to a paid web service, fits better, so cite that clause and include a free-event demo ¹³.

5.1.1 and 5.1.2: data, accounts and consent

• Vague permission strings ("location is needed for the app to function") were rejected in two separate threads; strings giving a concrete example of what the user will see passed ^1,2.
• Account deletion must happen in the app and actually delete; an email flow is not compliant, and one developer watched the reviewer delete a demo account to test it. With Sign in with Apple, deletion must also revoke the token ^2,3.
• Requiring an account to browse content got a jobs app rejected; developers who had faced the same rule said a polite reply explaining why accounts are central to the experience was accepted ¹⁴.
• A game was rejected under 5.1.2 for sending scores to Game Center without consent despite its privacy policy disclosing it. Another developer with the identical rejection pasted the policy paragraphs into a reply and was approved without changes ^15,22.

Design, paywalls and 5.6 conduct

Paywalls missing visible Terms of Use and Privacy Policy links (3.1.2(c)) caused repeated rejections, with the wrinkle that Apple wants its standard EULA linked in the App Store description, not your own terms ^2,3. An iPod-style music player was rejected around seven times before an appeal led to a conversation with a person at Apple; it shipped with a more modern default look and the classic wheel as an option ¹⁶. A 5.6 "hidden features" rejection, which carries the language of fraud, was traced to an ad-loading message that read as if something ran covertly; the fix is auditing every string a reviewer could misread ¹⁷.

Appeal outcomes in brief

Appeals were decisive for the camera app (overturned) and the iPod player (approval with concessions) ^5,16, silently effective for the social app ¹, and unsuccessful for the ticket scanner ¹³. Calls were the best route for 4.3 cases with real differentiation to show ^4,6,18. Apple's page confirms appeals and expedited review are reachable from the rejection message and contact form ¹⁹; one 4.3-rejected app that resubmitted and sat for 17 days was approved the morning after an expedited request ²⁰.

How this shows up in the charts

Each rejection type delays or removes an app from the charts differently. 4.3(b) explains why Top Free rankings in dating, fortune-telling, calorie tracking and wallpaper categories show so few new entrants despite constant submissions: many never get in. 3.1.1 shapes the Top Grossing charts, where almost every entry still runs on in-app purchase even on the US storefront. And the long loops described here are why a game can sit in the Google Play charts for months before its iOS version appears, visible on AppWinners when you compare first-seen dates on the two stores. The developers who got through fastest treated the reviewer as someone with minutes, not hours, and put the explanation where it would be read.