What to Check Before Sending Your App to Apple Review

About 40% of first-time iOS app submissions get rejected — and the majority fall on small, predictable issues that aren't in Apple's headline guidelines. Here's a pre-submission checklist that covers the things first-time submitters most often miss.

1. Legal links in three places, not one

Privacy Policy, Terms of Service, and a support email must be:

• Linked in your App Store listing description (last paragraph is fine).
• Reachable from inside the app — typically a Settings screen.
• Visible on the account creation screen itself. This one is rarely required outright, but it pre-empts a 5.1.1 rejection where the reviewer can't find the policy before signing up.

The URLs must resolve to public pages (no login wall, no 404). Use a real Privacy Policy that reflects what your app actually collects — generic templates that don't match your data flow are flagged on re-read.

2. Submit with a screen recording in reviewer notes

In App Store Connect → Notes for Review, attach (or link to) a 30–60 second screen recording:

• Logging in with the demo account
• Walking through the main feature
• Triggering the paywall (if you have one)

This single artifact prevents most "we couldn't complete sign-up" or "we couldn't find the advertised feature" rejections. Include the demo account credentials in plain text right below the link.

3. Configure IAP and subscriptions before submitting

If your app has any in-app purchases or subscriptions, they must be set up in App Store Connect and attached to the build before you submit — even if the IAP itself isn't yet approved. Apple's reviewer hits the paywall during review; if products don't load, the app gets rejected as broken.

Common gotcha: products created but not added to the in-review build. Verify under the build's "In-App Purchases and Subscriptions" section.

4. Account maintenance features Apple expects

If your app has account creation, you must ship all of these — missing any one is a common silent rejection:

• Account deletion in-app (Guideline 5.1.1(v), required since June 2022). Not just "email us to delete" — an actual self-service deletion flow.
• Forgot password / reset password flow.
• Change password in settings.
• Change email is nice to have but not required.

The delete-account flow should remove personal data, not just deactivate. State that clearly to the user before confirming.

5. Sign in with Apple — only if you have other social logins

Apple's rule (4.8) is conditional: if you offer any third-party social login (Google, Facebook, Twitter/X, etc.), you must also offer Sign in with Apple, and it must be at least as prominent. Email-and-password-only apps don't trigger this rule.

The cheapest path for many small apps: stay email-only on launch and skip Sign in with Apple entirely until you add social login.

6. Permission strings — write them like a copywriter

Every NS*UsageDescription string in Info.plist should explain why you need the permission, in the user's language, at the moment they'll see it. Reviewers reject when:

• The string is generic ("This app needs camera access")
• The reason doesn't match what the app actually does with the data
• A permission is requested but the feature using it isn't obvious

Bad: "Camera access required." Good: "AppName uses your camera to scan barcodes when you add items to your shopping list."

7. Test on a real device, with a fresh install

Vibe-coded and simulator-only testing misses things reviewers find within seconds:

• App crashes on first launch on a clean install (not on your devbox where data already exists)
• Onboarding loops back to itself
• "Sign up" works but "Sign in" silently fails
• Network calls fail on IPv6-only networks — Apple's review network frequently is IPv6-only, and v4-only backends will look broken to them

Test on at least one real iPhone, with a fresh install, and ideally over an IPv6-only network (you can simulate this on Mac via Internet Sharing settings).

8. Don't ship with "Test," "Beta," or "Debug" anywhere

Reviewers scan for these strings in:

• App name and subtitle
• Screenshots
• In-app copy, especially welcome screens and About pages
• Push notification copy if a reviewer happens to receive one

A single "Beta v0.9" label in a screenshot is enough for a 2.1 (App Completeness) rejection.

9. Keep your backend frozen during review

Once you submit, don't:

• Push migrations that change the response shape of endpoints your app calls
• Take staging down for maintenance (some reviewers' devices end up on staging URLs via TestFlight)
• Disable the demo account you provided in reviewer notes

Reviewers may test your app over a 2–4 day window. Anything that breaks mid-window can flip a passing review into a rejection.

Quick checklist before you hit submit

• Privacy Policy + Terms + Support email linked in App Store description, inside the app, and on signup
• Screen recording + demo credentials in Notes for Review
• All IAPs/subscriptions created and attached to the build
• Account deletion, password reset, and change-password all implemented and tested
• Sign in with Apple added if (and only if) you have other social logins
• All permission strings explain what and why in plain English
• Fresh install on a real device passes — including over IPv6-only
• No "Test"/"Beta"/"Debug" strings in name, screenshots, or app copy
• Backend and demo account frozen for the next 7 days

For a deeper, line-by-line pre-flight, see our App Review Playbook — it covers the items above plus metadata edge cases, age-rating gotchas, and what to put in the rejection-response message if you do get hit.

After approval: keep an eye on what users actually say

Once you ship, watching first-week reviews across every country is what tells you whether your launch is going well — Apple's dashboard only shows a few markets at a time. AppStoreReview tracks your app across 175+ countries and alerts you the moment a 1- or 2-star review lands, so launch-week issues never go quiet.

Start monitoring for free →