Fastest fix: find the exact phrase the reviewer quoted, decide whether it is true / partly true / false against the submitted build, then either delete the claim, add a qualifier, or rewrite your Review Notes to point the reviewer at the screen that proves it. If you only touch text and screenshots, you resubmit metadata with no new build and the status moves back to Waiting for Review, usually within 24 hours.
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 (accurate metadata), 2.3.7 (in-app purchase / pricing metadata), or 5.0 / 5.2 (legal + intellectual property). 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 by shipping a new binary alone. 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.
As of June 2026 this is Metadata Rejected most of the time, which means the version stays in review and you can edit text/screenshots and resubmit without uploading anything from Xcode.
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
# Clean the status bar first (9:41, full battery, full wifi, no carrier)
xcrun simctl status_bar booted override \
--time "9:41" --batteryState charged --batteryLevel 100 \
--dataNetwork wifi --wifiMode active --wifiBars 3 --operatorName ""
# Then capture the running simulator
xcrun simctl io booted screenshot ~/Desktop/screen_6.9inch.pngAs of June 2026, Apple requires one screenshot set at the largest size per device family and auto-scales it to every smaller size in that family. You no longer upload a separate 5.5” or 12.9” set.
- iPhone (required): 6.9” —
1320 x 2868px (iPhone 17 Pro Max / 16 Pro Max). The older1290 x 2796(6.7”) and1284 x 2778(6.5”) are still accepted as a fallback, but the native 6.9” asset renders best. - iPad (required if your app runs on iPad): 13” —
2064 x 2752px (iPad Pro M4/M5). The legacy2048 x 2732(12.9”) is also accepted. - PNG or JPEG, RGB, no alpha, exact pixel dimensions (no off-by-one tolerance), 1-10 images per family.
No Photoshop touch-ups beyond cropping the status bar. The reviewer compares your screenshots against the running binary, so the captured screen must match what a cold-install user sees.
Step 4: Rewrite Review Notes to point reviewer at the claim
In App Store Connect → your app → the Distribution tab → select the version in the sidebar → scroll to 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 roughly two minutes per app, so concrete tap-by-tap notes often turn a rejection into an approval on resubmit.
Step 5: Submit metadata change (and binary if needed)
If only description / screenshots / Review Notes changed and the binary still demonstrates the claims:
- App Store Connect → Distribution tab → version → edit the localized fields under Version Information (Description, Promotional Text, Keywords) and the screenshot wells → Save → Add for Review / Submit for Review. No new build is needed; metadata-only resubmits skip Xcode entirely. Live-app edits can take up to 24 hours to propagate.
If you removed or gated a feature in the binary:
- Archive a new build in Xcode → upload via Organizer (or
xcrun altool/ Transporter) → wait for processing → attach the new build number to the version → submit.
How to confirm the fix
- The Resolution Center thread shows your reply timestamped after the edit.
- Status moves from Rejected to Waiting for Review, usually within 24 hours.
- A fresh TestFlight or live download shows the cited feature within
60 secondsof user interaction, from a cold install. - A re-review (even by a different reviewer) does not cite the same Guideline again.
If it still fails
- Reply in Resolution Center with timestamped screenshots or a short screen recording showing the feature working from cold install. Keep it factual; the same reviewer usually reads the thread.
- Ask for a phone call directly in the Resolution Center thread (for example: “Could we schedule a call so I can demonstrate this feature live?”). Calls run about 15-30 minutes; have the build open and ready to demo. Phone reviewers can override a metadata rejection on the spot.
- If the cited wording is industry-standard (e.g., “AI-powered” for an LLM wrapper), point to live competitor apps using identical phrasing as precedent — but still make sure the feature is reachable in your build.
- Last resort: file a formal appeal at developer.apple.com/contact/app-store → topic Appeal. The App Review Board typically responds in about 5-7 business days and its decision is usually final, so 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 within
60 secondsfrom 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 one-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: ten minutes with a teammate who hasn’t seen the build, reading the description aloud and asking “show me this in the app.”
FAQ
Do I have to upload a new build to fix a misleading-metadata rejection? No, if the binary already does what the listing claims. A 2.3.1 metadata rejection keeps the version in review, so you edit the Description, screenshots, or Review Notes and resubmit with no Xcode upload. You only need a new build if you removed or gated a feature in the binary itself.
Why did only my Japanese (or German) listing get rejected when English was fine? Each localization is reviewed against the same build. If a localized description adds a superlative the base language doesn’t (“automatically writes perfect emails” vs “helps you draft emails”), the reviewer rejects that locale specifically. Diff every localization against the base under the Distribution tab and strip the extra promises.
Is “AI-powered” still safe to use in 2026? Yes, when there’s a real model behind it. Apple tightened scrutiny on apps that label static templates as “AI,” and reviewers will run the feature twice expecting non-identical output. If your feature returns byte-identical results or rotates through a few fixed presets, drop the “AI” wording or describe the actual mechanism.
How long until the status changes back after I resubmit? Metadata resubmits typically return to Waiting for Review within 24 hours, then go back In Review. Live-app changes (for an already-approved version) can take up to 24 hours to appear on the storefront.
The reviewer says “feature not observed” but it works for me. What now? The reviewer almost certainly couldn’t find it. Rewrite Review Notes with the exact tap path (tab → button → wait time), attach a short demo recording, and if the feature is gated behind a login or paywall, give a working sandbox/test account in the Review Notes. If they still miss it, ask for a call in the Resolution Center thread.