How to submit an iOS app to the App Store without rejections.

How App Store review actually works in 2026

When you submit a version in App Store Connect, your build moves into a queue and a human reviewer at Apple runs it on hardware, tests the flows your description advertises, confirms your metadata matches the build, and checks the submission against the App Review Guidelines at developer.apple.com/app-store/review/guidelines/. Apple also runs automated checks for API misuse, private-API calls, and missing entitlements, but the rejection messages you will spend most of your time responding to come from the human reviewer.

Every rejection cites a specific guideline number. The reviewer leaves a short note in Resolution Center explaining what they saw and quoting the guideline. Your job — if the rejection is genuine — is to fix the underlying issue and resubmit. If the rejection is a misunderstanding, your job is to reply factually and ask the reviewer to re-test with the clarification.

Guideline 2.1 — Information Needed (performance and completeness)

Guideline 2.1 is a catch-all that fires when the reviewer cannot complete their evaluation. The top causes:

• Demo credentials don't work. The reviewer can't log in because the username is wrong, the password is wrong, the account requires email verification, or 2FA blocks them.
• Required hardware isn't clear. If your app needs a specific Bluetooth device, NFC tag, or external peripheral, the reviewer needs instructions and, where possible, a video of the feature working.
• The app crashes on launch or during onboarding. The reviewer opens your app and it dies before reaching any feature they can evaluate.
• A feature advertised in the description or screenshots isn't reachable. If your screenshot shows a PDF scanner but the scanner is behind a paywall that the reviewer hasn't paid for, add reviewer notes explaining how to access it, or provide a demo account with the scanner unlocked.

How to pre-empt it: before you tap Submit, fill the App Review Information section in App Store Connect (App Information → App Review Information) with working demo credentials, a contact phone and email, and a Notes field that walks the reviewer through anything non-obvious. If your login uses 2FA, either create a dedicated reviewer account that bypasses 2FA, include a static OTP for a test user, or explain exactly how the reviewer should retrieve the code.

Test the exact build you're submitting on a real iPhone via TestFlight internal testing before submission. If you only test on a simulator, memory and sandbox behavior can differ enough to cause crashes that only show on device — and guideline 2.1 rejection rates are significantly higher for builds the developer never ran on hardware.

Guideline 2.3 — Accurate Metadata

Guideline 2.3 breaks into several sub-rules that all come back to the same principle: your metadata must honestly describe the app that's actually being reviewed.

2.3.3 — Screenshots must show the app in use

Screenshots that are mostly marketing copy with no in-app UI, screenshots showing features that aren't in the current build, screenshots using competitor logos or real user data, and screenshots with staged fake reviews all fail 2.3.3. Captions and framing are fine — Apple explicitly permits them — as long as the underlying UI shown is genuinely from your app.

2.3.7 — Metadata must not be misleading or spammy

The app name cannot include pricing claims ("Free"), ranking claims ("#1 tracker"), category stuffing ("— Notes, Calendar, Reminders, To-do"), competitor names, or promotional language like "best" and "ultimate". The subtitle falls under the same rule. Emoji in the name is a guaranteed 2.3.7 rejection. Keyword stuffing in the description — pasting comma-lists at the bottom — can also trigger it.

2.3.8 — App icon, name, and subtitle must match

The name you display in App Store Connect must match the name bundled in the build (within reason — minor suffix differences are fine). Substantially different names on the Store versus on the home screen fail 2.3.8.

How to pre-empt: before submission, read your current App Store listing in the App Store Preview at apps.apple.com/app/idXXXXXXXXXX as though you'd never seen it. Does every screenshot reflect the current build? Does the description promise things the build delivers? Would a skeptical reviewer think the name or subtitle is a ranking or pricing claim?

Guideline 5.1.1 — Privacy (Data Collection and Storage)

5.1.1 is one of the fastest-growing rejection categories since Apple tightened the privacy framework. It covers three distinct failures:

• Missing or inaccurate App Privacy nutrition label. The questionnaire in App Store Connect (App Privacy section) must accurately reflect every data type your app or its SDKs collect, and for each type: whether it's linked to the user, whether it's used for tracking, and what purpose it serves.
• Privacy policy URL doesn't resolve or doesn't cover what's required. Apple requires a working HTTPS URL to a privacy policy that explains what data is collected, how it's used, how it's shared, and how users can request deletion.
• Collecting data without a clear user benefit or consent surface. If your app asks for Location Always, Contacts, Photos, or Microphone on first launch without a clear in-app benefit, 5.1.1(ii) rejections are common.

How to pre-empt: audit every third-party SDK in your build — Firebase, Sentry, Meta, Google Ads, analytics — and confirm each one's data collection is declared in your App Privacy label. SDK vendors publish privacy manifest files that list the categories they touch; Xcode 15+ warns when a required manifest is missing. Rebuild your privacy label from scratch if you've added or removed any SDK since last submission.

Guideline 4.0 — Design

Guideline 4.0 is broad and subjective. The rejections cluster in four places:

• Minimum functionality (4.2). Repackaged websites, single-purpose apps that duplicate a Safari bookmark, link-only apps, and content aggregators with no native interaction fail 4.2. Adding push notifications or offline storage to a web-wrapper alone isn't enough — the app needs genuine iOS-native features.
• Spam (4.3). Multiple near-identical apps from the same developer ("app farms") get hit with 4.3. If you have a template app and want to ship per-client versions, look at the Enterprise program or custom apps distribution, not the public App Store.
• Extensions and widgets (4.5). If your widget or Home Screen extension doesn't offer meaningful functionality, expect a rejection. Widgets that are only decorative with no real data layer or interaction fail this rule.
• Copycat UI (4.1). Apps that closely mimic another well-known app's visual design or branding get flagged.

Guideline 1.5 — Developer Information

1.5 covers the developer contact information you expose to users. Requirements: a working Support URL that loads a page users can reasonably get help from, an accessible support email or contact form, and — for apps that charge users or collect personal data — accurate business information in App Store Connect. A Support URL that 404s, redirects to an unrelated site, or loads only an empty landing page is a guaranteed 1.5 rejection.

Guideline 4.2 — Minimum Functionality, expanded

4.2 has specific language about apps that "simply package a website" or "are limited in usefulness". A test that works: can a user do something in your app they couldn't do by visiting your website in Safari? Offline mode, Home Screen widgets, background processing, on-device computation, Core ML inference, SharePlay integration — these are all real iOS-native features that satisfy 4.2. A list of blog posts fetched from an RSS feed with no interaction beyond tap-to-read isn't.

Your pre-submission pre-flight checklist

Run this checklist before every submission. Most avoidable rejections come from skipping one of these steps under release-day pressure.

• The exact build you're submitting has been installed and tested on at least one physical iPhone in the last 24 hours.
• All metadata fields (name, subtitle, promotional text, description, keywords, What's New) are filled for every locale you support, and none exceed Apple's character limits.
• Screenshots are uploaded for every required device class and every supported locale; each screenshot shows real in-app UI from the current build.
• App icon is uploaded at 1024×1024 and matches the in-build icon.
• Privacy policy URL resolves on a fresh browser with no cookies.
• Support URL resolves and loads a real support page.
• App Privacy nutrition label reflects every data type the current build (including third-party SDKs) collects.
• App Review Information section is filled: demo username, password, 2FA workaround, any special instructions.
• Age rating questionnaire has been answered with current content in mind.
• Export Compliance question is answered (most apps can select "uses standard HTTPS encryption, exempt").
• Content rights declaration is accurate.
• The app has been tested in the specific locale whose screenshots you uploaded (especially for right-to-left locales and CJK).

AppConsul runs most of these checks automatically when you pull up a version for submission — missing localized metadata, missing screenshots per device class, unresolved privacy or support URLs, and unanswered age-rating questions surface as inline warnings before you tap Submit for Review. The checklist is still worth keeping in Notes or a text file for the steps no tool can verify for you (actually installing on a real device, actually reading your privacy policy).

What to do when you're rejected anyway

Rejections are not disasters. They are a conversation with a reviewer. Here's how to run that conversation:

Step 1: Read the rejection carefully

The reviewer will quote a guideline number and, almost always, include a short note describing what they saw. They may attach screenshots of their session. Read these before doing anything else. Many "mysterious" rejections become obvious once you look at the screenshots and realize the reviewer was on a feature flag you forgot to enable for App Review builds.

Step 2: Decide whether to fix or reply

• If the rejection is correct — fix the issue, upload a new build, and resubmit.
• If the reviewer misunderstood the app or missed a step — reply in Resolution Center with a clarification, screenshots, or a short screen recording.
• If the rejection cites a guideline you believe doesn't apply — reply with a polite reference to the specific rule and why you believe the app is in compliance, and ask the reviewer to reconsider.

Step 3: Write a professional Resolution Center reply

Resolution Center replies should be short, factual, and respectful. A template that works:

Thank you for the review. I'd like to clarify what the app does in the flow you described.
1. When a user taps [button], the app does [exact behavior].
2. The [feature] referenced in the screenshots is available at [exact path], reachable by tapping [button] on the Home tab.
3. I've attached a 30-second screen recording showing the full flow end-to-end.
Could you please re-test using the attached credentials? Demo username: [user], password: [pass]. The 2FA workaround is: [details].
Thank you.

Avoid: apologising excessively, arguing about the guideline itself, invoking past approvals ("this has been approved 12 times before"), or asking for the same reviewer. None of these help. Apple reassigns reviewers based on queue load, not on prior history with your app.

Step 4: Know when to escalate

If a reply in Resolution Center doesn't resolve the issue — especially if you believe the reviewer is misapplying a guideline — you can escalate to the App Review Board via the "Appeal" link at the top of the Resolution Center thread. Appeals go to a senior review team. Only use appeals when you have factual grounds: attach evidence (screen recordings, documentation showing compliance, links to the exact guideline text). Frivolous appeals hurt your standing with the board.

Expedited review for critical bugs

If you've shipped a bug that's actively harming users — a crash loop, a data-loss issue, a security problem — you can request expedited review. The form is at developer.apple.com/contact/app-store/?topic=expedite. Apple grants expedited review selectively and based on severity. Abusing expedited review for routine updates results in future requests being ignored. Describe the user-facing impact clearly (how many users, how they're affected, what the fix does) and keep the request to a paragraph.

Frequently asked questions

What is the most common reason Apple rejects iOS apps?

Guideline 2.1 (Information Needed) is the most frequently cited in public communications. It's a catch-all that fires when the reviewer can't complete their test: demo credentials don't work, a feature is unclear, hardware required isn't available, or the build crashes on launch. Guidelines 4.0 (Design) and 5.1.1 (Privacy) follow close behind.

How long does App Store review take in 2026?

Apple's published median is under 24 hours for most submissions. First-version apps and apps introducing new sign-in, payment, or data-collection surfaces tend to take longer. Expedited review exists for critical bug fixes but is granted selectively.

Can I appeal a rejection?

Yes. Each rejection in Resolution Center has an Appeal option that routes to the App Review Board. Appeal when the reviewer misunderstood your app or misapplied a guideline — not when you simply disagree. Keep it factual and attach evidence.

Does rejection hurt my developer account?

Individual rejections don't. Patterns do: repeatedly submitting the same flagged behavior, fetching remote code that changes app behavior, or misleading metadata can lead to account-level action under guideline 5.6.1.

Should I resubmit or respond in Resolution Center?

Respond first to clarify or ask questions. Resubmit a new build only when fixing the issue requires code changes. Resubmitting the same build without addressing the cited issue almost always fails again.