App Store submission checklist (2026): everything Apple checks before approving your app

To get an app approved on the App Store in 2026, you need a complete App Store Connect record, a stable build with an accurate privacy manifest, a privacy policy URL and a support URL that lead to real pages, clear subscription terms if you sell anything, and screenshots in the required sizes. Most avoidable rejections come back to a handful of guidelines: 2.1 (crashes and incomplete apps), 2.3 (inaccurate metadata), 3.1 (in-app purchase), 4.2 and 4.3 (minimum functionality and spam) and 5.1.1 (data collection). This is the checklist Develak runs before every submission of the more than 30 iPhone, iPad and Mac apps it publishes.

Key takeaways

• Every app needs a privacy policy URL and a support URL with real contact information (guideline 1.5).
• The privacy manifest must declare the required-reason APIs your code and SDKs call, and your App Privacy answers must match reality.
• If users can create an account, they must be able to delete it inside the app (5.1.1(v)).
• Subscriptions need price, period and renewal terms, Terms of Use and privacy links, and a Restore Purchases button.
• iPhone screenshots are required for the 6.9-inch display (or 6.5-inch as a fallback), plus 13-inch iPad screenshots if the app runs on iPad.
• Give App Review working demo access and answer the updated age rating questionnaire (4+, 9+, 13+, 16+, 18+).

The App Store submission process at a glance

Submitting an app is four steps: build and upload with Xcode, let App Store Connect process the build and test it in TestFlight, complete the app record (URLs, privacy answers, screenshots, age rating, review notes), then submit it to App Review. If it is approved, you choose when it goes live; if it is rejected, the message names a guideline, and you fix the metadata or ship a new build. Each section below covers one part of this pipeline.

Before you start: account, agreements and toolchain

• Apple Developer Program membership (US$99 a year). Enroll as an organization to publish under a company name; Apple will ask for a D-U-N-S number.
• Agreements, tax and banking completed in App Store Connect: no price or in-app purchase goes live without an active Paid Apps Agreement.
• EU trader status. Under the Digital Services Act, every developer declares whether they are a trader. Since February 17, 2025, apps without that declaration are removed from the App Store in the EU.
• An app record with a registered bundle ID, a name (30 characters maximum), a primary language and an SKU.
• A current toolchain. Apple raises the minimum SDK every spring: since April 28, 2026, uploads must be built with Xcode 26 and the iOS 26 SDK or later (see Apple’s upcoming requirements). Keeping published apps on a current SDK is part of our app maintenance service.

Required URLs and metadata

App Store Connect asks for three URLs. Two are mandatory, and App Review opens them.

• Privacy policy URL, required for every app, even one that collects nothing (guideline 5.1.1(i) of the App Review Guidelines). The policy must also be reachable inside the app, and it says what you collect, why, who receives it (SDK providers included), how long you keep it and how to request deletion.
• Support URL, required. Guideline 1.5 asks for an easy way to contact you: a working e-mail address or contact form, not a placeholder or a bare homepage.
• Marketing URL, optional. Your product page, if you have one.

Privacy: App Privacy details and the privacy manifest

Many submissions stall here, because three sources must agree: your App Privacy answers, the privacy manifest in the build, and what the code actually does.

App Privacy details (the “nutrition labels”)

Declare every data type the app or its SDKs collect (health, location, identifiers, usage data, diagnostics…), whether it is linked to the user’s identity, and whether it is used for tracking. Tracking across other companies’ apps or websites also requires the App Tracking Transparency prompt (5.1.2). “Data Not Collected” is only valid if it is true for every SDK, analytics and crash reporting included. Guideline 5.1.2(i) now names third-party AI explicitly: if personal data is sent to an outside AI service, you must disclose it and obtain explicit permission first.

The privacy manifest (PrivacyInfo.xcprivacy)

This property list, shipped in the app and in each SDK, declares tracking domains, collected data and the “required reason” APIs the code calls: UserDefaults, file timestamps, system boot time, disk space and active keyboards. Since May 2024, an upload that uses one without an approved reason triggers ITMS-91053: Missing API declaration. The most common entry:

<key>NSPrivacyAccessedAPITypes</key>
<array>
  <dict>
    <key>NSPrivacyAccessedAPIType</key>
    <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
    <key>NSPrivacyAccessedAPITypeReasons</key>
    <array>
      <string>CA92.1</string>
    </array>
  </dict>
</array>

Reason CA92.1 covers data only your app reads and writes. SDKs on Apple’s list of commonly used third-party SDKs must ship their own signed manifest, so update them before you archive. Our iOS privacy manifest guide covers every API category and reason code.

Purpose strings

Each permission prompt needs an Info.plist usage description that says precisely why access is needed (5.1.1). “This app needs your microphone” invites a rejection; “The microphone is used to measure sound levels. Audio is analyzed on your iPhone and never recorded.” does not. Health apps have extra rules (5.1.3): HealthKit data cannot be used for advertising, and apps must not write inaccurate data into Apple Health.

Accounts, demo access and account deletion

• Don’t force sign-up for features that don’t need it (5.1.1(v)). Many of our apps have no account at all: data stays on the device and syncs through the user’s own iCloud.
• Offer in-app account deletion if users can create an account. Deactivation is not enough, and “e-mail us” is only accepted in highly regulated industries. With Sign in with Apple, revoke the user’s tokens on deletion.
• Pair social login with a private option such as Sign in with Apple (guideline 4.8).
• Provide demo access in App Review Information: an account valid for the whole review, with the back end running, or a full demo mode.
• Write review notes. If a feature needs something the reviewer doesn’t have (a race track, a mechanical watch, a Bluetooth sensor), explain how to test it and attach a short screen recording.

Subscriptions and in-app purchases

Digital features must be sold through in-app purchase (3.1.1), and auto-renewable subscriptions have precise disclosure rules (3.1.2). Check that:

• The paywall shows the subscription name, duration, price per period, what is included, and the free-trial terms.
• The paywall links to your Terms of Use (EULA) and privacy policy; in the metadata, the Terms go in the License Agreement field or the description.
• A Restore Purchases button is visible (3.1.1 requires a restore mechanism).
• Each product has a localized name, a description and a review screenshot, and your first in-app purchases are submitted with an app version.

With StoreKit 2 and SwiftUI, most of it is built in:

SubscriptionStoreView(groupID: "YOUR_GROUP_ID") {
    PaywallHeader()
}
.storeButton(.visible, for: .restorePurchases)
.subscriptionStorePolicyDestination(url: termsURL, for: .termsOfService)
.subscriptionStorePolicyDestination(url: privacyURL, for: .privacyPolicy)

We also end every app description with the standard renewal wording (renews automatically unless cancelled at least 24 hours before the end of the period) and the Terms of Use and privacy links. It answers the reviewer’s questions before they are asked. For paywall details, trials and the most common subscription rejections, see our guide to getting subscriptions through App Review.

Screenshots and the product page

• iPhone: 6.9-inch screenshots are required (1320 × 2868, 1290 × 2796 or 1260 × 2736 pixels in portrait). If you don’t provide them, 6.5-inch screenshots (1284 × 2778 or 1242 × 2688 pixels) are accepted instead. Smaller displays use scaled versions.
• iPad: if the app runs on iPad, 13-inch screenshots are required too (2064 × 2752 or 2048 × 2732 pixels).
• Mac: 16:10 screenshots at 1280 × 800, 1440 × 900, 2560 × 1600 or 2880 × 1800 pixels.
• Between 1 and 10 screenshots per size and language (PNG or JPEG, no transparency), plus up to three app previews of 15 to 30 seconds.
• Show the app in use (2.3.3), not a splash or login screen, and never a feature the build lacks.

Apple’s screenshot specifications list every accepted size, and our App Store screenshot sizes guide explains which ones you actually need to upload. Screenshots are also your best conversion tool: our App Store Optimization service covers keyword research, product page copy and localized screenshot sets.

Age rating and export compliance

Age rating. Apple updated its ratings in 2025: the scale is now 4+, 9+, 13+, 16+ and 18+ (replacing 12+ and 17+), and the questionnaire now asks about in-app controls, capabilities such as messaging or user-generated content, medical or wellness topics and violent themes. Existing apps had to answer the new questions by January 31, 2026 to keep submitting updates. Answer precisely: a rating that is too low is a rejection reason.

Export compliance. If your app only uses exempt encryption (HTTPS through URLSession, Apple’s standard cryptography), declare it once in Info.plist and the question disappears from future uploads:

<key>ITSAppUsesNonExemptEncryption</key>
<false/>

TestFlight: test the build Apple will review

• Internal testing: up to 100 members of your team, as soon as the build is processed.
• External testing: up to 10,000 testers by invitation or public link, once the build has passed TestFlight App Review. Builds expire after 90 days.
• Test what reviewers do: fresh install, denied permissions, no network, the demo account, purchase and restore in the sandbox, and the oldest iOS you support (iOS 17 for most of our apps).
• Run an iPhone-only app on an iPad: it can run there in compatibility mode, reviewers may test it, and a crash is still a 2.1 rejection.

Groups, public links, tester feedback and build expiry are covered in our TestFlight guide.

The most common rejection reasons

A word on 4.3, since we publish a large catalogue: a portfolio is not spam when every app solves a different problem. A seizure diary, a dive logbook and a wine cellar manager share an architecture, not a purpose. What triggers 4.3 is one app under several names, or a template reskinned with new colors. Apple clarified both parts of 4.3 with new examples in its June 2026 guideline update; our guide to guideline 4.2 and 4.3 rejections explains how to answer them.

What to do after a rejection

A rejection is a message, not a verdict. Apple says that, on average, 90% of submissions are reviewed in less than 24 hours, so a well-handled rejection usually costs a day or two.

1. Read the message in App Store Connect (the App Review messages, long known as the Resolution Center) and note the guideline number.
2. If the reviewer missed something, reply in the thread with clear steps and a screen recording. Metadata-only issues don’t need a new build.
3. If the issue is real, fix it, increase the build number, upload, and summarize the change in your reply.
4. If you still disagree, appeal to the App Review Board with facts. For a critical fix or a time-sensitive event, request an expedited review.
5. For a bug-fix update, Apple may let you approve the current submission and resolve other issues found during review in the next version, unless they raise legal or safety concerns.

How Develak handles App Store submission

We have published more than 30 apps on the App Store since March 2025, for iPhone, iPad and Mac, in up to 44 languages. Each submission follows this checklist: privacy manifest and App Privacy answers reviewed side by side, purpose strings written for humans, complete paywall terms, review notes with demo access, and screenshots in every required size and language.

For clients, we set up App Store Connect, write the metadata and review notes, prepare localized screenshots, run TestFlight and follow the exchange with App Review until the app is live. Nobody can guarantee approval, since only Apple decides, but this process removes the avoidable rejections. See our iOS app development service and our App Store Optimization service, or tell us about your app.

FAQ