Developer Tools

Apple App Store Submission Checklist 2026: 18 Checks Before You Submit

A production App Store submission checklist for iOS teams: binary settings, privacy manifests, metadata, entitlements, HealthKit, Core ML, Foundation Models, and review notes.

By Ehsan Azish · 3NSOFTS·June 2026·10 min read

App Store rejections follow predictable patterns. The same categories appear repeatedly: missing privacy disclosures, broken entitlements, metadata that contradicts the binary, and App Store Connect configuration errors that only surface after upload. None of these are obscure edge cases — they are the standard failure modes for apps submitted without a structured pre-submission review.

This checklist covers 18 checks across six categories. Each check maps to a documented rejection reason or a review guideline Apple enforces in 2026. Work through them in order — earlier checks affect later ones.

Binary and Build Configuration

1. Correct bundle identifier in all targets

The bundle ID in project.pbxproj must match the App ID registered in App Store Connect. Mismatches between the main target, extensions, and watch targets are the most common entitlement failure at upload. Check every target individually — Xcode does not warn when extension bundle IDs are misaligned with their parent.

2. Provisioning profile entitlements match the binary

Every entitlement declared in the .entitlements file must have a corresponding capability enabled in the provisioning profile. aps-environment, com.apple.developer.icloud-container-identifiers, and com.apple.developer.healthkit are the three most frequently mismatched. Archive and run codesign -d --entitlements - YourApp.app to inspect what is actually embedded before upload.

3. Minimum deployment target set correctly

The deployment target in project.pbxproj must be consistent across all targets and must not exceed the minimum OS version required by any linked framework. Core ML models compiled for a specific MLComputeUnits configuration may require iOS 17 or later — verify this against your declared minimum.

4. No private API usage

Static analysis does not catch all private API calls. Run nm -u YourApp.app/YourApp | grep -i private and audit any third-party SDKs for symbols prefixed with _. Apple's automated binary analysis flags these before a human reviewer sees the app.

Privacy and Data Declarations

5. Privacy Nutrition Label complete and accurate

Every data type your app collects, links to user identity, or uses for tracking must be declared in App Store Connect under App Privacy. The declaration must match what the binary actually does. Apple cross-references declared data types against API usage in the binary — CLLocationManager, CNContactStore, and AVCaptureDevice usage without corresponding declarations triggers rejection.

6. NSPrivacyAccessedAPITypes populated in PrivacyInfo.xcprivacy

Apps must include a PrivacyInfo.xcprivacy file declaring reason codes for any use of required reason APIs — a requirement introduced in 2024 that carries into 2026. The five covered API categories are: file timestamp APIs, system boot time APIs, disk space APIs, active keyboard APIs, and user defaults APIs. Missing reason codes produce a rejection citing Guideline 5.1.1.

7. Usage description strings present for every permission

Every NS*UsageDescription key required by the app's permission requests must be present in Info.plist. Absent strings cause an immediate crash on permission request — which App Review catches. Write description strings that state the specific use case. Apple rejects apps with strings like "Required for app functionality."

8. App Tracking Transparency implemented correctly

If the app uses IDFA or any third-party SDK that accesses device identifiers for tracking, ATTrackingManager.requestTrackingAuthorization(completionHandler:) must be called before any tracking occurs. The NSUserTrackingUsageDescription key must be present. Apps that call tracking APIs before authorization — or omit the prompt entirely — fail review under Guideline 5.1.2.

App Store Connect Metadata

9. Screenshots match the current binary

Screenshots must reflect the actual app UI. Placeholder screens, outdated flows, or screenshots showing UI elements that no longer exist in the binary produce rejections under Guideline 2.3.3. For apps with on-device AI features, screenshots showing AI output must be reproducible on-device without a network dependency — Apple tests this.

10. App description does not reference unavailable features

Every feature described in the App Store listing must be present and functional in the submitted binary. References to "coming soon" features, beta functionality, or platform integrations not yet implemented are rejection triggers. The description must reflect the app as it ships.

11. Keywords field does not contain competitor names or irrelevant terms

Apple's metadata guidelines prohibit competitor app names, Apple product names, and category names in the keywords field. Violations produce metadata rejections that delay release without triggering a binary review — which means a separate resubmission cycle.

12. Age rating matches actual content

The age rating questionnaire in App Store Connect must accurately reflect the content in the binary. Apps with user-generated content, web browsing, or AI-generated text that could produce mature output require specific age rating selections. Underreporting content categories is a common rejection reason for AI assistant apps in 2026.

Entitlements and Capabilities

13. iCloud container identifiers configured correctly

Apps using NSPersistentCloudKitContainer or CKContainer must have the correct iCloud container identifier in both the .entitlements file and the App Store Connect capability configuration. Container IDs follow the format iCloud.com.yourcompany.yourapp. A mismatch between the entitlement and the registered container produces a provisioning error at archive time — but only if the profile was generated after the container was registered.

14. Associated Domains entitlement matches server configuration

Apps using Universal Links or Sign in with Apple require the com.apple.developer.associated-domains entitlement and a corresponding apple-app-site-association file served from the domain. Apple's servers fetch the AASA file during review. A 404 response or malformed JSON causes the entitlement to fail silently — the app passes review but Universal Links do not function.

15. HealthKit entitlement declared and usage justified

Apps requesting com.apple.developer.healthkit must provide a clear explanation of HealthKit usage in the App Review notes. Apps that request HealthKit access without demonstrating a primary use case tied to health data are rejected under Guideline 5.1.3. Both NSHealthShareUsageDescription and NSHealthUpdateUsageDescription must be present if the app reads and writes health data.

On-Device AI and Core ML

16. Core ML model files included in the bundle

.mlmodelc compiled model directories must be present in the app bundle at the path referenced in code. Models loaded via MLModel(contentsOf:) with a hardcoded bundle path that does not exist at runtime produce a crash on first inference — which App Review catches during functional testing. Verify the bundle path with Bundle.main.url(forResource:withExtension:) before submission.

17. Apple Intelligence and Foundation Models API usage declared

Apps using FoundationModels framework APIs must handle the case where Apple Intelligence is unavailable — either because the device does not support it or because the user has not enabled it. A missing isAvailable check before calling LanguageModelSession produces a runtime exception that fails review. The app must degrade gracefully. Not crash.

For apps that integrate on-device AI as a primary feature, the AI-native iOS app architecture checklist covers the full set of pre-submission requirements specific to Core ML and Foundation Models integration.

18. No cloud API calls disguised as on-device features

App Review tests AI features in network-restricted conditions. An app that claims on-device AI processing but falls back to a cloud API when the model is absent or slow will fail review under Guideline 2.3.1 (accurate metadata) and potentially 5.1.1 (data collection without disclosure). If the listing claims offline operation, the architecture must function without network access — no exceptions.

Xcode Configuration Diagnostics

Xcode configuration errors account for a disproportionate share of upload failures and post-submission rejections. Entitlement mismatches, incorrect signing identities, and project.pbxproj inconsistencies are detectable before archive — but only with a systematic check.

The Xcode Doctor case study documents a macOS tool that runs 9 specialized configuration checks in under 2 seconds, catching the class of errors that cause build failures and App Store rejections before they reach the upload stage.

For teams preparing a first submission or returning to a codebase after an extended gap, a structured configuration audit is faster than debugging rejection emails after the fact.

Pre-Submission Review Notes

App Review notes are read by a human reviewer before the binary is tested. Use them to explain non-obvious functionality: demo credentials for apps requiring login, instructions for testing on-device AI features, and justification for any entitlement that might appear unnecessary without context.

Notes that address HealthKit usage, background modes, or VoIP entitlements reduce the probability of a guideline-based rejection on first review. The notes field has a 4000-character limit — use it.

Frequently Asked Questions

What is the most common reason for App Store rejection in 2026? Privacy-related rejections lead the category. Missing PrivacyInfo.xcprivacy reason codes, incomplete App Privacy nutrition labels, and NSUserTrackingUsageDescription omissions account for a large share of first-submission failures. All of these are detectable before submission with a static review of Info.plist and App Store Connect configuration.

How long does App Store review take in 2026? Most submissions complete within 24 to 48 hours. Apps with on-device AI features, HealthKit access, or financial functionality take longer — typically 3 to 5 business days. Expedited review is available for critical bug fixes but is not guaranteed.

Can a rejected app be resubmitted immediately? Yes. After addressing the rejection reason, the app can be resubmitted without waiting. Each resubmission restarts the review queue. Submitting without fully resolving the cited issue produces a second rejection for the same reason — which delays release further.

What is PrivacyInfo.xcprivacy and which apps need it? PrivacyInfo.xcprivacy is a structured privacy manifest required for all apps submitted to the App Store. It declares the app's use of required reason APIs — file timestamp, boot time, disk space, active keyboard, and user defaults APIs. Any app using these APIs, directly or through a third-party SDK, must include the manifest with the correct reason codes. Missing entries produce a rejection citing Guideline 5.1.1.

How should on-device AI features be described in App Store metadata? Describe what the feature does for the user, not the underlying technology. If the feature runs entirely on-device, that can be stated — but it must be accurate. Apple tests AI features in network-restricted conditions during review. Claims of on-device processing that require a network call to function produce a metadata accuracy rejection. The on-device AI architecture audit findings for 2026 documents the specific patterns that fail this test.

What happens if screenshots do not match the current binary? App Review rejects the submission under Guideline 2.3.3. The rejection requires updated screenshots and a new submission cycle. Screenshots must reflect the actual app state — including any AI-generated content shown, which must be reproducible on-device without a network connection if the app claims offline AI functionality.

Do App Review notes affect the review outcome? Yes, directly. Reviewers read notes before testing the binary. An unexplained entitlement that would otherwise trigger a guideline question can be pre-empted with a one-sentence justification in the notes. For apps with non-standard functionality — offline AI, HealthKit write access, background location — notes reduce review friction and first-submission rejection rates.

Work With Me

The iOS Architecture Audit reviews data-layer structure, sync strategy, App Store compliance, and on-device AI readiness, then delivers a written recommendations report in 5 business days.