What App Store review actually costs teams

Showing all 126 stories.

1. 

   4.3(a) Spam iOS Guideline 4.3

   A whole portfolio flagged at once

   What happened

   A developer with several apps built from the same starter project received the identical 4.3 notice on every one of them: the apps shared a similar binary, metadata or concept with only minor differences. They decided to work through the apps one at a time.

   Resolution

   Still in progress at the time of posting.

   Lesson

   4.3(a) also covers overlap between your own apps. If several apps grew from one template, each needs a genuinely distinct core, not just a new icon and name.

2. 

   4.3(a) Spam iOS Guideline 4.3

   The same letter twice in one week

   What happened

   A small single purpose photography helper app was rejected under 4.3(a) in the middle of the night, a week after receiving the exact same rejection text for an earlier build.

   Resolution

   Not stated.

   Lesson

   Resubmitting with cosmetic changes rarely moves a 4.3 decision. Change the concept or explain clearly in review notes what makes the app different.

3. 

   4.3 Design / Spam iOS Guideline 4.3

   Building in a crowded category

   What happened

   A solo builder documenting a daily build challenge got a 4.3 Design / Spam rejection on day four and started questioning whether picking a saturated category had been a mistake.

   Resolution

   Not stated.

   Lesson

   Categories Apple lists as saturated get extra scrutiny. Validate what makes your app different before you build, not after review.

5. 

   2.1 Information Needed iOS Guideline 2.1

   Seven questions for a new account

   What happened

   A team's first ever submission came back under 2.1 Information Needed: seven questions, a request for a screen recording and a demo account. Answering honestly surfaced four things they had missed.

   Resolution

   They fixed the issues and replied.

   Lesson

   New developer accounts should expect this. Prepare a demo account, a recording and clear review notes before you submit.

6. 

   2.1 App Completeness iOS Guideline 2.1

   The reviewer could not follow the app

   What happened

   A first time developer was rejected twice before going live. The first rejection, under 2.1, came because the reviewer could not work out how the app was meant to be used.

   Resolution

   Approved after adding a demo video recorded on a real device and step by step review notes.

   Lesson

   Reviewers have minutes, not context. Tell them exactly what to tap and what they should see.

7. 

   Metadata and in app purchase setup iOS Metadata and IAP

   Two rejections for known checkboxes

   What happened

   An indie developer was rejected twice for things they already knew. First, the build went in without its in app purchases attached and the description did not link the terms of use. Weeks later, a screenshot described the app as free.

   Resolution

   Fixed and resubmitted each time.

   Lesson

   Keep a pre submission checklist for metadata, subscriptions and legal links. Most metadata rejections are avoidable.

8. 

   Review queue timing iOS Endless review

   9 days waiting, then 8 days in review

   What happened

   A developer waited nine days for the status to move from Waiting for Review to In Review, then sat in review for eight more days with no update.

   Resolution

   None at the time of posting.

   Lesson

   Review times are not guaranteed. Never tie a launch date, press or creator campaign to an expected approval date.

9. 

   Review queue timing iOS Endless review

   20 days in the reject, fix, wait loop

   What happened

   Over 20 days, a developer went through rejection, fix, Waiting for Review, rejection, fix, and was still waiting at the time of posting.

   Resolution

   Pending.

   Lesson

   Every round trip can cost days. Batch every fix from a rejection note into a single build.

10. 

    Account termination iOS Account termination

    Closed before the first review

    What happened

    A developer with ten years of experience had their developer account terminated, with a fraud accusation that did not say what they had done, while a language learning game was still waiting for its very first review. Their existing apps disappeared and customers started asking why.

    Resolution

    None reported.

    Lesson

    An account termination removes every app at once. Keep your own channel to users (email, website) so you can reach them if the store disappears.

11. 

    Account termination warning iOS Account termination

    Too many rejected versions

    What happened

    A prolific indie developer received a notice that their account would be terminated in ten days. Apple indicated the number of rejected versions was part of the reason. After public attention and an appeal, the account was not terminated.

    Resolution

    Account kept after appeal.

    Lesson

    Rejections add up. Avoid same day resubmits with one word changes and near identical clones of your own apps.

12. 

    Login requirement (guideline number not stated) iOS Login requirement

    Sign up required: you are not that big app

    What happened

    A developer's social app was rejected because it required people to create an account before reaching the home feed. When the developer explained that every user needs a handle for the app to work at all, and pointed to a major photo sharing network that does the same, the reviewer replied, in effect, that their app was not that network.

    Resolution

    Not stated.

    Lesson

    What big apps get away with is not a precedent you can cite. If you require sign up, explain in review notes why the core feature cannot work without an account, and consider letting reviewers or guests see some content first.

13. 

    4.3 Spam iOS Guideline 4.3

    From no review at all to almost everything rejected

    What happened

    A developer saw none of their apps get reviewed for days. Over about a week, while waiting, they created more submissions. When review finally moved, almost all of them came back rejected under guideline 4.3 spam.

    Resolution

    Not stated.

    Lesson

    A stalled queue is not a signal to submit more. Piling up submissions while nothing is being reviewed can make your account look like a spam pattern once a reviewer finally sees them together.

14. 

    4.3 Spam iOS Guideline 4.3

    Unrelated apps rejected together

    What happened

    A developer had several apps, built over months and unrelated to each other, all rejected as spam at the same moment. They asked publicly whether that was normal.

    Resolution

    Not stated.

    Lesson

    4.3 can be applied at the account level, not app by app. If several apps are rejected at once, answer each one separately and spell out in review notes what makes each app distinct.

15. 

    Review queue timing iOS Endless review

    One rejection, then two months of silence

    What happened

    After a single rejection, a developer's app sat in review for around two months, with each review cycle taking roughly a month. They suspected long cycles had become a way to keep new apps out.

    Resolution

    Still stuck at the time of posting.

    Lesson

    After a rejection, the next cycle can be far slower than the first. Make your resubmission complete and well documented so you do not spend another month on a second round trip.

16. 

    Objectionable content iOS Objectionable content

    Rejected for resubmitting without a fix

    What happened

    An AI photo editing app was rejected because it had been resubmitted several times without fixing the issue Apple flagged, which was objectionable content.

    Resolution

    Rejected.

    Lesson

    Resubmitting the same build hoping for a different reviewer can count against you. Fix the flagged issue, or ask for clarification through the Resolution Center, before you resubmit. For generative AI features, add filters for content Apple considers objectionable.

17. 

    4.3 Spam iOS Guideline 4.3

    Rejected the same minute review started

    What happened

    A developer spent weeks building an app and it was rejected under 4.3 spam in the very same minute it entered review. They believed the reviewer judged the niche, not the app.

    Resolution

    Not stated.

    Lesson

    In crowded niches a fast 4.3 can come before anyone looks closely. Lead your review notes with what is unique and point the reviewer straight to it.

18. 

    4.2.6 Template iOS Guideline 4.2.6

    Flagged for a template that was never used

    What happened

    A team was rejected under guideline 4.2.6, which covers apps created from a commercialized template or app generation service, even though they used no template or generation service at all.

    Resolution

    Not stated.

    Lesson

    4.2.6 can be a false positive. Reply in the Resolution Center stating plainly that the app is custom built and who built it, and offer to show the source or development history.

19. 

    3.1.2 Subscriptions iOS Guideline 3.1.2

    The monthly price was bigger than the billed price

    What happened

    A developer's paywall was rejected because it showed the calculated monthly price of a longer subscription more prominently than the amount actually billed. The same paywall had passed earlier reviews without comment. They agreed with the rule but were frustrated it was flagged only now, and redesigned the paywall to lead with the billed amount.

    Resolution

    Resubmitted with the new design.

    Lesson

    A paywall that passed before can still be rejected later. Always make the billed amount and period the most prominent price; show any per month breakdown smaller and secondary.

20. 

    Enrollment (not an App Review guideline) Apple Developer Program Enrollment and account

    Two months, then a refusal with no reason

    What happened

    A developer spent over two months trying to enroll, with multiple support calls and emails, identity verification, device details and even video evidence. Apple then rejected the enrollment without giving a specific reason.

    Resolution

    None at the time of posting.

    Lesson

    Enrollment can take far longer than building the app. Start enrollment early, before your launch plan depends on it, and keep a record of every support exchange.

21. 

    5.1.2 Data use and sharing iOS Guideline 5.1.2

    An App Tracking Transparency rejection that threatened a startup

    What happened

    After a few months of fast shipping and strong user feedback, a startup's app was rejected in late autumn over App Tracking Transparency, the iOS privacy rule that requires user permission before tracking across apps and websites. The founder later described it as a rejection that put the whole company at risk.

    Resolution

    Not stated in the post.

    Lesson

    Audit every SDK in your app for tracking before you submit. If anything links user data with other companies' data, you need the tracking permission prompt and matching privacy labels, even if the tracking comes from a third party library.

22. 

    Login (guideline number not stated) iOS Login

    Reviewer could not sign in with Apple or Google

    What happened

    To stop bot signups, a developer removed email and password login and kept only Sign in with Apple and Google sign in. It worked on their own iPhone and iPad, and even for the previous reviewer, who had rejected the app for a different reason. The next reviewer rejected it because they could not log in.

    Resolution

    Not stated.

    Lesson

    If your app only offers social login, reviewers can still get stuck. Give them a working path in the review notes, such as a demo account or a review only login, and test sign in on a fresh device and account before each submission.

23. 

    Simulated gambling (guideline number not stated) iOS Simulated gambling

    An in game staking feature on an individual account

    What happened

    A game was rejected for including simulated gambling: players could stake in game items against each other, a mechanic common in classic online role playing games. Because the developer published under an individual account rather than a company, they decided to remove the feature for now.

    Resolution

    Removing the feature and resubmitting.

    Lesson

    Gambling style mechanics get extra scrutiny even without real money, and some of what Apple allows depends on your account type and documentation. Check the gambling rules before building staking, loot or wager features, and plan your developer account type around them.

24. 

    Fake documents (guideline number not stated) iOS Fake documents

    A PDF editor blamed for what users might do

    What happened

    A PDF editor app was rejected because Apple said it let users create fake IDs and fake documents. The developer argued that by the same logic any banking or messaging app could be rejected for what bad actors might do with it.

    Resolution

    Not stated.

    Lesson

    General purpose tools can be judged by their worst possible use. Avoid templates or marketing that look like official IDs or certificates, and explain in review notes what the app is for and what it does not support.

25. 

    AI data sharing (guideline number not stated) iOS AI data sharing

    No consent screen for third party AI data sharing

    What happened

    A team got their first rejection for sharing user data with a third party AI provider. Apple required explicit permission from users plus clear disclosure of what data is sent and to which AI provider. The team's worry was building a consent screen that passes review without hurting conversion.

    Resolution

    In progress.

    Lesson

    If your app sends user content to an outside AI service, ask for consent before the first request and name the provider and the data involved. Build that screen before submission, not after the rejection.

26. 

    Family Controls entitlement (guideline number not clearly stated) iOS Metadata and IAP

    Five rejections for one unchecked box

    What happened

    A developer shipping a screen time style app was rejected five times. Vague review notes led them to believe the design itself was the problem. The real cause was a single unchecked Family Controls setting in their developer setup. Once they checked it, the app passed.

    Resolution

    Approved after enabling the Family Controls setting and resubmitting.

    Lesson

    When rejection notes stay vague, audit entitlements and certificates before redesigning the product. Screen Time and Family Controls apps need the matching capability enabled in the developer portal, not only in Xcode.

27. 

    Guideline 5.1.1(v) iOS Guideline 5.1.1 Login requirement

    Account required for a paid feature that runs on device

    What happened

    A developer coming from web apps was rejected under guideline 5.1.1(v). On the web they always tied purchases to an account. On iOS Apple owns the purchase, so buyers can pay without signing up. Their paid tier unlocked on device filters that ran only on the phone, but both unlocking that tier and Restore purchases still forced account creation first.

    Resolution

    Rebuilding so a purchase made without an account still finds its owner after optional sign up. In progress at the time of posting.

    Lesson

    If a paid feature runs on the device and does not need a server identity, let people buy and restore it without an account. Keep sign up only for features that truly need one, such as cloud backup.

28. 

    Guideline 1.4.2 Physical Harm iOS Guideline 1.4.2

    Live dosage calculator apps pulled in a rule crackdown

    What happened

    A developer woke up to find two of their apps flagged under guideline 1.4.2, even though neither had anything in review. Both were already live: a standalone peptide dosage calculator and a tracker with the same calculator built in, which together had become their first real revenue success. Other developers in the same niche reported the same notice at the same time. It said apps that calculate medication doses, including peptide dosage and reconstitution, must be published by the drug maker or a recognized institution such as a hospital, insurer, pharmacy or university.

    Resolution

    None. The developer said they understood the safety concern and treated it as the end of those apps.

    Lesson

    Approval is not permanent. Apple can re-evaluate a live app when it tightens a rule. If your app calculates doses or gives health guidance that could hurt someone, read guideline 1.4 before you build, and plan to publish through a qualified institution or leave the calculation out.

29. 

    Guidelines 4.3 Spam and 4.2.6 App Generation Services iOS Guideline 4.3 Guideline 4.2.6

    An offline ticketing app called spam, again

    What happened

    A developer built a small app that turns a spreadsheet into a ticketing and check-in system that runs fully offline, with no account and no subscription. It had already handled entry at a local event with several hundred attendees over the summer. Apple rejected it again with a combined 4.3 and 4.2.6 notice, saying it might duplicate apps already on the store, be an opportunistic variant of a crowded category, or come from a template or app generation service. The developer said they knew of no other app that did the same thing, and the Android version had been live for about a week.

    Resolution

    Still rejected at the time of posting. The developer said they were not trying to make money from the App Store anyway.

    Lesson

    A 4.3 reviewer sees your listing and a few minutes of the app, not your real users. If the app is genuinely different, say exactly how in the review notes and the first screenshots, mention the real world use, and state plainly that you did not use a template or app generator.

30. 

    Guideline 5.6.4 App Quality Apple Developer Program Guideline 5.6.4

    Payouts frozen over a rising refund rate

    What happened

    A developer running a fast growing subscription app woke up to a warning from Apple saying their developer account broke the Developer Code of Conduct under guideline 5.6.4, App Quality. The notice pointed to excessive refund requests and customer complaints, warned that the account could be terminated, and said all earnings payments were paused and app transfers were disabled. The refund rate had roughly doubled over the previous two months. When the developer dug into the data, most refund requests were labeled as unintended purchases, which they believed came mainly from people forgetting to cancel a 3 day free trial that rolled into an annual plan. The warning landed while a large redesign of the app was already in testing.

    Resolution

    Still open at the time of posting. The developer added more reminders during the trial, made the upcoming charge more obvious, added a way to manage and cancel the subscription inside the app, finished the redesign with more testing, and paused all paid creator marketing while waiting.

    Lesson

    Apple looks at refund rates and complaints, not just your binary. A free trial that quietly converts into a yearly charge can turn into an unintended purchase problem at scale. Remind people before the trial ends, show the real price clearly, make cancelling easy, and treat a rising refund rate as an account risk long before Apple does.

31. 

    Metadata and in app purchase setup iOS Metadata and IAP

    Rejected three times over an image the console would not delete

    What happened

    A developer added a promotional image to a subscription in App Store Connect and accidentally ended up with the same image added twice. After that, the image could not be deleted or replaced, and every attempt failed with a generic error asking them to try again later. The app was rejected three times over that subscription setup. Each time, the developer replied with a screen recording of the delete attempt and the error, and each time it felt like the reviewer ignored it. The developer believed the root cause was a bug in App Store Connect itself.

    Resolution

    Still stuck at the time of posting, with no fix from Apple.

    Lesson

    When App Store Connect itself blocks the fix, a reply in the rejection thread may not reach anyone who can solve it. Upload subscription images carefully and only once, and if the console breaks, contact Apple developer support separately about the bug while you reply to App Review.

32. 

    Guideline 4.3 Spam iOS Guideline 4.3

    Three rejections for an app built to run one gym

    What happened

    A developer built an iOS app to run their own gym, roughly one hundred seventy six commits of work. Apple rejected it on September 29, rejected it again on October 7, and on October 13 rejected it under guideline 4.3 Spam. The same day they answered all nine questions App Review sent them. Six days later, on October 19, they had heard nothing back. Their App Store Connect apps list showed several other apps on the same account also sitting in a rejected state at the same time, on both iOS and macOS.

    Resolution

    Still open at the time of posting, with no reply from App Review after the answers were sent.

    Lesson

    Effort and commit count are not what 4.3 measures. If an app is really built for one business, an unlisted app can stay out of search while remaining accessible to anyone with its direct link; Custom App distribution restricts availability to specified organizations. Choose the option that matches the required access control. For a public listing, make what is different from existing apps obvious in the first screens, screenshots, and review notes.

33. 

    Guidelines 5.6 Developer Code of Conduct and 2.5.19 Hidden Features iOS Guideline 5.6 Developer Code of Conduct Guideline 2.5.19 Hidden Features

    Rejected as fraud for leftover testing switches

    What happened

    In September 2026 a developer had an iOS app rejected under guideline 5.6 Developer Code of Conduct. Apple said it had found a pattern of behavior it associates with fraud, specifically features that looked like they had been deliberately hidden during review. The developer traced it to three testing switches they had left in the release build: a mode for taking store screenshots, a switch that simulated a slow entitlement check, and a switch that unlocked mock purchases. None of them could be reached by normal users of the App Store version. In Apple's October 16 App Review Guidelines update, hidden, dormant, or undocumented features became their own guideline, 2.5.19, and Apple says breaking it can put the whole developer account at risk.

    Resolution

    The developer now inspects the strings inside every release archive before uploading. Whether that specific build was later approved was not stated.

    Lesson

    Keep test-only code out of release builds at compile time, for example with DEBUG flags, rather than behind a runtime check. Check what actually ships in the archived binary, and list any switch that stays in the App Review notes.

34. 

    2.1 Information Needed iOS Guideline 2.1

    Review paused until Apple knew who the app was for

    What happened

    A developer submitted version 1.0 of an iPad app and review stopped under Guideline 2.1, Information Needed. There was no crash report, no broken feature, and no requested binary fix. Apple only wanted a detailed answer to one question before review could continue: who would use this app.

    Resolution

    Apple asked for a target user explanation before continuing review.

    Lesson

    Treat audience and use case as review inputs, not marketing copy you can fill in later. Write a clear target user answer before you submit a first version.

35. 

    4.3 Design / Spam iOS Guideline 4.3

    Not different enough in a saturated sound app category

    What happened

    An entertainment sound app was rejected under Guideline 4.3(b). Apple said the store already had enough similar apps and treated the product as duplicate content in a saturated category, even where the team believed extra features set it apart.

    Resolution

    Rejected under 4.3(b) for insufficient differentiation in a crowded category.

    Lesson

    In categories Apple calls saturated, novelty has to be obvious in the first minute of review. Lead with what is unique, not with a gimmick reviewers have seen many times.

36. 

    Metadata and store listing copy iOS Metadata and IAP Endless review

    The metadata loop that ate launch week

    What happened

    A consumer productivity team shipped a clean build, then spent more than nine days cycling through metadata objections. Each resubmission answered the previous note, but the next reply focused on another phrase, screenshot, or explanation. No code changed while launch, press, and paid acquisition plans waited on review copy.

    Resolution

    Approved after rewriting screenshots, subtitles, and review notes without a binary change.

    Lesson

    Lock listing copy, screenshots, and review notes in one pass before you attach a launch date. Metadata rejections can stack even when the binary never moves.

37. 

    Export compliance (App Store Connect) iOS Metadata and IAP

    Approved, then blocked by one more compliance question

    What happened

    A B2B dashboard companion build reached approval, but release stayed blocked when a compliance prompt reappeared after the team thought export questions were already answered. The release owner stopped rollout, gathered legal wording, updated the App Store Connect response, and waited through another review pass while customers saw the announcement before the app was available.

    Resolution

    Released after answering export compliance again and waiting for the next review pass.

    Lesson

    Treat export compliance as a release gate, not a one time checkbox. Confirm App Store Connect shows a releasable state before you announce a ship date.

38. 

    Google Play permissions and policy review Google Play Metadata and IAP Endless review

    The permission policy time sink

    What happened

    A field operations Android app triggered a broad policy review after a narrow permission used on one screen. The team documented the feature, added reviewer instructions, recorded a demo path, and still had to remove the permission from the main release to unblock customers after thirteen days.

    Resolution

    Approved after removing the permission, recording a new demo, and rewriting the store declaration.

    Lesson

    Scope sensitive permissions to the smallest surface you can ship first. A single permission can expand into a full policy review on Google Play.

39. 

    Google Play review queue timing Google Play Endless review

    The hotfix that waited behind a policy queue

    What happened

    An ecommerce team needed a fast mobile fix for a checkout bug, but the store release sat in review for six days at the worst possible time. Support tickets climbed while status stayed pending. They mitigated server side first, then watched binary approval arrive after the emergency had already burned through a weekend.

    Resolution

    The native store fix arrived after the team had already mitigated the incident elsewhere.

    Lesson

    Store review is not an incident response channel. Keep a non store mitigation path for urgent production bugs while a binary waits in queue.

40. 

    Guidelines 3.1.1 In-App Purchase and 3.1.3(f) Free Stand-alone Apps iOS Guideline 3.1.1 Guideline 3.1.3

    A companion app rejected because its trial ends

    What happened

    A developer shipped a free iOS companion app for their paid web based email service. The app sold nothing inside it. They pointed App Review to the 3.1.3(f) exception for free stand-alone companion apps, but the app was rejected four times. They appealed, and the App Review Board upheld the rejection. Its reasoning was that the service offered a 14 day free trial, so for an iOS user the app stopped being useful after 14 days and was not a real stand-alone experience. Apple offered two ways out: give the app enough free content and features to stand on its own, or let App Store customers buy the service with In-App Purchase. The developer pointed out that a well known email app seemed to do the same thing with a 14 day limit.

    Resolution

    Still unresolved at the time of posting. The appeal was lost, and the developer was weighing a minimal free tier against adding In-App Purchase.

    Lesson

    The 3.1.3(f) companion exception is read narrowly. If your web service has a time limited trial, Apple may treat the app as a paywall in disguise once the trial ends. Before you submit, decide what someone can still do in the app for free after the trial, or plan for In-App Purchase. Pointing to other apps that seem to do the same rarely wins an appeal.

41. 

    Guideline 3.1.1 In-App Purchase iOS Guideline 3.1.1

    Bring your own API key treated as paying outside the App Store

    What happened

    A solo developer building an AI assistant for iPhone let users paste their own API key from a third party model aggregator so they could run large cloud models. On the fourth review round, App Review rejected the app under guideline 3.1.1, treating the bring your own key option as a way to pay for features outside the App Store. As the developer understood the rejection, a key bought elsewhere can only unlock paid capability in the app if that seller offers In-App Purchase in its own iOS app, and this provider has no iOS app. The developer did not appeal.

    Resolution

    They removed the bring your own key feature entirely, rebuilt the next version to run models fully on device, and planned to bring cloud models back later as in-app credits sold through In-App Purchase. The result of that resubmission was not known at the time of writing.

    Lesson

    If paid capability in your app is unlocked by credentials bought somewhere else, check before you build whether that seller offers In-App Purchase in its own iOS app. If not, plan your own In-App Purchase path or a mode that works without it.

42. 

    Guideline 1.2 iOS Guideline 1.2

    An outfit comparison rejected for crowning a winner

    What happened

    A solo developer shipped an AI app that compares two outfits. After a comparison, the app announced that one look won. App Review rejected it under guideline 1.2, reading the result as ranking people rather than clothes. The developer agreed with the concern.

    Resolution

    They removed all winner wording, the winner badge, and any bigger score or highlight color on either option, so both looks now get equal visual weight, each gets its own feedback, and the user decides. Whether the fixed build was approved was not shared.

    Lesson

    Apple judges how a screen feels, not only what it does. If your app scores anything tied to how people look, present feedback without a ranking and assume the harshest reading.

43. 

    Kids category, Guideline 3.1.2, and privacy questions iOS Kids category Guideline 3.1.2 Endless review

    A kids story app still waiting after a month of rejections

    What happened

    A solo developer built a story app for children aged 4 to 10, where kids listen to stories and can pause to ask questions. It had already been live on Android for weeks. They submitted to the App Store on 19 September 2026. After several rounds of rejection and resubmission it was still not approved about a month later. In the latest round Apple asked for two things: because the app sells weekly, monthly, and yearly subscriptions, the App Store page needed a working link to the Terms of Use; and because the app is in the Kids category, review could not continue until the developer answered four questions about third party analytics, third party ads, whether any data is shared with third parties and where it is stored, and whether any other user or device data is collected and for what.

    Resolution

    The developer fixed both issues and resubmitted. Outcome still pending at the time of posting.

    Lesson

    For kids, health, money, or education apps, find out early what local privacy law and the stores will ask, for example parental consent before collecting a child's data, and have the Terms of Use link and a written data answer ready before the first submission.

44. 

    Guidelines 5.1.1(v) and 3.1.2 iOS Guideline 5.1.1 Guideline 3.1.2

    Version 1.0 rejected for sign in, purchase, and delete flows

    What happened

    A developer's version 1.0 was rejected for three issues at once, none about the app idea itself. After Sign in with Apple the app still asked the user for a name that Sign in with Apple had already provided. Account deletion had to be startable inside the app. The subscription and support screen had to show the price, renewal terms, and a Terms link. The developer's own takeaway was that all three were about signing in, buying, and deleting.

    Resolution

    Not stated.

    Lesson

    Before a first submission, walk the sign in, purchase, and delete account flows like a reviewer. Those three flows cause many first rejections.

45. 

    Guideline 5.2.3 Audio/Video Downloading iOS Guideline 5.2.3 Audio/Video Downloading

    Vintage internet radio stopped for third party audio rights

    What happened

    A solo developer's internet radio app with a vintage look, version 1.0 on its fifth build, was rejected under guideline 5.2.3, which covers apps that play or download audio and video from third party sources and asks for proof the developer has rights to that content. The developer replied in the Resolution Center the next day with an explanation about content rights.

    Resolution

    Outcome not yet known at the time of posting.

    Lesson

    If your app streams stations or media you do not own, gather authorization or use sources whose terms explicitly allow app playback, and put that documentation in the review notes before submitting.

46. 

    Guideline 4.3 (Spam) iOS Guideline 4.3

    Six rejections, then a 4.3 spam label and a two week wait for a call

    What happened

    A solo developer spent months on a first app, a conversation starter for social settings. It was rejected six times, the last time under Guideline 4.3 for spam, even though the developer felt it offered more than the similar apps already on the store. They asked App Review for a one on one call. A week went by with no reply, and the call finally happened about two weeks after the 4.3 rejection. The developer left the call with the impression that 4.3 is now being used to flag apps that look like low effort, AI generated clones, which they said their app was not.

    Resolution

    The developer filed an appeal. It was still pending at the time of writing.

    Lesson

    In a crowded category, the reviewer judges what the screenshots, description and first session show. Make the difference from existing apps obvious there, and request the App Review call early, because getting one can take a week or more.

47. 

    Agreement not accepted (no guideline cited) iOS Enrollment and account

    A week in the queue, rejected over an unsigned agreement, then another week

    What happened

    An app waited about a week for review and was then rejected for nothing inside the app. The account had not yet accepted a newly published agreement in App Store Connect. The developer accepted it and resubmitted, and the submission went back into the queue for roughly another week. Developer support only replied that everything was on track.

    Resolution

    Still waiting for review at the time of writing.

    Lesson

    Before every submission, check App Store Connect for agreements waiting to be accepted. A missing click can cost a full trip through the review queue.

48. 

    Crash during review (guideline not stated) macOS Guideline 2.1

    Rejected for a crash on a macOS version the developer had not installed

    What happened

    A Mac app was rejected because it crashed on macOS 27, a version the developer was not running yet and did not want to install on their main machine. While looking for a way to reproduce the crash, they found that Apple's Virtualization framework can run a macOS virtual machine on Apple silicon at no cost, and set one up to test on the new version.

    Resolution

    Not stated beyond reproducing the crash in a virtual machine.

    Lesson

    App Review tests on the newest OS. Keep a virtual machine with the latest macOS ready so you can reproduce review crashes without upgrading your daily machine.

49. 

    Review delay (no guideline cited) iOS Endless review

    Twelve days in Waiting for Review after two expedite requests

    What happened

    A developer who already had apps approved on the store submitted version 1.0 of a new app together with a subscription group of five subscriptions. Twelve days later it was still in Waiting for Review, against the usual expectation of under 48 hours. They requested an expedited review twice, contacted support without getting an answer, and tried to book an App Review appointment, which was declined.

    Resolution

    Still waiting at the time of writing.

    Lesson

    Do not plan a launch date on the 48 hour average. Leave weeks of buffer for a first version with subscriptions, and treat expedite requests and appointments as possible, not promised.

50. 

    Permission prompt + screenshot metadata (rules commonly cited as 5.1.1 and 2.3.7) iOS Guideline 5.1.1 Guideline 2.3.7

    Launch week: custom Allow screen and prices in screenshots

    What happened

    During launch week the app was rejected twice. The first time it showed its own screen with an Allow button immediately before the system permission prompt, which Apple does not accept. After fixing that, the second rejection was because App Store screenshots showed prices. Both fixes were small, but each resubmission cost about a day in the review queue.

    Resolution

    The developer fixed both issues and now keeps both rules written down in the project so it does not happen again.

    Lesson

    A pre-permission screen can explain why you need access, but leave the only Allow choice to the system prompt. Keep prices out of screenshots, and run a short checklist before every submission.

51. 

    Review delay (no guideline cited) iOS Endless review

    Ten days stuck in review, then approved half an hour after resubmit

    What happened

    The app sat in review for more than ten days without moving. The developer resubmitted it.

    Resolution

    It was approved about 30 minutes after resubmitting.

    Lesson

    A stalled review is not always a verdict on your app. When it is stuck well past the usual time, resubmitting or requesting an expedited review can be worth a try, but neither is guaranteed.

52. 

    4.3(a) Spam iOS Guideline 4.3

    Seven template apps rejected for 4.3 in the same minute

    What happened

    A small team sent seven apps built on the same template to review in the same week. All seven got the identical 4.3(a) spam rejection in the same minute, including two apps that had never been rejected before. The team concluded Apple judged the batch rather than each app.

    Resolution

    The team now submits one app at a time.

    Lesson

    Apps that share a codebase can read as a spam pattern when they land together. Space out submissions and make each app clearly distinct in features, design and metadata.

53. 

    Guideline 2.3.6 iOS Guideline 2.3.6

    Age rating rejection when Connect already matched

    What happened

    An app was rejected over its age rating. The developer opened the age rating questionnaire in App Store Connect and found every answer already matched what the rejection message asked for.

    Resolution

    They changed nothing in Connect, replied to the reviewer that the settings already matched, and resubmitted. The app was approved a few hours later.

    Lesson

    A 2.3.6 note can be wrong about your current settings. Check App Store Connect before changing anything, and if it already matches, say so clearly in your reply instead of guessing at a fix.

54. 

    Guideline 2.1 Information Needed iOS Guideline 2.1

    Limited review history: device recording and paid feature walkthrough

    What happened

    An app that had already passed Google Play review was sent back under 2.1 Information Needed. Apple said the developer account had limited review history and asked for a screen recording on a real device, a walkthrough of the paid features, and a written description of what the app does and which outside services it relies on.

    Resolution

    The developer was preparing the recording and answers at the time of posting. Outcome not known.

    Lesson

    Passing Google Play review says nothing about Apple. If your developer account is new or has few past submissions, prepare a real device recording, a paid feature walkthrough, and a list of third party services before you submit.

55. 

    Guidelines 2.1, 2.3.2, and 5.2.3 iOS Guideline 2.1 Guideline 2.3.2 Guideline 5.2.3 Audio/Video Downloading Endless review

    First submission: 2.1, then 2.3.2, then 5.2.3 over a month

    What happened

    A developer's first ever submission waited six days and was rejected under 2.1. They answered the same day. Twelve days later it was rejected again, this time under 2.3.2. They resubmitted, and nine days after that it was rejected under 5.2.3. They answered the same day again and, two days later, were still waiting. Each round raised a different guideline than the one before.

    Resolution

    Still waiting, more than a month after the first submission.

    Lesson

    Every round trip can surface a new guideline, and each one can cost a week or more. Before a first submission, read the metadata rules (2.3) and any content rights rules that apply to you (5.2), not only the completeness rules (2.1), and fix everything you can find in one build.

56. 

    Guideline 4.2 Minimum Functionality iOS Guideline 4.2

    Prayer app rejected as primarily a book under 4.2

    What happened

    A religious prayer and devotion app was rejected under 4.2 with the reasoning that it was primarily a book. The developer noted interactive features including a calendar, a prayer count tracker, a meditation timer, shareable collections, Home Screen widgets, and voice search.

    Resolution

    Not stated.

    Lesson

    If a reviewer reads your app as static content, the interactive features may not be visible in the first minutes of review. Show them on the first screens and screenshots and list them in the review notes, with steps to reach each one.

57. 

    Guideline 2.3.10 iOS Guideline 2.3.10

    Thirteen days in queue, rejected in seven minutes over Android

    What happened

    A developer waited thirteen days in the review queue, checking App Store Connect and email every day and filing two support requests. When review finally started, the app was rejected about seven minutes later because the App Store description said the product worked in any browser on iPhone or Android.

    Resolution

    They removed the mention of the other platform, a one line edit, and resubmitted. Outcome not yet reported.

    Lesson

    Apple rejects metadata that names other mobile platforms. Scan your description, screenshots, and promo text for competitor platform names before submitting, because a tiny wording issue can cost a full queue wait.

58. 

    Guideline 5 (Legal) iOS Guideline 5 Legal

    Guideline 5 rejection over OpenAI in metadata for China

    What happened

    An AI app was rejected under Guideline 5 Legal because its metadata mentioned OpenAI. Apple explained that China requires a government license for generative AI and deep synthesis services, that ChatGPT lacks that permit, and that the developer must either remove the AI functionality and every OpenAI or ChatGPT reference from the name, subtitle, promotional text, description, and screenshots for the China storefront, or stop distributing in China mainland.

    Resolution

    The developer recommends deselecting the China mainland storefront in Availability before submitting an app that names those services, which saves a review cycle.

    Lesson

    If your app is built on a generative AI provider, decide on China availability up front. The rejection is about the storefront and metadata, not your code alone.

59. 

    Guideline 3.1.2 iOS Guideline 3.1.2

    Terms link in the app but missing from the description

    What happened

    A subscription app's first version was rejected two days after submission because the Terms of Use link was not in the App Store description. It was already present inside the app on the paywall and in settings, just not in that metadata field.

    Resolution

    The fix took five minutes, but after resubmitting the build sat in Waiting for Review for more than ten days with no response. None reported yet.

    Lesson

    For auto renewable subscriptions, put Terms of Use (EULA) and Privacy Policy links in the App Store metadata as well as in the app before the first submission, because a quick fix can still cost a long second wait.

60. 

    Account termination iOS Account termination

    Account terminated under 3.2(f), pending earnings unpaid

    What happened

    A developer's Apple Developer account was terminated under section 3.2(f) of the Developer Program License Agreement. Almost three months later their pending earnings had still not been paid out and they were asking other developers whether anyone had ever received withheld earnings after a termination.

    Resolution

    None reported.

    Lesson

    A termination can freeze revenue you already earned, not only future sales. Keep cash runway, records of your payouts, and your own channel to users so one account decision does not end the business.

61. 

    Guidelines 2.1 and 5.1.2 iOS Guideline 2.1 Guideline 5.1.2 Endless review

    Twenty-five days in review, then 2.1 and 5.1.2 at once

    What happened

    An indie developer submitted the first version, 1.0, of an iOS app. After about seventeen days, the build was still in review. After roughly twenty-five days total, App Review rejected it under guideline 2.1 App Completeness and guideline 5.1.2 Data Use and Sharing in the same decision. App Store Connect then blocked every other item in the submission until the rejected version was fixed. The developer said the cited problems were easy to fix; the painful part was expecting another two to three weeks for the resubmission.

    Resolution

    They fixed both issues and resubmitted. The outcome of the next review was not reported.

    Lesson

    When queues run this long, every rejection can cost weeks. Before you submit, run a full completeness pass with no broken flows, a working demo account, and nothing placeholder, and make sure privacy answers and any SDK data sharing match what the app actually does.

62. 

    Guideline 2.3.1(a) iOS Guideline 2.3.1 Metadata and IAP

    Real money stakes rejected as hidden under 2.3.1(a)

    What happened

    A developer built a habit and discipline tracker where users could put money at stake and lose it if they missed their goals. In mid-October 2026, App Review rejected it under guideline 2.3.1(a), saying the app contained hidden features, specifically monetary staking and stake forfeiture that were not described in the metadata. The letter also carried an Extended Review notice warning that repeated submissions with such issues lead to longer review times and that accounts that keep breaking the rules can be removed from the Apple Developer Program. The app went through five rejections in total; another cited a crash during review on iPad. The developer, who had built with AI coding tools, summarized takeaways: read the guidelines, match metadata to the app, never hide features or data collection, review generated code, and test on different devices.

    Resolution

    Not stated beyond reworking the app after five rejections. Approval was not reported.

    Lesson

    Any feature that moves real money, including stakes or forfeits, must be clear in the description and App Review notes. Test on iPad even if you target iPhone, because reviewers do.

63. 

    Guideline 4.3(a) iOS Guideline 4.3

    New features, new screenshots, and a 4.3(a) in three minutes with a warning

    What happened

    A developer who had spent about two months building an app from scratch had already been rejected under 4.3 spam. For the next round they added new features, replaced every screenshot, optimized the app for more device sizes, and resubmitted with review notes and a premium test account. Three minutes after the app entered review it was rejected again under Guideline 4.3(a). This time the message ended with an extended review notice: repeated submissions with these issues would lead to longer review times, and accounts that keep submitting such apps face removal from the Apple Developer Program. Afraid that another resubmission could cost the whole account, the developer was deciding whether to drop the app or ask App Review for a call.

    Resolution

    Unresolved at time of posting.

    Lesson

    Once the extended review notice appears, a quick resubmit is the riskiest move. Ask for an App Review call first and resubmit only once you know what they consider too similar.

64. 

    Guideline 4.3(b) iOS Guideline 4.3

    Rejected in three minutes, then three weeks of appeal silence

    What happened

    A developer's app was rejected under Guideline 4.3(b) about three minutes after it entered review. They appealed to the App Review Board. Three weeks later they still had no answer, no status change and no message of any kind.

    Resolution

    Unresolved.

    Lesson

    An appeal can sit for weeks without feedback. Work on what makes the app different from the crowded category in parallel, so you are not stuck waiting on the appeal alone.

65. 

    Account termination iOS Account termination

    One app looked like a website, and dozens of apps disappeared

    What happened

    A studio that had published apps for more than a decade, over 80 of them, had its developer account flagged for termination. According to the studio, the reason was that one of its apps could be seen as similar to an existing website. There was no warning and no option to remove just that app. Every one of its apps was pulled from the App Store, including unrelated licensed apps built for clients, and updates were blocked.

    Resolution

    Unresolved. The studio publicly disagreed with the decision.

    Lesson

    One developer account is one point of failure. If you build apps for clients, publish them under the client's own developer account so a dispute over one of your apps cannot take theirs down too.

66. 

    Section 3.2(f) (Developer Program License Agreement) iOS Account termination

    A title update, then a 3.2(f) termination notice

    What happened

    An indie developer submitted a simple title change for one app and received a termination notice under section 3.2(f). All of their apps were removed from the store. They filed official appeals and, 15 days later, had not heard back from a person.

    Resolution

    Unresolved.

    Lesson

    The update that triggers a 3.2(f) notice may not be what Apple is reacting to. Before appealing, gather clear proof of who owns and runs each app, and expect answers to take weeks.

67. 

    Section 3.2(f) (Developer Program License Agreement) iOS Account termination

    One paywall fix, then a 3.2(f) termination notice a week later

    What happened

    An indie developer's app had been rejected once, over how the yearly and weekly prices were shown on its paywall. The paywall had come from a template that an AI coding assistant copied in. They fixed it in code, submitted a new build, and waited about a week. Instead of a review result, they woke up to a pending termination notice under section 3.2(f). Their whole developer membership was flagged, every app they had built over several years was removed from the App Store, and payouts were frozen. The developer said they had not changed anything in the app after submitting, had logs to back that up, and publicly asked whether anyone had ever gotten an account back.

    Resolution

    Unresolved at time of posting.

    Lesson

    Treat a paywall or pricing rejection as a warning, not a formality. Check any template or generated paywall code for how prices and trial terms are shown before the first submission, and keep build and change logs so you can document exactly what you submitted if your account is ever questioned.

68. 

    Guideline 3.1.1 In-App Purchase macOS Guideline 3.1.1

    A free cloud gaming client rejected under 3.1.1 for purchases inside streamed games

    What happened

    A developer built a free remote play app for a major console maker's cloud gaming service and submitted it to the App Store. The Mac version was rejected under guideline 3.1.1. App Review said some streamed games could lead users to buy digital content outside the App Store. As the developer understood it, the gaming service does not let players complete a payment during a streaming session: some games show purchase options, but the payment cannot go through while streaming. They pointed out that several similar streaming apps were already on the store and filed an appeal.

    Resolution

    Appeal pending at time of posting.

    Lesson

    For streaming and client apps, App Review judges what users can see inside the streamed content, not only your own code. Explain in the review notes exactly how purchases behave inside the stream, with screenshots, before the first submission instead of saving it for the appeal.

69. 

    Login on iPad (guideline number not stated) iOS Login

    Third rejection because login failed on iPad during a backend outage

    What happened

    A small team building a fitness app had its iOS app rejected for the third time because the reviewer could not log in on an iPad. The cause was not in the app code: their hosted backend provider was having authentication problems at the moment the reviewer tried, so sign in simply failed. The team had supplied a demo account with an email and password, but by their account the reviewer did not try again later. They did not own an iPad or a Mac to test on. Once the backend was healthy they resubmitted. Apple had told them the app would stay in expedited review even if rejected again, yet three business days later it was still waiting for review.

    Resolution

    Resubmitted, still waiting for review at time of posting.

    Lesson

    Reviewers often test on iPad and usually try your login once. Watch your backend and auth provider status while a build is in review, test the demo account on an iPad-sized screen before submitting, and say in the review notes who to contact if sign in fails.

70. 

    Guidelines 5.1.1(i) and 5.1.2(i) iOS Guideline 5.1.1 Guideline 5.1.2 AI data sharing

    AI consent buried in the terms was not enough for 5.1.1(i) and 5.1.2(i)

    What happened

    A developer's journal app was rejected on iOS under guidelines 5.1.1(i) and 5.1.2(i), both about sharing user data with AI services. Consent for that processing was already covered in the app's terms, but App Review did not accept that. The developer moved consent to an explicit screen inside the app, shown first, before any model reads a single entry. They then mapped every code path where entries reach a model and gated each one on that consent, so no request is even built without a yes. Background jobs now skip accounts that have not agreed and wait instead of failing, and a release check fails if the app calls an AI host that the consent screen does not name.

    Resolution

    Fixed and resubmitted. Apple's verdict was still unknown at time of posting.

    Lesson

    A line in your terms is not consent for AI data sharing. Ask inside the app before the first request, name the provider and the data, and make sure every code path that sends user content checks that answer.

71. 

    Section 3.2(f) (Developer Program License Agreement), after repeated metadata rejections iOS Account termination Metadata and IAP

    One new library, eight rejections, a renamed app, then a termination notice

    What happened

    An indie developer had an iOS app that was almost three years old, had earned six figures in revenue and had shipped many updates with a low refund rate. Over six months ago they submitted a small update whose only change was one new library. App Review rejected it more than eight times, each time over metadata: keywords that had been live for more than a year, a subtitle in one localization, then the screenshots, then the same points again, and finally the app name itself, which was where most of their search traffic came from. They asked for a call with App Review, and the reviewer told them the name was the last remaining issue. They renamed the whole app and resubmitted. Three days later a generic rejection came back with the subtitle and screenshot issues again. They decided they did not need the update and dropped it. Months later, a pending termination notice arrived in that same old review thread. It said the account had repeatedly violated the guidelines in an attempt to evade the review process and that the issues from earlier messages remained unresolved. The app was removed from the store and the whole account was flagged for removal.

    Resolution

    Appeal filed with the App Review Board, pending at time of posting.

    Lesson

    An abandoned submission can still count against your account. If a review loop keeps going, get every remaining issue confirmed in writing in the review thread rather than only on a call, and if you decide to drop an update, reply in the thread to say so and remove the build from review instead of leaving the rejection unresolved.

72. 

    Guideline 1.1 Safety: Objectionable Content, then Section 3.2(f) iOS Objectionable content Account termination

    Two 1.1 rejections, one question about which image, then a termination notice

    What happened

    A developer's iOS app that generates AI couple photos was rejected under guideline 1.1 for objectionable content. The rejection did not say which image was the problem. They toned down the sample images, with no touching or leaning in, and resubmitted once about five days later. Four days after that it was rejected again for the same reason. Instead of sending another build, they wrote to Apple asking which image was the issue. About ten days passed with no answer, then the app was removed from the store and the developer received a pending termination notice. As they understood it, Apple treated the repeated fix and resubmit cycle as an attempt to get around review. Payouts were paused and every app on the account was at risk, with 30 days to appeal. Reading forum threads from developers with the same notice, they found that most appeals sat for weeks without an answer, and the one reinstatement they found came after a second appeal that named the actual cause and disclosed everything else.

    Resolution

    Preparing an appeal at time of posting.

    Lesson

    Two rejections under the same guideline can now be enough to put an account at risk. When a content rejection is vague, ask App Review to point to the exact screen or asset before resubmitting, keep a record of every change, and treat the second rejection as a signal to pause rather than to try again.

73. 

    Guidelines 2.3.7, 5.2.5 and 4.8 iOS Guideline 2.3.7 Metadata and IAP Login requirement

    Approved on Mac, then rejected on iPhone under 2.3.7, 5.2.5 and 4.8 in the same app

    What happened

    A developer building a calendar client for a major third party calendar service shipped the Mac version first. The Mac version had already needed a formal appeal just to say in its listing that it works with that calendar service, and they had already explained to App Review why it did not need Sign in with Apple. When they added the iPhone version, under the same bundle and the same App ID as the Mac app, it was rejected on three guidelines at once: 2.3.7 for prices shown in an in-app event, 5.2.5 for a line saying the app was for iPhone, iPad and Mac, and 4.8 for not offering Sign in with Apple next to the calendar service's own login. Guideline 4.8 has an exception for apps that are clients for a specific third party service, which is what this app is, but the explanation given for the Mac version did not carry over. Each platform target was reviewed from zero.

    Resolution

    Not stated at time of posting.

    Lesson

    A new platform is a new review, even inside the same App ID. Copy every explanation and exception you already won into the review notes for each platform, and check in-app events and descriptions for prices and Apple device names before submitting.

74. 

    Guideline 3.1.2(c), then Apple trademark in Siri text (guideline number not stated) iOS Guideline 3.1.2 Endless review

    Nine days waiting, a 3.1.2(c) paywall rejection, then a binary rejected in 42 seconds over Siri text

    What happened

    A developer on a new account submitted the first version of a writing habit app and waited about nine days before it moved to In Review. Fifty minutes later it was rejected under guideline 3.1.2(c): on the yearly plan, the calculated monthly price was shown in larger text than the yearly price actually billed. They fixed the paywall font sizes and uploaded a new build. That build was rejected automatically in 42 seconds, because the help text of a Siri shortcut mentioned an Apple app by its brand name, and text in Siri intents cannot use the word Apple. They reworded it to refer to the notes app generically and uploaded the build again.

    Resolution

    Resubmitted, result unknown at time of posting.

    Lesson

    Before the first submission, make the billed amount the most prominent price on every plan and search all user facing strings, including Siri, Shortcuts and widget text, for Apple trademarks. Automated checks catch these in seconds, but each round still costs you a place in the queue.

75. 

    Section 3.2(f) (Developer Program License Agreement), citing an old name rejection iOS Account termination Metadata and IAP

    A name rejection fixed and approved, then a fraud termination notice almost a year later

    What happened

    A solo developer running a small company account had built eight live apps over about a year and a half. Almost a year earlier, one of those apps had been rejected because Apple objected to a word in its name. The developer changed the name, the app was reviewed again and approved, and a later update to it was approved too. The review history they shared shows version 1.0 rejected on two consecutive days and approved the day after, then an update approved on its first try about two months later. After that the app was left untouched for about nine months. Then a new app from the same account was rejected, and a pending termination notice arrived citing dishonest or fraudulent activity under section 3.2(f): submissions had repeatedly violated the guidelines in an attempt to evade review, and issues from earlier messages remained unresolved. It named no new issue and came with no warning or question first. Earnings from every app were paused, including apps that never had a problem, and the notice warned that a new account could be terminated too. The only way to respond was a web form limited to 2,000 characters, which returned an automated acknowledgment and then silence. The developer accepted the removal of the flagged apps, shut down their servers the same day, paused all submissions and sent a full appeal on day one.

    Resolution

    Appeal sent on the first day, only an automated acknowledgment at time of posting.

    Lesson

    A rejection you fixed and got approved can still be cited months later as part of a pattern. Keep every rejection message, the exact change you made and the approval that followed, so you can show the full history in a short appeal form, and expect no timeline once it is submitted.

76. 

    Guidelines 4.3 Spam and 4.2.6 iOS Guideline 4.3 Guideline 4.2.6

    A game made alone rejected twice as spam and as a template, nine answers sent, no reply

    What happened

    A developer who makes games alone in the evenings submitted an original game and had it rejected twice, four days apart in early October, under guideline 4.3 for spam and guideline 4.2.6, which covers apps created from a commercialized template or app generation service. No template was involved and every line was written by the developer. Both rejections came back with the same template text, and neither named the app the game was supposed to resemble. Apple then sent nine questions about how the game was made, and the developer answered all of them in detail the day after the second rejection. No reply came. About nine days later they appealed to the App Review Board, and a week after that they were still waiting. Their own guess was that one person shipping several games within a few months looks like an app factory from the reviewer side. In the meantime they made the game playable for free in a web browser.

    Resolution

    Appeal to the App Review Board pending at time of posting, about three weeks after the first rejection.

    Lesson

    4.3 and 4.2.6 can be judged across your whole account, not one binary. If you ship several titles in a short time, show what makes each one original from the first submission, with review notes on how it was built and a short gameplay video, because once the rejection text is templated, detailed answers can sit unread for weeks.

77. 

    Guideline 2.1 App Completeness, then Guideline 5 Legal (China availability) iOS Guideline 2.1 Guideline 5 Legal Endless review

    A free license for the reviewer hid the paywall, then six days in the queue and a China AI rejection

    What happened

    A developer submitted their first iOS app, a personal finance tool for keeping track of recurring payments, and it was rejected under guideline 2.1 App Completeness. The cause was a favor that backfired: they had given the reviewer email a paid license, so the reviewer skipped the paywall and never saw the purchase flow. The developer wrote a step by step PDF guide with screenshots for the reviewer and resubmitted, this time sending the iOS and Mac versions together. The new submission waited six days before moving to In Review, and was then rejected again, this time over a mention of ChatGPT while the app was available in mainland China.

    Resolution

    Still rejected at time of posting, while a newer build was offered to testers through TestFlight.

    Lesson

    Let App Review see exactly what a new user sees, paywall included. Give the reviewer a working demo or sandbox account and clear notes rather than a free license that hides the purchase flow. If the app or its listing names an AI provider such as ChatGPT, check whether mainland China is in your availability before submitting, since each new round can cost days in the queue.

78. 

    Guideline 2.3.10 Accurate Metadata iOS Guideline 2.3.10 Metadata and IAP Endless review

    Ten days to a first review, a Google Play mention, then two more weeks waiting

    What happened

    A developer with a brand new developer account submitted a brand new app in early October. It is an app where users can publicly upload their own images, which the developer expected to draw extra content moderation scrutiny. The first review came ten days later, on an iPad, and ended in a rejection under guideline 2.3.10 Accurate Metadata: the app or its metadata mentioned a third party platform, and the next step was to remove the Google Play references. The developer traced the mention to the text describing an in app purchase. After the fix the app went back into the queue, and two weeks later it was still waiting for review, 24 days after the first submission and still not live.

    Resolution

    Still waiting for review at time of posting, 24 days after the first submission.

    Lesson

    Search every text field you submit, in app purchase descriptions included, for the names of other stores and platforms before the first submission. On a new account each round trip can cost a week or more in the queue, so a one word mention can delay a launch by weeks.

79. 

    Guideline 2.1 App Completeness (Information Needed) iOS Guideline 2.1 Endless review

    24 days in the queue, then a 2.1 rejection asking for a full screen recording

    What happened

    A developer submitted version 1.0.0 of a new iOS app together with a subscription group and two subscriptions, yearly and monthly. After 24 days of waiting, Apple looked at it and rejected it under guideline 2.1 App Completeness, which the developer said left them confused. Because the app version was rejected, the subscriptions submitted with it could not be approved either and stayed at Ready for Review. The message behind the rejection was a 2.1 Information Needed request, the first time the developer had received one. It asked for a screen recording on a physical device running the latest operating system, starting from launch and showing the typical user flow, including registration, login and account deletion, any user generated content with its reporting and blocking tools, and access to paid content. It also asked for a description of the purpose and target audience, setup instructions with login credentials, a list of the outside services the app relies on, AI services included, any regional differences, and documentation for regulated industries or protected third party material. The answers also had to be added to the review notes in App Store Connect for future submissions.

    Resolution

    The developer went back to preparing the recording and answers at time of posting. Outcome not known.

    Lesson

    An Information Needed request after weeks in the queue costs another full round trip. Record that walkthrough on a real device and write those answers into the review notes before you submit a new app, especially one with subscriptions, accounts or user content, since a rejected version also holds back everything submitted with it.

80. 

    Section 3.2(f) (Developer Program License Agreement) Apple Developer Program Account termination Endless review

    Six approved updates in a row, then a routine update and a 3.2(f) termination

    What happened

    An indie developer had six updates approved in a row. The review history they shared shows the latest submission In Review and every earlier one marked Review Completed. They then submitted a routine update in mid October, and it stayed stuck in review. Instead of a review result, the whole developer account was terminated under section 3.2(f). In App Store Connect, a message dated the day of that submission was attached to multiple versions and marked as unresolved issues. The developer described their apps as native, with a clean record of approved updates, and said Apple support was investigating their appeal.

    Resolution

    Appeal under investigation at time of posting.

    Lesson

    A clean approval streak is no protection against a 3.2(f) termination. Keep a dated record of every submission, review message and approval, and check the Messages section in App Store Connect after every review, so you can send the full history the moment an appeal is possible.

81. 

    App Review information request (demo account and screen recording) iOS Login

    The demo account deleted five minutes after submission, then a recording request that saved a second rejection

    What happened

    An agency submitted a client app with a demo account for App Review. Five minutes after submission, App Review had deleted that demo account. Apple then asked for a screen recording of the app. While making the recording, the team found sales copy inside the app that they had missed and that would have gotten the app rejected again.

    Resolution

    Final outcome not shared at time of posting.

    Lesson

    A reviewer may delete the demo account you provide, for example while checking that account deletion works, so have a way to recreate it or provide more than one. Record your own review walkthrough before submitting: watching the app the way a reviewer does is a cheap way to catch copy that would trigger the next rejection.

82. 

    Section 3.2(f) (Developer Program License Agreement) Apple Developer Program Account termination Metadata and IAP

    Five early rejections, four approved updates, then a 3.2(f) notice over a year later

    What happened

    An independent iOS developer with almost ten years of apps behind them submitted a new AI image to video app in April 2025. Users uploaded their own photos, got their first generation free, and could then buy credits as one time in app purchases, with no subscriptions. The first submission was rejected five times, mostly over screenshots and metadata: screenshots judged too marketing oriented, and a screenshot showing a couple kissing, then its replacement showing a marriage proposal, flagged under the Objectionable Content guideline. After changes to the screenshots, their text and the build, the app was approved, and four updates followed without a single rejection, the last in August 2025. No update was submitted after that. More than fourteen months later, a Pending Termination Notice arrived saying submissions from the account had repeatedly violated the guidelines in an attempt to evade review, with violations still unresolved after multiple resubmissions, and it was attached to all five versions. The developer said App Store Connect no longer showed enough detail to rebuild the old rejections. They appealed about 30 minutes after the notice arrived around midnight, inside a 2,000 character limit, and later wished they had waited to write it more clearly.

    Resolution

    Appeal pending at time of posting.

    Lesson

    An approval does not close the file. Keep your own copy of every rejection message, the guideline cited, what you changed and the date it was approved, because App Store Connect may not show old details later. If a notice arrives, take the time to write a clear appeal that fits the character limit rather than sending one in the first hour.

83. 

    Section 3.2(f) (Developer Program License Agreement) Apple Developer Program Account termination Metadata and IAP

    A title keyword, a 3.2(f) termination, and an appeal answer that pointed to streaming references

    What happened

    An indie developer had their whole developer account terminated under section 3.2(f). By their account it came with no warning and no earlier metadata rejection, and they believed the cause was a keyword mistake in an app title. They appealed. The App Review Board replied that its investigation confirmed guideline violations: one of the developer's apps included misleading references that led users to believe it delivered streaming services, which Apple called egregious. The letter described a pattern of manipulative or misleading behavior, kept earnings payments paused, and said that once the termination was formal the developer could petition the App Review Board for reinstatement, explaining the reasons and the improvements planned.

    Resolution

    Appeal rejected. A reinstatement petition is possible after formal termination.

    Lesson

    Words in a title or keywords that hint at a service the app does not provide, like streaming, can be read as misleading rather than as a simple metadata mistake, and that can lead straight to termination with no rejection first. Check every title, subtitle and keyword against what the app actually does before you submit.

84. 

    Guideline 4.1(a) Copycats iOS Endless review

    15 days in review, then 4.1(a) Copycats for movie posters from a public API

    What happened

    A developer built an iOS app that helps people pick a movie. It shows titles and posters pulled from a public movie database API, credited inside the app, and its watch button opens the official streaming app rather than streaming anything itself. After 15 days in review, Apple rejected it under guideline 4.1(a) Copycats, treating the posters as third party content and asking for proof of the rights to use them, or for their removal. The same app with the same posters had been approved on Android and on a TV device app store.

    Resolution

    Unresolved at time of posting. The developer was asking other developers whether the API terms had been accepted as proof or whether the posters had to go.

    Lesson

    Credit inside the app and approval on other stores do not count as rights for App Review. If your app shows posters, artwork or logos from an API, have written proof that you may display them ready before you submit, or plan a version without them.

85. 

    Metadata rejection (localized keyword) iOS Metadata and IAP

    AI translated the app into five languages and slipped in a keyword that got it rejected

    What happened

    A developer used an AI model to translate their app into five more languages. In one of those languages the translation added a keyword that could be misread, and the submission was rejected over it. A week later the developer was still waiting for an answer and, after a week of 3.2(f) termination stories from other developers, worried that even an approved fix could later be held against the account.

    Resolution

    Waiting for an answer from Apple at time of posting.

    Lesson

    Have someone who reads each language check every localized keyword, title and subtitle before you submit. Machine translation is fast, but App Review judges the words in every locale as if you chose them yourself.

86. 

    App preview metadata (price reference) iOS Metadata and IAP

    An app preview said free trial available, and the update was rejected

    What happened

    An indie developer submitted an update whose app preview video included the words free trial available. Apple rejected the update, treating any mention of free in the preview as a price reference. The developer re-cut the video and resubmitted.

    Resolution

    Video re-cut and resubmitted. Final outcome not shared at time of posting.

    Lesson

    Keep prices and the word free out of app previews, even when the trial is real. Show the trial terms inside the app on the paywall instead.

87. 

    Guideline 2.5.1 Software Requirements (HealthKit) iOS Endless review

    Six days waiting, then 2.5.1 because the Health sync had no Apple Health badge

    What happened

    An indie developer submitted a major update that added Apple Health sync for the first time. It sat in Waiting for Review for six days. Only then did they notice a new developer agreement waiting to be signed in their account. They signed it, and the update went into review that same afternoon, though they could not say whether the two were connected. The update was then rejected under guideline 2.5.1 because the Health feature was not clearly identified in the app interface. The developer had not known about the Apple Health badge.

    Resolution

    Added the Works with Apple Health badge next to the sync toggle, a review note, and a screen recording made on a real device. Approved on the next submission.

    Lesson

    If your app reads or writes Health data, show it clearly in the interface with the Apple Health badge from the very first submission. And when a review sits still for days, check App Store Connect for an unsigned agreement before anything else.

88. 

    Guideline 1.1 Objectionable Content iOS Objectionable content

    Live for over a year with no rejections, then removed under 1.1 without warning

    What happened

    An indie developer had an app on the App Store for more than a year. It had never been rejected once and brought in a modest monthly subscription income. With no prior warning, Apple sent a message saying the app had been removed from the store for violating guideline 1.1 Objectionable Content.

    Resolution

    The developer told Apple they would not resubmit, abandoned the app and the whole niche, because they did not want to put their developer account at risk.

    Lesson

    A clean review history does not protect an app from being pulled later, and content rules can be applied to an app that was approved for a long time. If your app sits in a sensitive niche, review its content and screenshots against guideline 1.1 now, not after a removal notice.

89. 

    Bug rejection (guideline not stated) iOS Endless review

    A 100 second matchmaking timeout was reported as a bug, then six days waiting for a reply

    What happened

    A developer submitted a multiplayer game. The reviewer rejected it for a bug, but what they hit was not a crash: the game stops searching after waiting 100 seconds to match the player with an opponent, and the reviewer saw that timeout as broken behavior. The developer replied to the reviewer explaining how matchmaking works and also removed the timeout from the game. Six days later they were still waiting for a single answer.

    Resolution

    Explained in a reply and removed the timeout. Still waiting for an answer at time of posting.

    Lesson

    A reviewer often plays alone and at an odd hour, so an empty matchmaking queue is likely. Give the review team a way to reach a real game, such as a bot opponent or a demo mode, and explain it in the review notes before you submit.

90. 

    Metadata rejection (Terms and Privacy links) iOS Metadata and IAP

    Code reused from another app, and the Terms and Privacy links still pointed to the old one

    What happened

    A developer built a new app partly by reusing pieces from one of their earlier apps. The Terms of Use and Privacy Policy links inside it still pointed to the old app, and App Review rejected the submission for that. The developer said the rejection message spelled out exactly what needed changing.

    Resolution

    Fixed the links and resubmitted. The developer said an expedited review usually came back in about a day, but should be used sparingly.

    Lesson

    Before you submit an app built from an older project, check every link, bundle name, and legal page it carries over. Read the rejection message closely, because it often says exactly what to fix.

91. 

    Guideline 2.1 Information Needed iOS Guideline 2.1

    No bugs in the report, just 2.1 Information Needed, answered with an 89 second recording

    What happened

    A developer submitted their second app, and it came back under guideline 2.1 Information Needed with no bug listed at all. App Review wanted a screen recording plus answers about who the app is for, how it is used, any outside services it relies on, and which regions it targets. The developer recorded 89 seconds on the simulator, going from launch through one full use of the main feature to the paywall, answered every question in the notes, and resubmitted the same day.

    Resolution

    Recording and answers sent the same day. Final outcome not shared at time of posting.

    Lesson

    For a new app, expect a 2.1 information request and prepare for it. Have a short recording of the main flow and written answers about audience, usage, outside services and regions ready in the review notes before you submit, so the first review does not stop for questions.

92. 

    Guideline 2.5.4 Software Requirements (background modes) iOS Endless review

    Rejected over one leftover checkbox, the audio background mode, then ten days for the next update

    What happened

    A small team submitted an update to an app that was already live. App Review rejected it under guideline 2.5.4 for a single setting: the audio background mode was enabled in the app, and the app did not need it. The team removed the background mode and resubmitted the same day, which cost them about a day. Their next update then sat in review for roughly ten days.

    Resolution

    Removed the audio background mode and resubmitted the same day. The following update waited about ten days in review.

    Lesson

    Background modes are only allowed for their intended purpose. Before every submission, open the Background Modes capability and remove anything the app does not actually use, because a leftover checkbox is enough for a rejection, and you cannot predict how long the next review will take.

93. 

    Guideline 4.3(a) Spam iOS Guideline 4.3

    A web app in a wrapper got 4.3(a) spam, so the developer rebuilt it as a native app

    What happened

    A developer submitted the first version of their app as a web app inside a native wrapper. App Review rejected it under guideline 4.3(a), the spam rule. The developer admitted Apple had a point. They rebuilt the app as a real native app, moved its backend to a relay server they run themselves, and published the source code.

    Resolution

    Rebuilt as a native app with a self hosted relay server. The outcome of the rebuilt version was not shared in the post.

    Lesson

    A thin wrapper around a website is easy for App Review to read as spam. If you ship to the App Store, give the app real native value from the first submission instead of hoping a wrapped site gets through.

94. 

    Objectionable content rejection (screenshots, then subtitle) iOS Objectionable content Metadata and IAP

    Screenshots flagged as objectionable, then the subtitle, for a game with nothing adult in it

    What happened

    A small studio makes simple story games for iOS, with no adult themes, gambling or crypto. One game, where the player is a celebrity trying to make it in Hollywood, was rejected for objectionable content in its screenshots. The screenshots only showed fully dressed characters from the game. The studio replaced every screenshot and resubmitted. The next rejection was for objectionable content in the subtitle, which simply described the game as celebrity life and drama games. Each review took weeks.

    Resolution

    The app was first submitted in September and was still not approved at the end of October.

    Lesson

    When App Review flags metadata as objectionable without saying why, ask in App Store Connect which exact element is the problem and why before you redo everything. Review screenshots, subtitle and keywords together before resubmitting, because fixing one can expose the next.

95. 

    Guideline 5.2.5 Legal, Intellectual Property iOS Guideline 5 Legal Metadata and IAP

    Rejected under 5.2.5 because the screenshots used a device that looked like an iPhone

    What happened

    A developer was rejected under guideline 5.2.5. App Review said the metadata contained imagery similar to an iPhone in the screenshots, which could confuse users with Apple products. The devices shown were not Apple devices, only Apple like ones, and the developer was surprised because another of their apps had already been approved with the same kind of device imagery.

    Resolution

    Final outcome not shared at time of posting. Another developer replying noted that App Review can also object to device frames that do not match the platform or renders that look different from real iPhones.

    Lesson

    Approval of one app does not set a precedent for the next. Device mockups that look almost like an iPhone can be treated as confusingly similar to Apple products. Use plain screenshots, or only device frames Apple provides for marketing, and make sure they match the platform.

96. 

    Guideline 2.1 Information Needed iOS Guideline 2.1

    First iOS app got a 2.1 information request, and the fix was making everything findable

    What happened

    A solo developer whose Android version was already live on Google Play submitted their first iOS app. It had three in app purchases and user generated content. App Review did not reject it outright but sent a guideline 2.1 information request. The developer reread guideline 2.1, which requires every in app purchase to be visible and working for the reviewer, and also checked the rules for user generated content (1.2) and account deletion (5.1.1(v)). The next day they resubmitted a new build with a visible report and block option on every piece of user content, community rules users accept before posting, sign out and switch account, and a screen recording showing where the purchases, safety tools and account controls are.

    Resolution

    New build submitted the day after the request. Outcome not known at time of posting.

    Lesson

    Treat review like a usability test with a stranger on a short clock. Every purchase, report and block option, and account control should be findable in seconds, and a recording in the review notes should point to each one. Being live on Google Play says nothing about passing App Review.

97. 

    Guideline 4.3(a) Design, Spam iOS Guideline 4.3 Endless review

    Twenty seven days in the queue for a new app, then a 4.3(a) spam rejection

    What happened

    A developer submitted a brand new app and waited 27 days for App Review to look at it. When the result finally showed up in App Store Connect, it was a rejection under guideline 4.3(a), Design, Spam. The developer then asked other developers whether anyone had ever gotten past a 4.3(a) rejection.

    Resolution

    No resolution was shared at the time of posting. The developer was looking for advice from others who had been through 4.3(a).

    Lesson

    A long wait is not a sign that the app is safe. With review queues this slow, a 4.3(a) rejection after weeks costs a whole month. Before submitting a new app, be honest about what makes it different from the apps already in its category, and say so clearly in the review notes and the metadata.

98. 

    Guideline 4.3(a) Design, Spam macOS Guideline 4.3

    The iPhone app was already live, then its Mac version was rejected as spam

    What happened

    A developer had an iPhone app already live on the App Store and built a native desktop version of the same app for the Mac. App Review rejected the Mac app under guideline 4.3(a). The message said the app shared a similar binary, metadata or concept with apps submitted by other developers, with only minor differences, and suggested submitting a unique app with distinct content and functionality. The developer asked the community what had worked for others facing 4.3.

    Resolution

    No resolution was shared at the time of posting.

    Lesson

    Each platform gets its own review, and an approved iPhone app does not carry over to the Mac. A 4.3(a) message compares your app with apps from other developers, so when you reply, explain concretely what your app does that similar apps do not, and point to the features that only exist in yours.

99. 

    Endless review iOS Endless review

    More than fourteen days in review ended in a rejection, and the resubmission waited two more weeks

    What happened

    A developer said their previous review took more than fourteen days and ended in a rejection. They resubmitted on October 21, and almost two weeks later the submission was still in Waiting for Review, while Apple says most reviews take 24 to 48 hours.

    Resolution

    Still waiting for review at the time of posting.

    Lesson

    Average review times do not describe the worst case, and a rejection sends you back to the end of a slow queue. Plan launches with weeks of margin, and make the first submission as complete as possible so a rejection does not double the wait.

100. 

     Account deletion requirement (guideline 5.1.1(v)) iOS Guideline 5.1.1

     Rejected for missing account deletion, after the first reviewer had deleted several accounts

     What happened

     A developer with an app built around public user generated content was rejected on its second review for missing account deletion. Their logs showed that during the first review, the reviewer had created and deleted several accounts without any problem. The developer felt the rejection had more to do with the strict category than with the feature actually being missing.

     Resolution

     No resolution was shared at the time of posting.

     Lesson

     Even when a feature works, a reviewer has to find it quickly. Put the account deletion path in the review notes with the exact screens to tap, and attach a short recording. For apps with user generated content, also show reporting, blocking and moderation, because those categories get the closest look.

101. 

     Guideline 2.1(a) App Completeness macOS Guideline 2.1

     A Mac app rejected under 2.1(a) for reading the login keychain, and the old rejection notes vanished

     What happened

     A developer submitted a Mac app and App Review rejected it under guideline 2.1(a) because the app read from the login keychain. The fix took a single update. What caught the developer off guard was App Store Connect itself: it only shows the last ten submissions, so older rejection messages quietly disappear from the history.

     Resolution

     Fixed in one update. The developer now copies every rejection message into the commit that fixes it.

     Lesson

     Do not rely on App Store Connect as your record of past rejections, because older submissions drop out of view. Save the full rejection text next to the fix, in the commit, the ticket or your release notes, so you still have the exact wording if the same issue comes back.

102. 

     Guideline 1.4.1 Physical Harm (health and medical) iOS Endless review

     Ten days in review for a health app, then a 1.4.1 rejection fixed with a sources page in one afternoon

     What happened

     An indie developer building a health app waited more than ten days in App Store review. The verdict was a rejection under guideline 1.4.1, which covers health and medical apps. The fix was small: the developer added a sources page citing where the health information in the app comes from, and it took a single afternoon to build.

     Resolution

     Added a sources page with citations, which took one afternoon. Whether the resubmission was approved was not shared in the post.

     Lesson

     Health apps are held to a higher bar, and a long wait can end with a request you could have met before submitting. If your app shows health or medical information, add clear citations for it in the app before the first submission. One developer replying noted that a visible reminder to check with a doctor is another common ask.

103. 

     In app purchase too hard for the reviewer to reach (guideline number not stated) iOS Metadata and IAP

     A game update rejected because the paywall was too deep, then through in 26 hours once unlock moved to the title screen

     What happened

     An indie developer needed 33 days and two rejections to get version 1.0 of their iOS game approved. The first update, 1.0.1, was rejected as well, because the paywall sat too deep in the game for the reviewer to reach. The developer added an unlock button to the title screen and resubmitted. This time the whole process took about 26 hours, with only about 12 minutes actually in review.

     Resolution

     Added an unlock button on the title screen. The update went through about 26 hours after resubmitting.

     Lesson

     A reviewer will not play your game for twenty minutes to find what you sell. Put every purchase where it can be reached in seconds, or describe the exact path in the review notes, so the reviewer can test it without digging.

104. 

     In app purchase metadata mismatch (guideline number not stated) iOS Metadata and IAP

     Rejected because the paywall said 1 month free while Apple showed the annual charge

     What happened

     A developer moved from weeks on TestFlight toward a public App Store launch and had one build rejected over the paywall. The paywall said 1 month free, but Apple purchase screen showed the annual charge starting that same day. The reviewer also could not find the weekly plan. The developer fixed the paywall copy and plan visibility, submitted another build, and waited through review again.

     Resolution

     Fixed the paywall so the free trial wording matched the purchase sheet and the weekly plan was reachable. The app later went live on the App Store.

     Lesson

     What your paywall promises must match what Apple purchase sheet shows, including trial length and when billing starts. Put every plan the reviewer needs to test where they can reach it in a couple of taps, and check that path on a fresh install before you submit.

105. 

     Guideline 2.1 App Completeness (crash on launch) iOS Guideline 2.1

     A resubmit with bonus performance fixes crashed on start and cost a full day

     What happened

     After a first App Store rejection that was only a request for more information, the developer decided to bundle performance fixes into the same resubmission. They were so confident that they also removed a hardware gate meant for gaming tier devices. App Review rejected the build again because it crashed on start, with no crash log, only an automated message. The developer assumed a memory kill, put the gate back, and spent the day shrinking assets, deferring loads, and freeing resources without losing performance.

     Resolution

     Restored the hardware gate, cut the memory footprint, and prepared a third submission for the next day. The final outcome after round three was not shared in the post.

     Lesson

     Do not pile unrelated fixes into a resubmission meant to answer a review question. Ship the smallest change that answers the rejection, keep stability gates in place for the lowest device you claim to support, and cold start on that device before you upload again.

106. 

     Guideline 4.3(a) Design Spam iOS Guideline 4.3

     Several small games submitted together all hit 4.3(a), then two appeals were overturned

     What happened

     A developer submitted several small games to the App Store around the same time. Every one of them was rejected under guideline 4.3(a) for spam. After that wave, they changed process and now submit only one game at a time. Two of those rejections were later overturned after an appeal to the App Review Board.

     Resolution

     Switched to one submission at a time. Two of the 4.3(a) rejections were overturned on App Review Board appeal.

     Lesson

     Bunching similar apps into the same review window invites a spam finding across the set. Submit one at a time, and if a 4.3(a) rejection looks wrong, appeal to the App Review Board with a clear case for how each app is distinct.

107. 

     Guideline 1.1 Safety, Objectionable Content (app metadata) iOS Objectionable content Metadata and IAP

     A recovery app was rejected under 1.1 because its marketing named the habit it helps people quit

     What happened

     An app built to help people overcome porn and lust was rejected under guideline 1.1. App Review said the app marketing referenced objectionable content in its metadata, including the description, screenshots and keywords. When the developer asked for details, App Review named one keyword, porn, said that list was not exhaustive, warned that the app would get a full review on resubmission, and said that resubmitting with the same marketing, or as a new app with the same concept, would bring the same or more violations. The developer pointed out that similar apps already on the store openly market help with sexual temptation.

     Resolution

     Not resolved at the time of the post. App Review asked for every reference to objectionable content to be removed from the metadata before a full re-review, and the developer publicly questioned why similar apps were treated differently.

     Lesson

     Apps that help people quit something adult are judged on the words in their own marketing, not on their intent. Describe the goal, like recovery or self control, rather than naming the vice in keywords, description and screenshots, and ask App Review which exact terms triggered the rejection before you resubmit, because the next submission gets a full review.

108. 

     App icon flagged as objectionable (guideline number not stated) iOS Objectionable content Metadata and IAP

     An app icon that was already approved got rejected for showing too much skin

     What happened

     An AI app used an illustrated character as its app icon, wearing a crop top that showed some chest and midriff. That same icon had passed App Review before. On a later submission, Apple rejected it because the chest and belly were too exposed. The developer redrew the character in a full top that covered both and resubmitted.

     Resolution

     Redrew the icon so the top covered the chest and midriff. The post did not say how long the new review took.

     Lesson

     An earlier approval does not lock in your icon or screenshots, because each submission can be judged again. If a character in your art shows skin, assume a stricter reviewer may flag it, and keep a more covered variant ready so the fix is a swap, not a redesign.

109. 

     Subscription cancellation flow (guideline number not stated) iOS Metadata and IAP

     Rejected for an extra are you sure step at cancel, a week before Apple launched retention messaging

     What happened

     A subscription app showed its own are you sure screen when users went to cancel. App Review rejected the app for it. Less than a week later, App Store Connect announced retention messaging, which lets developers show subscribers a message, with an optional image or a retention offer, when they try to cancel their subscription.

     Resolution

     The post did not say how the rejection was fixed. The new App Store Connect feature now gives an Apple approved way to show a message at cancel time.

     Lesson

     Do not put your own friction in front of subscription cancellation. Let users reach the cancel flow directly, and if you want one last chance to keep them, use Apple retention messaging and offers instead of a custom screen.

110. 

     Guidelines 5.6 Developer Code of Conduct and 2.5.19 Hidden Features iOS Guideline 5.6 Developer Code of Conduct Guideline 2.5.19 Hidden Features

     Rejected under 5.6 for hidden features that turned out to be checkout code bundled in a subscription SDK

     What happened

     A solo developer had an iOS goal tracking app rejected seven times on the way to launch. One earlier rejection had been about real money stakes. The last one came under the Developer Code of Conduct: App Review said the app had hidden or misleading functionality and asked for all hidden features to be removed, without saying which one. The app had no remote feature flags, no downloaded code and no special behavior for reviewers. Instead of guessing, the developer scanned their own release binary and found web checkout code from a payment provider that they had never written. It came bundled inside their subscription SDK for that SDK web platform, and the iOS app never used it. Given the earlier money stakes rejection, the developer suspected it looked like a hidden payment path.

     Resolution

     Without changing any code, the developer replied to App Review with plain facts: what the app does and does not do, that it has no real money stakes, where the checkout code came from, that the unused SDK web code and an unused photo library permission would be removed in the next build, and a request to name the flagged screen. About nine hours later App Review said it would continue the review, and the app went live.

     Lesson

     Know everything your binary ships, including code your SDKs bring in for other platforms, because App Review judges what is in the build, not what you call. After a 5.6 rejection, do not guess and resubmit. Reply calmly with specifics and ask which screen or behavior was flagged.

111. 

     Guideline 2.3.4 Accurate Metadata (App Previews) iOS Metadata and IAP

     An App Preview that passed review in October was rejected under 2.3.4 for its framing a month later

     What happened

     A developer submitted an update to their iOS app and it was rejected under guideline 2.3.4. App Review said the App Preview video had framing around the screen capture. The same video had passed review the month before. The developer pointed out that other apps on the store, including a well known one whose preview shows a person rather than the app, use App Previews with little or no footage of the app itself.

     Resolution

     The developer removed the App Preview video entirely and resubmitted the update. The post did not say how the new review went.

     Lesson

     An App Preview that passed once can still be rejected on a later update, because every submission is reviewed again. Keep previews to plain screen captures of the app without decorative framing around the capture, and if one gets flagged, removing it is the fastest way to unblock the update while you rework it.

112. 

     Section 3.2(f) (Developer Program License Agreement) macOS Account termination Endless review

     A macOS update that fixed an icon issue sat in review for about 45 days, then a 3.2(f) notice arrived

     What happened

     An independent developer had a macOS app that App Review had flagged over branding concerns. On September 15, 2026, they submitted an update that addressed the feedback, including a fully redesigned app icon. The update then stayed In Review for about 45 days with no decision, and the developer sent two expedited review requests through the official channels. On October 30, 2026, while that corrected update was still waiting, a Pending Developer Account Termination Notice arrived under section 3.2(f).

     Resolution

     Appeal pending at time of posting. The developer filed a formal appeal and contacted Developer Support separately, and had not received a substantive response.

     Lesson

     A fix waiting in the queue does not pause enforcement on older submissions. Keep a dated record of every rejection, every change you made in response and every expedite request, so an appeal can show exactly what you corrected and when.

113. 

     Guideline 3.2.2 Unacceptable Business Models iOS Guideline 3.2.2

     A paid step challenge app was rejected under 3.2.2, and a call with App Review confirmed the whole model was out

     What happened

     A team that already ran a fitness app with thousands of users built a second iOS app around paid step challenges: users pay a fee to join a walking challenge, the same basic model as several fitness apps already on the store. App Review rejected it under guideline 3.2.2. The explanation was that any penalty based model is not allowed, whether users pay before the challenge starts or get charged after missing a goal. The team met with the App Review team to ask what to change, and was told the concept itself was not allowed, not one specific screen or step in the flow.

     Resolution

     The team decided not to appeal because they did not want to put their developer account at risk. At the time of posting the app was not on the store, and they still did not understand why apps with the same model remain live.

     Lesson

     Similar apps already on the store are not a precedent App Review will accept, because your build is judged against how the guideline is read today. If money changes hands based on whether a user hits a goal, check that model against 3.2.2 before building the whole product around it, for example by asking App Review directly.

114. 

     Guideline 5.6 Developer Code of Conduct iOS Guideline 5.6 Developer Code of Conduct

     An update rejected under 5.6 for hidden features got the exact same rejection after a second review that took almost three weeks

     What happened

     A developer submitted an update to their iOS app and it was rejected under the Developer Code of Conduct. The notice said App Review had seen a pattern of unusual behavior commonly associated with fraudulent activity, specifically features that appeared to have been intentionally hidden during review. The developer said nothing in the app was hidden and it used no tricks or misleading behavior. They uploaded the app again with an explanation of exactly what it does, then waited almost three weeks for the second review. It came back with the exact same rejection, still without naming any feature or screen.

     Resolution

     Unresolved at the time of posting. The developer said they would file an appeal.

     Lesson

     A generic 5.6 notice that names no feature rarely clears with the same build plus an explanation. Ask App Review in the thread which screen or behavior was flagged, check what every SDK in your binary ships, and use the formal appeal when replies go nowhere.

115. 

     Guideline 4.3(a) Spam iOS Guideline 4.3

     A new game in an indie series was rejected under 4.3(a) as too similar to the developer's own earlier games

     What happened

     An independent developer was preparing the iOS release of a new game in their own series, while also translating it into more languages. App Review rejected the iOS version as spam under guideline 4.3(a), saying it was too similar to the developer's previous games. The developer had significantly reworked the core battle system, but admitted that parts carried over from the series, such as the basic interface, icons and logo, still looked much like the earlier titles. App Review only sent the standard rejection message, and a week after asking for more details the developer had no reply.

     Resolution

     Unresolved at the time of posting. The developer was explaining to App Review what makes the new game different from the earlier titles, and said they could not tell when or whether the iOS version would ship.

     Lesson

     Under 4.3(a), your own back catalog counts as the comparison, so a sequel that reuses the interface, icons and branding of earlier games can read as a duplicate even when the gameplay changed. Make the new parts obvious in the build and screenshots, and list them for the reviewer in the notes before you submit.

116. 

     Guidelines 5.2.5 and 2.3.10 iOS Guideline 5 Legal Guideline 2.3.10

     An app for making store screenshots was rejected because its own icon showed the App Store logo

     What happened

     A developer built an app that helps people create screenshots for both the App Store and Google Play. Its first iOS build was rejected under two guidelines. Under 5.2.5, the app icon showed the App Store logo next to the Google Play logo, and the subtitle in the listing started with the words App Store. Under 2.3.10, Google Play appeared in the iOS build itself, in the binary, the icon and the screenshots. The developer had looked at that icon every day for weeks without seeing a problem.

     Resolution

     The developer redrew the icon, rewrote the subtitle, and added one switch that hides Google Play everywhere in the iOS version, from onboarding and export to settings and error messages, while leaving saved projects untouched and keeping both stores on Android. They explained the change in one line in the review notes. The second build had been waiting for review for at least three days at the time of posting.

     Lesson

     Apple reviews the icon and subtitle as strictly as the screens. Even when your app is about app stores, keep Apple marks out of the icon and listing, and make sure no other store name appears anywhere in the iOS build, screenshots included.

117. 

     In app purchase failure (guideline not stated) iOS Metadata and IAP Endless review

     A game was rejected three days after its announced release date because a purchase failed while the reviewer was offline

     What happened

     An independent developer had already announced a release date for their game. The build sat in review for a little over a week and only moved after they asked for an expedited review. It was finally rejected three days after the announced date. Judging by the screenshot attached to the rejection, the reviewer had no internet connection when they tried to make an in app purchase. The app did show an error saying the purchase failed, but the message was vague.

     Resolution

     The developer appealed and still had no answer about a month later. In the meantime they redesigned the interface, rewrote the error messages to explain more clearly what went wrong, and planned to resubmit the improved version.

     Lesson

     Reviewers can hit bad networks too. Try every purchase with no connection and with a failing store request, and make sure the app shows a clear message and a way to retry. Avoid announcing a launch date before the build is approved.

118. 

     Crash, subscription, EULA and paywall rejections (guideline numbers not stated) iOS Guideline 2.1 Guideline 3.1.2 Endless review

     A first iOS app took 37 days and four rejections, with each review finding a new problem

     What happened

     A developer submitted their first iOS app, which sells subscriptions, on October 1. Eight days later it was rejected for a crash. They resubmitted the next day, and about two weeks later it was rejected over its subscriptions. The next resubmission was rejected two days later over the EULA. The fourth rejection, on November 5, was about the links on the paywall and the previews. Every round surfaced an issue the earlier reviews had not mentioned.

     Resolution

     Approved on November 7, 37 days after the first submission. The developer was happy to launch but said review could be faster and more transparent for indie developers.

     Lesson

     A rejection does not always list every problem in the build. Before the first submission, check launch on a real device, the subscription details, a Terms of Use (EULA) link, and the paywall links together, because each extra round can cost a week or more.

119. 

     Guideline 2.4.5 Mac App Store Requirements macOS Guideline 2.4.5

     A Mac screen recorder was rejected under 2.4.5 for showing keystrokes on screen, and shipped 27 days later without the feature

     What happened

     An indie developer submitted a screen recording app to the Mac App Store. A week later it came back rejected under guideline 2.4.5. One of its features displayed the keys the user was pressing on top of the recording, and App Review said apps distributed through the Mac App Store are not allowed to read keyboard input that way.

     Resolution

     The developer did not dispute the decision. They removed the keystroke display, resubmitted eleven days after the rejection, and the app was approved about nine days later, 27 days after the first submission. The store build now does less than the version the developer runs on their own Mac.

     Lesson

     Features that watch the keyboard, the screen or other apps are where the Mac App Store rules bite hardest. If a feature depends on reading input outside your own app, check it against 2.4.5 before you build your launch around it, and decide early whether it belongs in a version you distribute outside the store instead.

120. 

     Guideline 2.1(a) App Completeness iOS Guideline 2.1

     An iPhone app was rejected under 2.1(a) because a bottom button covered content on the iPad App Review used

     What happened

     A developer who tested only on their own iPhone noticed that their rejection messages listed an iPad Air as the review device. One rejection was filed under guideline 2.1(a): a button pinned to the bottom of the screen sat on top of content, and the only evidence was a screenshot Apple attached. iPhone apps run on iPad inside a compatibility window that is roughly 664 points tall, and the affected screen could not scroll, so the button covered part of it. The same overlap showed up on a small iPhone.

     Resolution

     The developer traced the cause to the fixed bottom button on a screen that could not scroll, and now runs a check for this layout problem before every submission. They did not share how long the resubmission took.

     Lesson

     App Review may test an iPhone app on an iPad even if you never targeted iPad, so the device in the rejection can be one you do not own. Let every screen scroll when its content can grow, and test at the smallest heights your app can be shown at, including the iPad compatibility window and the smallest supported iPhone.

121. 

     App Store Connect agreements Apple Developer Program Endless review

     An app sat in Waiting for Review for more than three weeks until the developer accepted updated agreements

     What happened

     An indie developer submitted an app and watched it sit in Waiting for Review for more than three weeks with no movement and no explanation. The cause was on their side of App Store Connect: Apple had published updated Developer Program agreements and terms, and they had not accepted them yet. The developer said nothing notified or warned them that the pending agreements were holding up the review.

     Resolution

     Once the developer accepted the new agreements in App Store Connect, the submission started moving again.

     Lesson

     When a submission stalls far beyond normal review times, check the agreements section of App Store Connect before assuming you are just stuck in a slow queue. Pending agreements are easy to miss, and nothing on the submission itself may point to them.

122. 

     Guideline 2.1, then Guideline 4.3(a) Design: Spam iOS Guideline 4.3 Guideline 2.1

     Three apps waited ten days for a 2.1 rejection, then all three were rejected under 4.3(a) a week after the developer explained them

     What happened

     A developer submitted three new apps at the same time. All three sat for about ten days with no movement, then came back rejected under guideline 2.1. The developer answered the questions and explained each app. After roughly another week of silence, all three were rejected again, this time under 4.3(a) Design: Spam, with the standard notice saying the apps shared a similar binary, metadata or concept with other apps and had only minor differences.

     Resolution

     The developer had lost almost a month across the three submissions and had not shared a next step when they posted about it.

     Lesson

     Answering a 2.1 information request does not mean an app is past the bigger question. When several apps from one account land together, the next round can turn into 4.3, so submit them one at a time and make what is different about each app obvious in the build, the screenshots and the review notes before the first review, not after it.

123. 

     Bug rejection on iPad (guideline number not stated) iOS Endless review

     A first app needed three review rounds and 37 days of waiting because its paywall kept loading forever on iPad

     What happened

     A solo developer waited nine days for the first review of their app. It came back rejected because the paywall got stuck loading forever on an iPad, a device the developer did not own and had not tested on. They fixed it and resubmitted within two days. During the second wait they asked for an expedited review and opened a support ticket, and heard nothing back. After 14 days the second review rejected the app again for the same endless loading on the iPad paywall, which the developer could not reproduce in the simulator.

     Resolution

     The developer rebuilt the purchase logic from scratch and resubmitted. The third review also took 14 days, and the app was approved after 37 days of total waiting across three rounds.

     Lesson

     App Review tests on iPad, so a purchase flow that has only ever run on your own iPhone is a risk. When each review round takes about two weeks, every missed bug costs another two weeks. Test the paywall on a real iPad with a sandbox account and a slow connection before you submit, and give the loading state a timeout with a clear error instead of a spinner that never ends.

124. 

     App Review Guideline Issue, price verification iOS Metadata and IAP

     A review was paused by an automated message asking the developer to confirm a $9.99 weekly subscription price

     What happened

     A developer's submission stopped with an automated App Review message. The review could not continue until they confirmed that one in-app purchase, a weekly subscription priced at $9.99, had the price they intended. The same paywall also offered cheaper plans, and it was the first time the developer had seen a review paused over pricing.

     Resolution

     The developer replied in App Store Connect to confirm the price was intentional and was waiting for the review to resume at the time of writing.

     Lesson

     Apple can stop a review to double check a price that looks high or out of line with the rest of a paywall. It is not a rejection yet, so answer quickly in App Store Connect, say the price is intended, and briefly explain how that plan relates to the cheaper options so the reviewer has nothing left to ask.

125. 

     Guideline 2.1(b) App Completeness, in-app purchase not available iOS Guideline 2.1 Metadata and IAP

     An update was rejected because its paywall loaded the plans of the team's other app, and it was approved the same evening

     What happened

     A small team submitted an update to their iPhone app. App Review rejected it under guideline 2.1(b) because the reviewer could not find the in-app purchase and reported it as not available. The cause was a single configuration value. The paywall was set to load the subscription plan list that belonged to another app from the same team, so in this app it had nothing to show or sell.

     Resolution

     They pointed the paywall at the app's own plan list and resubmitted about seven hours after the rejection. The update was approved roughly an hour and a half later, about eight and a half hours after the rejection.

     Lesson

     When one team runs several apps on the same subscription setup, plan and product IDs are easy to cross. Before you submit, open the paywall in a fresh sandbox install of the exact build and check that it loads this app's own products, because a reviewer who sees an empty paywall will reject the app as incomplete.

126. 

     Missing review video, then a crash on lower end devices (guideline number not stated) iOS Endless review

     A new iPhone app took 17 and a half days and two rejections, first for a missing review video, then for crashing on lower end phones

     What happened

     In the same few weeks, a developer had a new Mac app and a visionOS update approved in about two days each. Their new iOS app went very differently. After eight days of waiting it was rejected because the review notes did not include a video of the app. For the next build the developer had also widened the list of supported devices. About two and a half days later it was rejected again, this time because the app crashed on lower end phones that the wider device list now included. The developer described both rejections as automatic.

     Resolution

     The next submission was approved after about seven more days, roughly 17 and a half days after the first one.

     Lesson

     Two avoidable rounds cost more than two weeks here. Attach a short screen recording of the main flow to the review notes from the very first submission, and never widen device support in the same build as a review fix unless you have tested on the oldest and smallest devices you just added.

127. 

     Guideline 2.1 App Completeness (crash after first launch) iOS Guideline 2.1

     A 1.0.1 update was rejected overnight for crashing after launch, with no crash log, and the crash could not be reproduced anywhere

     What happened

     An indie developer's 1.0.1 update was rejected overnight with a one line reason: the app crashed after the initial launch. The notice had no crash log, no device model and no steps to reproduce. The developer rebuilt that exact build in Release mode and replayed a first launch on three simulators, covering fresh installs, permission prompts and relaunches, without a single crash. The same build installed from TestFlight on their own iPhone also ran fine.

     Resolution

     They replied to App Review asking for the crash log and resubmitted the same build. They were still waiting for an answer at the time of posting.

     Lesson

     A crash you cannot reproduce usually lives in a state the reviewer hit and you did not, such as another device, OS version, region, network or a brand new account. Ask for the crash log in your reply, and test a clean install on a real device that is not your daily phone, on the oldest iOS version you support, before you send the same build back.

This page is not legal advice and does not predict what Apple will do on your next submission.