DOMAIN:IOS_DEVELOPMENT:APP_STORE_REVIEW

OWNER: martijn
ALSO_USED_BY: valentin, julian (compliance review)
UPDATED: 2026-03-24
SOURCE: Apple App Store Review Guidelines (2025-2026 edition), App Review Board decisions

---

REVIEW:TOP_REJECTION_REASONS

NOTE: these are the most frequent rejection reasons based on Apple's published data and developer reports
NOTE: guideline numbers reference Apple's App Store Review Guidelines

1. Bugs and Crashes (Guideline 2.1)

STANDARD: §2.1 — App Completeness
CHECK: app must be final, complete, and fully functional at review time
CHECK: no placeholder content, broken links, or unfinished features
CHECK: test on ACTUAL devices, not just Simulator
CHECK: test on oldest supported iOS version
CHECK: all URLs in app must be live and accessible
CHECK: all in-app purchases must be functional during review

IF: feature requires account/login
THEN: provide demo credentials in App Review notes
IF: feature requires hardware (Bluetooth, location)
THEN: explain in review notes + provide video demo

2. Guideline 2.3 — Accurate Metadata

STANDARD: §2.3 — Accurate Metadata
CHECK: app name must reflect functionality — no misleading names
CHECK: screenshots must show actual app (no mockups, no marketing overlays that obscure functionality)
CHECK: description must accurately describe features
CHECK: category must match primary functionality
CHECK: keywords must not include competitor names, misleading terms, or irrelevant content
CHECK: no pricing information in screenshots or name (use subtitle)
CHECK: age rating must accurately reflect content

ANTI_PATTERN: using screenshots from a different device size (scaling up iPhone to iPad)
FIX: provide device-specific screenshots for each required size

3. Guideline 4.0 — Design

STANDARD: §4.0 — Design
CHECK: app must provide sufficient value — no thin/trivial apps
CHECK: no web-view-only apps that replicate a website
CHECK: must use native controls where appropriate
CHECK: no misleading UI elements (fake system dialogs, fake notifications)
CHECK: alert/notification style must not mimic iOS system UI

4. Guideline 5.1.1 — Data Collection and Storage

STANDARD: §5.1.1 — Data Collection and Storage
CHECK: privacy policy URL required (displayed in App Store Connect + within app)
CHECK: apps collecting user data MUST explain what data and why
CHECK: data collection must be proportional to app's functionality
CHECK: sensitive data (health, financial, biometric) needs additional justification
CHECK: no accessing contacts, photos, camera, microphone without clear purpose

5. Guideline 3.1.1 — In-App Purchase

STANDARD: §3.1.1 — In-App Purchase
SEE: section REVIEW:IN_APP_PURCHASE below for full detail

---

REVIEW:PRIVACY_REQUIREMENTS

App Tracking Transparency (ATT)

STANDARD: §5.1.2(i) — Permission, Apple ATT Framework documentation
RULE: IF app tracks users across other companies' apps/websites THEN MUST use ATT framework
RULE: ATT prompt must appear BEFORE any tracking occurs
RULE: IF user denies THEN app must not track AND must still function fully

CHECK: does app use IDFA (Advertising Identifier)?
CHECK: does app share device-level identifiers with third parties?
CHECK: does any SDK in the app perform cross-app tracking?
IF: any answer is YES
THEN: implement ATT prompt using ATTrackingManager.requestTrackingAuthorization()

ANTI_PATTERN: pre-prompting (showing custom dialog before ATT system dialog)
FIX: Apple specifically prohibits "pre-ATT prompts" that incentivize allowing tracking (§3.2.2(vi))

Privacy Nutrition Labels

STANDARD: App Store Connect — App Privacy
RULE: ALL apps must declare data collection practices in App Store Connect
RULE: labels must cover ALL data collected by app code AND third-party SDKs
RULE: update labels whenever data practices change

CATEGORIES:
- Contact Info (name, email, phone, address)
- Health & Fitness
- Financial Info
- Location (precise/coarse)
- Sensitive Info
- Contacts
- User Content (photos, videos, audio, gameplay, customer support)
- Browsing History
- Search History
- Identifiers (user ID, device ID)
- Purchases
- Usage Data (product interaction, advertising data)
- Diagnostics (crash data, performance data)

FOR_EACH data type, declare:
- Linked to identity? (associated with user account/identity)
- Used for tracking? (cross-company tracking)
- Purpose: analytics, app functionality, product personalization, third-party advertising

ANTI_PATTERN: declaring "no data collected" when using analytics SDKs
FIX: Firebase Analytics, Crashlytics, Mixpanel etc. ALL collect data. Declare honestly.

Privacy Manifests (Required since 2024)

STANDARD: Apple — Describing use of required reason APIs
RULE: apps AND included SDKs must include PrivacyInfo.xcprivacy manifest
RULE: manifests must declare usage of "required reason APIs":
- File timestamp APIs (NSFileCreationDate, NSFileModificationDate)
- System boot time APIs (systemUptime, mach_absolute_time)
- Disk space APIs (volumeAvailableCapacityKey)
- User defaults APIs (UserDefaults) — IF accessed cross-app
- Active keyboard APIs

TOOL: Xcode → Privacy Report (Product → Generate Privacy Report)
CHECK: run privacy report before EVERY submission
CHECK: all third-party SDKs must include their own privacy manifests
CHECK: IF SDK lacks manifest THEN contact SDK vendor or replace SDK

RULE: third-party SDK signatures required since April 2024
RULE: SDKs listed on Apple's "commonly used third-party SDKs" list MUST use XCFramework with signature

---

REVIEW:IN_APP_PURCHASE

STANDARD: §3.1.1 — In-App Purchase

When Apple IAP is MANDATORY

RULE: digital content consumed within the app → MUST use Apple IAP
RULE: subscriptions for digital services/content → MUST use Apple IAP
RULE: in-app currency, virtual goods, loot boxes → MUST use Apple IAP
RULE: unlocking features/functionality → MUST use Apple IAP
RULE: SaaS accessed primarily through the app → MUST use Apple IAP

When External Payment is ALLOWED

RULE: physical goods/services (e.g., e-commerce, ride-sharing, food delivery) → external OK
RULE: person-to-person services (tutoring, consulting) → external OK
RULE: "reader" apps (content purchased elsewhere, consumed in app) → external OK (Netflix, Kindle, Spotify)
RULE: enterprise services sold to businesses (not individuals) → external OK
RULE: cross-platform SaaS where app is secondary → GRAY AREA, contact Apple
RULE: free apps with no paid features → no IAP needed

EU DMA Changes (2024+)

RULE: in EU, apps can now link to external payment methods (StoreKit External Purchase Link Entitlement)
RULE: Apple still charges commission on external EU transactions (reduced rate)
RULE: requires entitlement + compliance with Apple's linking requirements

Commission Rates

Category	Standard Rate	Small Business Rate
App Store purchases	30%	15% (if <$1M revenue previous year)
Auto-renewable subscriptions (year 1)	30%	15%
Auto-renewable subscriptions (year 2+)	15%	15%
EU external purchases (2024+)	~17%	~10% (approximate)

IF: GE client app is SaaS for SME businesses
THEN: evaluate whether primary use is via app (IAP mandatory) or web+app (may qualify for reader/enterprise exception)
ESCALATE_TO: human for commercial decision on IAP vs external payment strategy

ANTI_PATTERN: hiding subscription terms in settings or small print
FIX: §3.1.2 — subscription terms must be clearly visible before purchase

---

REVIEW:SIGN_IN_REQUIREMENTS

STANDARD: §4.8 — Sign in with Apple

RULE: IF app offers third-party sign-in (Google, Facebook, etc.) THEN MUST also offer Sign in with Apple
RULE: Sign in with Apple must be a PROMINENTLY displayed option (not hidden)
RULE: Sign in with Apple button must follow Apple's design guidelines (ASAuthorizationAppleIDButton)

CHECK: does app require account creation?
IF: account required AND third-party login offered
THEN: MUST add Sign in with Apple
IF: account required AND only email/password registration
THEN: Sign in with Apple NOT required (but recommended)
IF: app works without account (guest mode)
THEN: Sign in with Apple only required if third-party login also offered

RULE: apps for children (Kids category) have additional restrictions — parental consent, no third-party logins
RULE: educational institution apps using managed Apple IDs are exempt

ANTI_PATTERN: requiring login for features that don't need it
FIX: §5.1.1(v) — apps should work without login where possible. Don't gate basic functionality.

---

REVIEW:CONTENT_RESTRICTIONS

STANDARD: §1.1 — Objectionable Content, §1.2 — User Generated Content

User Generated Content (UGC)

IF: app includes UGC (comments, posts, photos, profiles)
THEN: MUST implement ALL of:
- Content filtering/moderation mechanism
- Reporting/flagging mechanism
- Blocking mechanism
- Contact information for concerns

RULE: "we moderate manually" is not sufficient — need proactive filtering
RULE: AI/ML moderation is acceptable but must have human fallback

Age Rating

CHECK: set age rating accurately via questionnaire in App Store Connect
CHECK: if app accesses web content, rate conservatively (web browsing = 17+)
CHECK: alcohol/tobacco references affect age rating
CHECK: medical/health info may require 12+ or 17+

---

REVIEW:MINIMUM_FUNCTIONALITY

STANDARD: §4.2 — Minimum Functionality

CHECK: app must provide lasting utility — not just a wrapper around a website
CHECK: app must do more than display information (that's a web page, not an app)
CHECK: no apps that are marketing materials or brochures
CHECK: simple web view wrapping a responsive website = rejection

IF: app is a companion to a web service
THEN: must provide native functionality beyond the website (offline access, push notifications, widgets, shortcuts, etc.)

ANTI_PATTERN: wrapping a web app in WKWebView and calling it a native app
FIX: must have meaningful native components. At minimum: native navigation, native notifications, offline support.

ANTI_PATTERN: submitting a near-empty app with "content coming soon"
FIX: app must be fully functional at review time — no placeholder content

---

REVIEW:SUBMISSION_CHECKLIST

PRE-SUBMISSION:
□ App tested on real devices (not just Simulator)
□ Tested on oldest supported iOS version
□ All URLs live and accessible
□ Demo account credentials prepared (if login required)
□ Privacy policy URL live and accessible
□ Privacy nutrition labels completed in App Store Connect
□ PrivacyInfo.xcprivacy manifest included
□ All third-party SDKs have privacy manifests
□ Age rating questionnaire completed accurately
□ Screenshots for all required device sizes
□ App description accurate and complete
□ Keywords relevant (no competitor names)
□ In-App Purchases configured and testable
□ Sign in with Apple implemented (if third-party login exists)
□ Export compliance answered
□ Build number incremented
□ No placeholder/test content
□ No private API usage
□ No hardcoded test URLs or API keys
□ Content moderation in place (if UGC)
□ Crash-free rate > 99% (check Xcode Organizer)

REVIEW NOTES (fill in for reviewer):
□ Demo credentials: username / password
□ Hardware-dependent features explained
□ Non-obvious features walkthrough
□ Subscription pricing justification (if applicable)
□ Geographic restrictions explained (if applicable)

---

REVIEW:REJECTION_HANDLING

IF: app rejected
THEN:
1. Read rejection message in App Store Connect → Resolution Center
2. Identify specific guideline number(s) cited
3. Fix the issue(s) — do not try to argue without fixing
4. IF rejection is ambiguous THEN reply in Resolution Center asking for clarification
5. IF you disagree THEN can appeal to App Review Board (but fix the issue first)
6. Resubmit — rejected builds go to front of review queue (usually faster)

RULE: NEVER ignore a rejection — it does not go away
RULE: do not submit identical build hoping for different reviewer — Apple flags this
RULE: polite, factual communication in Resolution Center — argumentative tone causes delays

ESCALATE_TO: human if same rejection happens 3 times — may need Apple Developer Relations call