Submitting to the App Store? Clear These Before You Send the Build.

1. Requirements that stop the upload

• Built with Xcode 26 and the iOS 26 SDK (or the current SDK for the platform) — uploads from older toolchains are refused at the door. Modernizing an old project.
• Signing and provisioning — distribution certificate valid, profile includes the right entitlements and bundle ID, no wildcard profile for an app using capabilities. Signing and profile errors.
• Privacy manifest and required-reason APIs for the app and every listed SDK. ITMS-91053 explained.
• Export compliance answered, or ITSAppUsesNonExemptEncryption set in Info.plist, so the build does not sit in “Missing Compliance”.
• Build version and number higher than anything uploaded before; dSYMs included for crash symbolication.
• Agreements — the Paid Applications agreement accepted before any in-app purchase can be reviewed, tax and banking complete.

2. What a reviewer does in the first five minutes

Most Guideline 2.1 rejections happen here, and almost all of them are avoidable.

• Sign-in. Provide a working demo account in App Review Information, including a code path for OTP/2FA that does not depend on the reviewer's phone. Test it on a device that has never run the app.
• Every gated feature reachable. If a region, subscription, hardware or invitation gates something, say so in the review notes and give the reviewer a way through.
• No placeholders. Lorem ipsum, “coming soon” screens, dead buttons and staging URLs are completeness failures.
• It must not crash. Run the exact archive you are submitting on a clean device with a fresh install, offline and on a slow network.
• Backends must be up for the whole review, including any staging service the build points at.

Details: Guideline 2.1 — app completeness.

3. Privacy declarations that must match the build

• App privacy details (“nutrition labels”) match what the app and its SDKs actually collect and link to the user.
• Purpose strings for every permission explain the real, user-visible reason — not “needed for app to work”.
• App Tracking Transparency prompt implemented if anything tracks across apps or sites, with the declaration to match.
• Account deletion in-app for any app that lets users create an account (Guideline 5.1.1(v)).
• Privacy policy URL reachable, app-specific, and consistent with the labels.
• Sign in with Apple offered where a third-party social login is the only other option, unless an exception applies.

Details: privacy rejections (Guideline 5.1).

4. Purchases, if the app has them

• Every in-app purchase has complete metadata, a review screenshot and review notes, and shows Ready to Submit — products in Prepare for Submission are not part of the review.
• The first submission of a purchase goes with an app version; the reviewer must be able to reach the paywall and complete a sandbox purchase.
• Digital content uses In-App Purchase; physical goods and services do not. Subscriptions show price, period and terms before purchase, and a restore path exists.
• If products do not appear at all in TestFlight or sandbox, fix that before submitting: in-app purchases not showing.

Rule-level detail: Guideline 3.1 payments.

5. Metadata and product page

• Screenshots show the real app on the right devices; no device frames with marketing copy that misrepresents the UI.
• Name, subtitle, keywords and description describe the current build; no competitor names, no pricing claims in metadata, no “beta”.
• Age rating answered honestly, including the updated questions Apple introduced for 2026 submissions.
• Support URL and marketing URL resolve and are about this app.
• Review notes explain anything unusual: hardware, regional gating, physical products, regulated features.

Details: metadata rejections (Guideline 2.3).

6. Is there enough app?

Guideline 4.2 rejections hit thin apps hardest: a website in a WebView, a template rebuilt for a new client, a single-feature utility with no native value. If the app is a wrapper or a template variant, decide before submitting what makes this one genuinely useful — see minimum functionality and spam / similar apps.

7. After you press submit

• Watch the status: Waiting for Review, In Review, Pending Developer Release each mean something specific, and a reviewer question pauses everything until you answer.
• Keep the build available in TestFlight so you can reproduce whatever the reviewer reports.
• If a genuinely critical fix is queued, an expedited review request exists — for critical bugs and events only.
• If it is rejected, read the guideline number before reacting: App Store rejection help.

Shipping to both stores? The Google Play blockers are different: Google Play submission checklist.