When your App Store submission gets rejected, the first place to look is the guideline number in the Resolution Center message; based on the current App Review Guidelines text, this guide maps the most common rejection reasons to their guideline numbers and what to check before submitting. Most developers searching "App Store rejection reasons" are actually mixing up similar-sounding guidelines (4.1 with 4.3, 2.3.3 with 2.3.4, 3.1.1 with 3.1.2) rather than facing a single item — this article tells them apart.
💡 Pro Tip: When you get a rejection message, first note the guideline number (e.g. 4.3(b)), then read the full text of that item on the guidelines page — the wording Apple uses there is directly useful when you write your reply.
Table of Contents
- How the review process works
- The most common rejection reasons (by guideline number)
- Metadata and screenshot rejections
- Guideline 4.3: the similarity and spam trap
- Subscription and purchase rejections
- Privacy, permission, and account deletion rejections
- Reading the rejection message correctly and writing a reply
- A 25-item pre-submission checklist
- FAQ
- Why did the App Store reject my app?
- How do you get past a Guideline 4.3 (spam) rejection?
- Why does 2.3.8 also apply to apps with a high age rating?
- Which unlock methods does 3.1.1 prohibit?
- Is a screenshot rejection the same as a preview video rejection?
- What's the difference between a subscription rejection and an IAP rejection?
- How do you appeal a rejection decision?
- Update (September 2026)
- Conclusion
- Sources
How the review process works
Your submitted build enters review through App Store Connect, and the result comes back as a message in the Resolution Center. Every rejection references a specific App Store Review Guidelines item, and that item's number (e.g. 2.3.3, 3.1.2, 4.3(a)) is written explicitly in the message. The sections below explain, one by one, what these numbers mean and which ones get triggered most often.
One thing needs to be clear up front: the Resolution Center message is often short and general, but the guideline item it references is always specific. Developers who reply without grasping the gap between these two layers risk the same rejection again. That's why each section below first explains what the item says, then what mistake it corresponds to in practice.
The most common rejection reasons (by guideline number)
The guidelines split into five main sections: Safety, Performance, Business, Design, and Legal. This guide covers four of the five — Performance (metadata/screenshots), Business (subscriptions/IAP), Design (copying/spam), and Legal (privacy). The table below lists the most frequent items with a brief rationale.
Guideline | Rejection reason | What you should do |
|---|---|---|
4.1 | Copying a popular app with minor changes, appropriating its name/UI | Show your own original value proposition on screen, differentiate the name/icon |
4.1(b) | Submission that impersonates another app or service | Remove brand/icon similarity, document any official partnership claim |
4.3(a) | Using separate Bundle IDs for variations of the same app (by location, sports team, or university) | Submit a single app, offer the variations as in-app purchases |
4.3(b) | A new submission that doesn't offer a unique, high-quality experience in an already saturated category | Highlight the concrete difference in the screenshots and description |
2.3.3 | Screenshots consisting only of the title art / login / splash screen | Show real moments of usage |
2.3.4 | Preview video that isn't an actual screen recording | Use only the app's own screen recording |
2.3.8 | Metadata (icon, screenshots, preview) not suitable for a 4+ age rating | Keep metadata at the 4+ level even for apps with a higher age rating |
3.1.1 | Unlocking a feature with a license key, QR code, or crypto instead of IAP | Move the unlock logic to StoreKit IAP |
3.1.2(a) | Auto-renewable subscription shorter than 7 days or not valid across all devices | Define the duration and device scope correctly in App Store Connect |
3.1.2(a) | Steering users into a subscription with a false pretense or bait-and-switch | Clearly show the price/content promise before purchase |
3.1.2(c) | Failing to clearly explain the price/content details before subscribing | State in advance how many items, how much storage, which access level |
5.1.1(i) | Missing privacy policy link in App Store Connect metadata or inside the app | Make the link easily accessible both in metadata and inside the app |
5.1.1(ii) | Not obtaining user consent for data collection even if anonymous, tying a paid feature to that consent | Show the consent flow before the permission, don't tie a paid feature to consent |
5.1.1(v) | No in-app account deletion option in an app that supports account creation | Add a direct "Delete Account" flow to Settings |
This list doesn't cover every rejection reason, but it gathers the four clusters most often seen in the Resolution Center — copying/spam, metadata, subscriptions, and privacy — into one table. Note that more than one item can trigger in the same submission — a subscription app can get both a 3.1.2(c) and a 5.1.1(ii) rejection at once, since price clarity and data consent are usually problems on the same screen (before purchase). So before fixing one item and resubmitting, checking the other items on that same screen saves time.
Metadata and screenshot rejections
Metadata rejections usually come down to one of three items. 2.3.3 requires screenshots to show actual usage — title art, login, or splash alone isn't enough. 2.3.4 applies the same logic to the preview video: it must consist only of the app's own screen recording, no outside footage or animation. 2.3.8 looks at a different axis: the icon, screenshots, and previews must always suit a 4+ age rating — even if the app itself is rated higher, the metadata can't show violence, sexual content, or otherwise inappropriate material.
In practice, the most common mistake is picking the app's "coolest" screen (usually onboarding or splash) as the screenshot, even though it doesn't reflect real usage. Capturing the actual main screens is the most reliable way to satisfy 2.3.3.
1# Capture screenshots from a real device before uploading to App Store Connect2xcrun simctl io booted screenshot screen-01.pngIf you want to include a screenshot of a page opened via Universal Links or a deep link, you first need to verify that this flow actually works — we covered this topic separately in our deep linking and Universal Links guide.
Guideline 4.3: the similarity and spam trap
4.1 and 4.3 are often confused because both are "copying" themed, but they target different things. 4.1 (Copycats) is about copying another app: appropriating the name/UI of the latest popular app with minor changes. 4.1(b) goes further and treats submissions that impersonate another app or service as a Developer Code of Conduct violation, which can lead to removal from the Apple Developer Program.
4.3, on the other hand, targets a different problem via two sub-items. 4.3(a) counts submitting multiple Bundle IDs for variations of the same app (by location, sports team, or university) as spam — the correct approach is a single app with the variations as in-app purchases. 4.3(b) rejects new submissions that don't offer a unique, high-quality experience in an already saturated category. Clearly stating in the screenshots and description exactly what's concretely different from your competitors is the safest approach.
Guideline | What it targets | Distinguishing question |
|---|---|---|
4.1 | UI/name copying | Does this screen/name come from another app? |
4.1(b) | Brand/service impersonation | Could a user mistake this app for an official service? |
4.3(a) | Multiple Bundle IDs for the same app | Can I consolidate the same function into a single app? |
4.3(b) | Lack of differentiation in a saturated category | Does a concrete difference show in the screenshot? |
Subscription and purchase rejections
Subscription/IAP rejections generally happen at two layers: technical implementation (a non-StoreKit mechanism) and presentation (misrepresenting or omitting price/content).
3.1.1 prohibits the app from using its own mechanism — a license key, QR code, cryptocurrency, or wallet — to unlock a feature or content; IAP through StoreKit must be used instead. 3.1.2(a) sets two conditions: an auto-renewable subscription must last at least 7 days and be valid on all of the user's devices; apps that steer users into a subscription with a false pretense or bait-and-switch are also removed. 3.1.2(c) requires clarity before purchase: explain what the user will get (how many issues/months, how much storage, which access level) before asking them to subscribe.
The purchase screen itself is audited separately too: per the App Store's Subscriptions page, it must show the subscription's name and duration, the full renewal price (localized in the available currencies), and a way for existing subscribers to sign in and restore purchases. The total amount to be billed must also be the most prominent price element — printing "try for free" in large type next to a small-print price violates this rule.
1// The restore flow is the client-side piece of making the subscription accessible on all of the user's devices2func restorePurchases() {3 Task {4 try? await AppStore.sync()5 await updateSubscriptionStatus()6 }7}A reminder on revenue sharing: a developer earns 70% in a subscriber's first year, and 85% after one year — this doesn't directly trigger a rejection, but it's worth factoring into your pricing strategy. To set up a modern IAP flow with StoreKit 2, check our StoreKit 2 guide.
Privacy, permission, and account deletion rejections
The three items in this section complement each other and are usually checked together. 5.1.1(i) requires an easily accessible privacy policy link both in the App Store Connect metadata and inside the app — a link in App Store Connect alone isn't enough, it must also be reachable in-app (usually on the Settings screen). 5.1.1(ii) states that apps collecting user or usage data must obtain consent even if that data is anonymous; critically, a paid feature can't be conditioned on the user granting that access. 5.1.1(v) requires every app supporting account creation to offer in-app account deletion.
The permission request flow itself can also trigger a rejection: showing the system dialog without explaining why you need it leads users to tap "Don't Allow" and later file support requests. To see a permission flow in a different context (health data), check our HealthKit integration guide. To optimize the timing and context of a permission prompt, see our push notification opt-in rate guide.
1<key>NSCameraUsageDescription</key>2<string>Camera access is needed to take a profile photo</string>To keep the account deletion flow accessible from within the app, it's usually enough to place a direct action under Settings > Account:
1{2 "settingsSection": "Account",3 "actions": ["Change Password", "Download My Data", "Delete Account"]4}From an accessibility standpoint, these screens also need to fully work with VoiceOver and Dynamic Type; we covered this topic in detail in our iOS Accessibility guide.
Reading the rejection message correctly and writing a reply
The Resolution Center message always contains a guideline number; the first step is matching it with the full item text on the guidelines page. The second step is writing your reply referencing that item directly — instead of saying "I fixed it," concretely explain which screen, text, or flow you changed and why; this helps the review team verify your change quickly. If the reason feels unclear or like a misunderstanding, Apple offers a way to appeal; the Resolution Center screen inside App Store Connect is the most reliable path to follow it.
A 25-item pre-submission checklist
The list below gathers the practical counterpart of all the guideline items above into one place — an operational, not technical, checklist for the last 15-20 minutes before uploading the build. Each item corresponds directly to at least one guideline number explained above, so if you can't check off an item, you know which section to revisit.
GOLDEN TIP
The most valuable insight in this article
This tip holds the article's most important takeaway.
Easter Egg
You found a hidden gem!
There's a hidden detail in this section. Want to uncover it?
Reader Reward
This section has a condensed checklist you can go through in the last five minutes before submission — the most commonly skipped subset of the 25 items above. Checking these off one by one right before uploading the build largely prevents rejections coming from the four most common clusters (metadata, spam/similarity, subscriptions, privacy).
- Icon and name: Not similar enough to be confused with another app
- Screenshots: Show real moments of usage, not splash/login
- Preview video: Consists of the app's own screen recording
- Metadata age suitability: Icon/visuals/preview at the 4+ level
- Bundle ID strategy: No multiple Bundle IDs for the same function
- Differentiation: If the category is saturated, a concrete difference shows in the screenshots
- IAP mechanism: Unlocking goes through StoreKit, no external license/QR/crypto
- Subscription duration: Auto-renewable is at least 7 days, valid on all devices
- Subscription price clarity: Content/price is clearly explained before purchase
- Purchase screen: Name, duration, full price, and restore option are visible
- Price priority: The amount to be billed is the most prominent element on screen
- Privacy policy link: Present both in App Store Connect and inside the app
- Data collection consent: There's an explicit consent flow before the permission
- Paid feature dependency: A paid feature isn't tied to a data permission
- Account deletion: If account creation exists, in-app deletion exists too
- Permission text: Every Info.plist usage description is explanatory and accurate
- Restore purchases: The button works and has been tested
- Deep link / Universal Link: Opening has been tested on a real device
- Accessibility: VoiceOver and Dynamic Type work in the core flows
- Crash-free build: At least one complete user flow is crash-free on TestFlight
- Demo account: A test account is in the App Review notes for features behind a login
- App Review notes: Special flows (subscription, permission, special hardware) are explained
- Release notes: User-facing, no technical jargon
- Legal text: Terms of use/EULA links are up to date
- Test device variety: A final check has been done on at least one old and one new device
FAQ
Why did the App Store reject my app?
The rejection message comes with a guideline number in the Resolution Center; the most common reasons cluster around metadata/screenshot mismatches (2.3.x), subscription/IAP presentation (3.1.x), and privacy/account deletion gaps (5.1.1.x). The first thing you should do is compare the number in the message with the full item text on the guidelines page.
How do you get past a Guideline 4.3 (spam) rejection?
For 4.3(a) you need to consolidate the same function into a single app (e.g. offering location, sports team, or university variations as in-app purchases instead of separate Bundle IDs); duplicating with separate Bundle IDs isn't accepted. For 4.3(b), you need to clearly show in the screenshots and description exactly what is concretely different from apps that already exist in your category — a generic "better" claim isn't enough, the difference needs to be visible.
Why does 2.3.8 also apply to apps with a high age rating?
2.3.8 requires the icon, screenshots, and previews to always be suitable for a 4+ age rating — this rule applies even if the app itself is rated for a higher age. That means you can't show violence, sexual content, or inappropriate material in the metadata, even if the app's content is listed with a higher age limit on the App Store.
Which unlock methods does 3.1.1 prohibit?
3.1.1 prohibits the app from using its own non-StoreKit mechanisms — a license key, QR code, cryptocurrency, or wallet — to unlock a feature or content. Instead, the unlock logic must be done through IAP via StoreKit.
Is a screenshot rejection the same as a preview video rejection?
No, they're separate items. 2.3.3 requires static screenshots to show real usage; 2.3.4 requires the preview video to consist of the app's own screen recording. Both can be rejected together, but they require different fixes.
What's the difference between a subscription rejection and an IAP rejection?
3.1.1 targets the general IAP unlock mechanism (StoreKit instead of an external license/QR/crypto); 3.1.2 covers subscription-specific rules like the duration, device scope, and pre-purchase clarity of auto-renewable subscriptions specifically. An app can get rejected under both at the same time.
How do you appeal a rejection decision?
If the reason for the rejection is unclear or feels like a misunderstanding, Apple offers developers a way to appeal; you can follow the appeal flow through the Resolution Center screen inside App Store Connect. When writing your appeal, stating concretely which guideline item you disagree with and why, or what change you made, speeds up the review team's process.
Update (September 2026)
This article was written based on the guideline text as of January 15, 2025; a few changes since then may affect rejection reasons:
- June 8, 2026: A wording-clarification-focused revision came to the guidelines — examples were added to items 4.3(a) and 4.3(b), it was clarified that 4.5.3 Live Activities cannot be used for spam/phishing purposes, a new paragraph explaining developer responsibilities was added to 1.2, and the child/minor safety guidance in the introduction section was revised. Source: developer.apple.com/news/?id=a233fmpw
- April 28, 2026: The requirement to build with the iOS 26 SDK took effect; submissions built with an older SDK are now rejected at the App Store Connect upload stage (they never reach App Review). The next threshold was announced as April 2027 for the iOS 27 SDK. Source: developer.apple.com/news/?id=ueeok6yw (iOS 26 threshold) and developer.apple.com/news/?id=k1mtkt1k (iOS 27 threshold)
- October 29, 2025: The scope of independent submissions (IAP promotions, critical bug fixes, Game Center updates) was expanded; the number of Custom Product Pages increased from 35 to 70. These changes aren't a direct rejection reason, but they affect submission strategy. Source: developer.apple.com/news/?id=gf6mgrs6
- April 27, 2026: A 12-month committed monthly subscription model outside the US/Singapore was introduced; apps using this model need to update their 3.1.2 metadata correctly. Source: developer.apple.com/news/?id=agq42lxe
None of these changes invalidate the guideline numbers in the main body dated 2025-01-15, they only expand their scope — when you get a rejection, your first check should still be the number in the Resolution Center.
Conclusion
An App Store rejection generally falls into one of four clusters: metadata/screenshots (2.3.x), similarity/spam (4.1, 4.3), subscription/IAP (3.1.x), and privacy/account deletion (5.1.1.x). Every rejection message comes with a guideline number; matching it to the full text on the guidelines page and replying directly against that item is the most reliable way to prevent a second rejection. To strengthen your subscription flow, see our StoreKit 2 guide; for a permission flow in a different context, our HealthKit integration guide; for accessibility checks, our iOS Accessibility guide; and for deep link testing, our Universal Links guide. Going through this article's 25-item checklist once more before submission helps you catch most rejection clusters early.
Sources
- App Store Review Guidelines — full text of items 4.1, 4.3, 2.3.x, 3.1.x, 5.1.1.x
- App Store Subscriptions — purchase screen requirements and revenue-sharing rates
- Offering Account Deletion in Your App — implementation details of the 5.1.1(v) account deletion requirement
- Apple Developer News — June 2026 guideline and license agreement revision announcement
- Apple Developer News — iOS 26 & iPadOS 26 SDK build requirement (April 28, 2026)
- Apple Developer News — iOS 27 & iPadOS 27 SDK threshold announcement (April 2027)
- Apple Developer News — independent submission scope and Custom Product Pages expansion
- Apple Developer News — 12-month committed monthly subscription model announcement
Tags
iOS Development News
Weekly Swift tips, SwiftUI tricks and iOS best practices. No spam, only valuable content.
We respect your privacy. You can unsubscribe at any time.