You submit, the build goes In Review, and a few hours later the status flips to Rejected with a Resolution Center note citing Guideline 2.3.1 (accuracy), 2.3.7 (metadata), or 5.0 / 5.2 (intellectual property + misleading). The reviewer usually pastes a screenshot of your App Store listing, highlights a phrase like “AI-powered photo editor” or “guaranteed weight loss,” and says either “this feature was not observed in the build” or “the screenshots do not match the app’s actual functionality.”
Unlike crash bugs, you cannot fix this with a build. Apple’s complaint is that your store page promises X but the binary delivers something less. Either change the promise, change the binary, or prove to the reviewer they missed where X lives.
Common causes
Ordered by hit rate. AI-feature apps in 2026 disproportionately hit #4.
1. Marketing copy describes a future-version feature
Roadmap leaked into the App Store description. “Coming soon: real-time collaboration” is fine; “work together in real time” with no working collab in the current build is a rejection.
How to spot it: Diff the App Store description against your release notes and feature flags. Any feature behind a featureFlag.collab = false toggle should not appear in copy.
2. Screenshots show UI from a different version, paid tier, or pure mockup
Marketing produced glossy screenshots in Figma, designers re-painted icons, or screenshots show the Pro plan but the free user lands on a stripped UI. The reviewer downloads the free build, sees the gap, rejects.
How to spot it: Open each screenshot file in Finder → Quick Look. Compare pixel-by-pixel with a freshly recorded screen capture from the submitted binary on the screenshot’s device size. Mismatched fonts, icon colors, or missing tabs = rejection bait.
3. Outcome claims with no in-app substantiation
“Lose 10 lbs in 30 days,” “Earn $500/month,” “Pass the bar exam.” If the app does not have a tracking mechanism, money disclaimer, or curriculum that justifies the claim, Apple cites 2.3.1.
How to spot it: For every quantified outcome in your description, find the screen in the app that delivers or measures it. No screen → remove the claim.
4. “AI” or “generated” labels for static templates
This is the 2026 hotspot. You wrap a fixed Lottie animation or a server-side template renderer and label it “AI-generated.” Apple has tightened scrutiny — reviewers will run the feature twice and expect non-identical output.
How to spot it: Run the AI feature 3 times with the same input. If the output is byte-identical or deterministically rotates through 4-5 presets, it’s not AI by Apple’s standard.
5. Localized metadata over-promises vs base language
Your English description says “helps you draft emails.” The Japanese localization says “automatically writes perfect business emails.” The reviewer compares — and rejects the locale that overpromises.
How to spot it: In App Store Connect → App Information → switch each localization → diff against the base. Any added superlative is risk.
6. Reviewer notes contradict the listing
You wrote in Review Notes “AI feature only works for Plus subscribers,” but the description does not mention the gate. Apple treats the gap as misleading.
Before you change anything
- Capture screenshots of the current store page in every locale before editing — App Store Connect doesn’t keep history.
- Confirm the exact Guideline number cited (2.3.1 vs 2.3.7 vs 5.2.x); each has a different fix path.
- Check whether the rejection is Metadata Rejected (no new binary needed) or Binary Rejected (must upload).
- Verify your App Review role (Account Holder / Admin / Marketing) can edit metadata.
Information to collect
- Exact rejection text + Guideline number + any screenshots Apple included.
- The current App Store listing in every locale (description, subtitle, promotional text, what’s new, keywords).
- Screenshot set + preview videos for every device size.
- Reviewer Notes content as submitted.
- The build the reviewer evaluated (number + uploaded date).
Shortest path to fix
Step 1: Categorize each cited phrase
Make a 3-column table:
| Cited phrase | Source (description / screenshot / in-app) | Truth status |
|---|---|---|
| ”AI-powered photo editor” | Description line 2 | Partially — uses Stable Diffusion API for one effect |
| ”Generates poems in seconds” | Screenshot 3 | False — feature shipped in v2.1, current is v2.0 |
| ”Pro features free for 30 days” | Promotional Text | True but gated behind sign-up |
Step 2: For each False or Partially row, pick a path
- False: Delete the claim. Update description, retake screenshot, or remove the feature card.
- Partially: Rewrite with a qualifier — “AI-powered effects in our portrait mode” instead of “AI-powered photo editor.”
- True but hidden: Add an in-app walkthrough or a static feature carousel that reviewers see before the gate.
Step 3: Retake screenshots from the actual binary
# Take a screenshot of the running simulator for each device size
xcrun simctl io booted screenshot ~/Desktop/screen_6.7inch.pngRequired sizes: 6.7” (iPhone 15 Pro Max), 6.5” (iPhone XS Max), 5.5” (iPhone 8 Plus), 12.9” iPad Pro 6th gen. No Photoshop touch-ups beyond cropping status bar.
Step 4: Rewrite Review Notes to point reviewer at the claim
In App Store Connect → App Review → App Review Information → Notes:
The AI photo enhancement feature is on the Home tab → tap any photo → tap "Enhance" button → wait 3-5 seconds. Output differs per input. Demo video: [private YouTube link].
The "30-day free trial" is shown on first launch onboarding screen 3 of 4. No payment required to start trial.Reviewers spend ~2 minutes per app — these notes save the rejection.
Step 5: Submit metadata change (and binary if needed)
If only description/screenshots changed and the binary still demonstrates the claims:
- App Store Connect → App Information → save changes → Submit for Review (no new build).
If you removed or gated a feature in the binary:
- Archive a new build in Xcode → upload via Organizer → wait for processing → attach to the version → submit.
How to confirm the fix
- The Resolution Center thread shows your reply timestamped after edit.
- Status moves from Rejected to Waiting for Review within 24 hours.
- A fresh download of TestFlight or the live build shows the cited feature in <60 seconds of user interaction.
- New reviewer (if escalated) doesn’t cite the same Guideline twice.
If it still fails
- Reply in Resolution Center with timestamped screenshots showing the feature working from cold install.
- Request a phone call — App Review Contact form → “Schedule a call.” Phone reviewers can override.
- If the cited claim is industry-standard wording (e.g., “AI-powered” for an LLM wrapper), cite competitor apps using identical phrasing as precedent.
- Last resort: file an App Review Board appeal. Document the differentiation in detail; appeals without new evidence almost always lose.
Prevention
- Treat App Store copy as a spec — every claim must map to a feature the reviewer can reach in <60 seconds from cold install.
- Maintain a
STORE-CLAIMS.mdfile alongsideCHANGELOG.md; review it in the same PR that changes the description. - Take screenshots in CI from the simulator after every release build, never from a designer’s Figma.
- For “AI” claims, write a 1-sentence justification: which model, which API, where output varies. If you can’t write it, don’t claim it.
- Localize claims, not just words — each locale’s marketer must run the feature in that locale and confirm the promise holds.
- Pre-submit checklist: 10 minutes with a teammate who hasn’t seen the build, reading the description and asking “show me this in the app.”