Skip to main content

Community rejection archive

App store refusal horror story

The worst Apple App Store and Google Play rejection loops, collected as screenshots and plain text so mobile teams can learn what review queues really cost.

Submission rule

1 to 5 images plus the story text.

No links inside stories. Use local images only. Keep the refusal painful, specific, and useful.

6

stories seeded

2

stores covered

5 max

images per story

The archive

Rejections that cost more than a bad sprint

Each story is text-first, image-backed, and intentionally free of external links so the archive stays readable.

Apple App Review message asking who will be the users of Adrien app
Apple App Store Absurd Shared by Adrien

The app with users Apple could not identify

"Who will be the users of this app?"

Adrien submitted version 1.0 and Apple stopped the review under Guideline 2.1, Information Needed. There was no crash report, no broken feature, and no requested binary fix in the message. The only blocker was that Apple wanted a detailed answer explaining who the app was for before review could continue.

App
Version 1.0 iPad app
Delay
Review paused on May 29, 2026
Outcome
Apple asked for a target-user explanation before continuing review.
Apple App Review message saying Adrien app did not differ enough from similar apps
Apple App Store Painful Shared by Adrien

The app Apple decided was not different enough

"There are already enough of these apps on the App Store."

Adrien got a Design - Spam refusal because Apple did not see enough distinct value compared with similar apps. The review said the app was primarily a fart or burp app, and even if it had features that distinguished it, that functionality was prominent enough for Apple to treat the whole app as duplicate content in a saturated category.

App
Entertainment sound app
Delay
Rejected on May 15, 2026
Outcome
Apple rejected it under Guideline 4.3(b), saying the app duplicated a saturated category.
App review guide screen used to represent an Apple App Store rejection workflow
App Store publishing interface used to represent a delayed Apple review
Apple App Store Launch blocker

The metadata loop that ate launch week

"The build was fine. The rejection kept moving from the app to the words around the app."

The team shipped a clean build, then spent more than a week cycling through metadata objections. Each resubmission answered the previous note, but the next reply focused on another phrase, screenshot, or explanation. No code was changed. The launch calendar, press window, and paid acquisition plan were all held hostage by review copy.

App
Consumer productivity app
Delay
9 days
Outcome
Approved after rewriting screenshots, subtitles, and review notes without a binary change.
App Store Connect build management screen representing a post-approval release blocker
App Store Connect compliance screen representing an extra compliance review step
Apple App Store Absurd

Approved, then blocked by one more compliance question

"The approval email landed before the blocker did."

The build reached approval, but release was still blocked by a compliance prompt the team thought had already been answered. The release owner had to stop rollout, gather legal wording, update the App Store Connect response, and wait again. Customers saw the announcement before the app was actually available.

App
B2B dashboard companion app
Delay
4 days
Outcome
Released after answering export compliance again and waiting for the next review pass.
Google Play Console releases screen representing a blocked release
Google Play Console artifact upload screen representing repeated Android submissions
Google Play Console save and publish screen representing a delayed publication
Google Play Expensive

The permission policy time sink

"The app needed the permission for one screen, but the review treated it like the whole product."

A narrow Android permission triggered a broad policy review. 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. The final build shipped with a degraded workflow while the team prepared a cleaner permission split.

App
Field operations app
Delay
13 days
Outcome
Approved after removing a permission, recording a new demo, and rewriting the store declaration.
Google Play Console confirmation screen representing a delayed hotfix publication
Mobile app interface representing a production hotfix waiting for store review
Google Play Painful

The hotfix that waited behind a policy queue

"The broken checkout was urgent for users, but not urgent for the review queue."

A checkout bug needed a fast mobile fix, but the store release entered review at the worst possible time. Support tickets climbed while the team watched the same pending status. They eventually mitigated the issue server-side, then watched the binary approval arrive after the emergency had already burned through the weekend.

App
Ecommerce app
Delay
6 days
Outcome
The native store fix arrived after the team had already mitigated the incident elsewhere.

Avoid the next horror story

Ship urgent fixes with Capgo while the stores take their time.

Capgo lets Capacitor teams send live updates, roll back broken releases, and target channels without waiting for a full App Store or Google Play review cycle.

Start with Capgo See live updates

Add a refusal story

Edit the story data, include one to five local image paths, and open a PR. Keep names anonymized unless you own the story.

Edit on GitHub