App Store Submission Checklist for iOS Developers in 2026: 15 Configuration Issues That Cause Rejections

1. Bundle identifier mismatch

The bundle identifier in your .xcodeproj must exactly match the App ID registered in App Store Connect and the one embedded in your provisioning profile. A single character difference — a trailing space, a capitalisation inconsistency — produces a binary that Transporter rejects before review even starts.

Check all three locations independently: the PRODUCT_BUNDLE_IDENTIFIER build setting, the App ID in your Apple Developer account, and the provisioning profile's application-identifier entitlement. They must be identical.

2. Version and build number conflicts

CFBundleShortVersionString (the marketing version) must follow semantic versioning — three dot-separated integers. CFBundleVersion (the build number) must be a monotonically increasing integer, higher than any previously uploaded build for that app record.

Uploading a build with the same or lower build number than a prior submission is an automatic Transporter rejection. This is a common failure point when teams reset build numbers after a release.

3. Provisioning profile and certificate alignment

The signing certificate embedded in your archive must match the certificate used to create the provisioning profile. A distribution profile signed with a certificate that has since been revoked or expired will fail notarisation. In Xcode's automatic signing mode, this is usually handled correctly. When manual signing is active — common in CI pipelines — certificate expiry is the most frequent silent failure.

4. Entitlements not matching capabilities

Every capability enabled in your App ID — CloudKit, Push Notifications, Sign In with Apple, HealthKit — must have a corresponding entry in the .entitlements file, and vice versa. An entitlement present in the file but absent from the App ID produces a binary that App Store Connect rejects at processing time, not at review.

This failure is particularly common when capabilities are added mid-development and the App ID in the developer portal is not updated to match. Check both directions: file to portal, and portal to file.

5. Missing or incorrect privacy manifest

As of 2024, Apple requires a PrivacyInfo.xcprivacy file for apps that use certain APIs — including UserDefaults, file timestamp APIs, and several system APIs categorised as "required reason APIs." This requirement extended to all app updates in 2026.

The manifest must declare every required reason API your app calls, using the correct reason codes from Apple's documentation. A missing manifest — or one that omits an API your binary actually calls — triggers a rejection with a specific error code referencing the uncovered API. Static analysis can detect these gaps before submission. See the iOS App Store optimization guide for how privacy compliance affects discoverability.

6. Screenshot dimensions out of spec

App Store Connect requires screenshots for specific device classes. In 2026, required sizes include 6.9-inch display screenshots for iPhone 16 Pro Max, 12.9-inch iPad Pro screenshots if your app supports iPadOS, and App Store previews if you include video. Screenshots that are even one pixel off the required dimensions are rejected at upload.

7. App name and subtitle keyword stuffing

Apple's App Store Review Guidelines prohibit app names and subtitles that consist primarily of keywords. A name like "Budget Tracker — Finance, Money, Expense Manager" will be flagged under Guideline 2.3.7. The subtitle field (30 characters) is the correct place for a short descriptive phrase. The keyword field (100 characters, not visible to users) is where keyword targeting belongs.

8. Missing privacy nutrition labels

The privacy nutrition labels in App Store Connect must accurately reflect every data type your app collects, links to identity, or uses for tracking. Underreporting is a rejection under Guideline 5.1.2. The most common failure: an app that integrates a third-party SDK — analytics, crash reporting, advertising — but does not declare the data that SDK collects. Apple holds the developer responsible for SDK data collection.

9. Age rating misconfiguration

The age rating questionnaire must reflect the actual content and functionality of your app. Apps with user-generated content, web browsing, or unrestricted internet access must declare those capabilities — even if the content itself is benign. An app that allows users to communicate with strangers and is rated 4+ will be rejected.

10. Missing NSUsageDescription keys

Every privacy-sensitive framework your app links against requires a corresponding NSUsageDescription key in Info.plist. This includes NSCameraUsageDescription, NSLocationWhenInUseUsageDescription, NSHealthShareUsageDescription, and others. The key must be present even if the permission request is conditional — if the framework is linked, the key is required. See the HealthKit integration guide for health permission patterns.

11. Calling private or restricted APIs

Apple's automated binary analysis scans for calls to private APIs: methods and symbols not in the public SDK. This includes undocumented methods accessed via string-based selectors, private framework symbols accessed through dlopen, and deprecated APIs removed in the current SDK. The scan is static and symbol-based — it does not require the code path to execute. Audit your third-party dependencies for private API usage before submission.

12. Incomplete Sign In with Apple implementation

If your app offers any third-party or social login option, it must also offer Sign In with Apple as an equally prominent option (Guideline 4.8). The common failure is not a missing button — it is an incorrect implementation. The ASAuthorizationAppleIDProvider flow must handle the credential state check on every app launch, not just at sign-in.

13. In-app purchase architecture violations

Apps that sell digital goods or subscriptions must use StoreKit for those transactions. Directing users to a web checkout for digital content consumed inside the app is a Guideline 3.1.1 violation — regardless of whether the web checkout works correctly. In 2026, this applies to AI features delivered as consumable credits or subscription tiers.

14. Bitcode and architecture flags

Apple deprecated bitcode for iOS apps in Xcode 14 and removed it entirely in subsequent toolchain versions. Projects migrated from older Xcode versions sometimes carry ENABLE_BITCODE = YES in their build settings. The more significant issue is ARCHS: for App Store distribution in 2026, your binary must include arm64 and must not exclude it via an EXCLUDED_ARCHS setting. Verify the Release configuration specifically — Debug and Release build settings often diverge without any obvious signal.

15. Crash on launch in review environment

Apple's review environment is not a standard device. Reviewers use devices without your test accounts pre-configured, without your backend in a known state, and sometimes with network access restricted. Apps that crash on launch are rejected under Guideline 2.1.

The most common causes: a forced unwrap on a network response that returns nil in a restricted environment, a missing demo account for apps that require login, or a Core Data migration that fails when no prior store exists on a clean install. Test on a clean device with no prior app data. Provide demo credentials in the review notes field — every app that requires authentication must include them. See the iOS testing strategies guide for clean-install testing patterns.

What is the most common reason for App Store rejection in 2026?

Privacy-related issues — missing NSUsageDescription keys, incomplete privacy nutrition labels, and missing or incorrect PrivacyInfo.xcprivacy manifests — account for a large share of rejections. These are configuration errors, not code quality issues, and they are detectable before submission.

Does Apple's automated review catch all of these issues before human review?

No. Automated checks catch binary-level issues: private API usage, missing usage description keys, and Transporter validation errors. Metadata issues, age rating misconfigurations, and IAP architecture violations typically reach a human reviewer before being flagged.

How do I test my app in a clean environment before submission?

Use a physical device with the app fully uninstalled. Sign in with a fresh Apple ID that has no prior relationship with your app. Disable any backend feature flags that assume a test environment. This replicates the conditions Apple's reviewers encounter.

What happens if my privacy nutrition labels are inaccurate?

Apple will reject the update under Guideline 5.1.2. If the inaccuracy is discovered after approval — through a user complaint or Apple's own audit — the app can be removed from sale. Accuracy is required at submission and must be maintained as the app's data practices change.

Can a third-party SDK cause my app to be rejected for private API usage?

Yes. Apple's binary scan does not distinguish between your code and your dependencies. If a framework you ship calls a private API, the rejection applies to your app. Audit dependencies before submission — particularly analytics, advertising, and crash reporting SDKs.

What should I include in the App Review Information notes field?

At minimum: demo credentials for any app requiring authentication, an explanation of any non-obvious features (particularly those involving hardware, location, or health data), and a note if the app requires a specific network environment or backend state to function correctly.

Do these requirements apply to TestFlight builds as well?

Partially. TestFlight builds go through automated checks but not full human review. Entitlement mismatches and private API usage will be caught. Metadata issues, age rating, and IAP compliance are not validated for TestFlight — they are only enforced at App Store submission.