Prepare an iPhone, iPad or Apple Watch app for the App Store.

Without an active membership nothing can be uploaded to App Store Connect. Pick the right status: individual or organization. Apps in regulated fields (finance, health, gambling, crypto) must be submitted by the legal entity that provides the service, not by an individual developer (5.1.1(ix)).

Verify: Open developer.apple.com → Account: the membership is active, the renewal date is known and the seller name shown is the right one.

Evidence: Screenshot of the Account page with status and expiry date.

Common failure: A payments app submitted from an individual account is rejected under 5.1.1(ix).

Apple Developer Program — Enrollment ↗ · reviewed 2026-10-23

Selling an app or in-app purchases requires an active Paid Apps agreement in App Store Connect, with tax and banking information. Without it, products cannot be sold.

Verify: App Store Connect → Business: the Paid Apps agreement shows “Active”.

Evidence: Screenshot of the Business section showing the agreement status.

Common failure: In-app purchases cannot be found by the reviewer and the submission is rejected under 2.1.

App Store Connect Help — Sign and update agreements ↗ · reviewed 2026-10-23

Since 17 February 2025, apps without a verified trader status are removed from the App Store in the EU, and the status is required to submit updates for EU storefronts (Digital Services Act).

Verify: App Store Connect → Business → Compliance: trader status is declared and verified.

Evidence: Screenshot of the verified DSA status.

Common failure: The app disappears from EU storefronts until the status is verified.

App Store Connect Help — EU Digital Services Act trader requirements ↗ · reviewed 2026-10-23

The bundle ID is permanent once a build is uploaded. The app name is unique and limited to 30 characters (2.3.7). Several bundle IDs for the same app count as spam (4.3).

Verify: The Xcode project’s bundle ID matches the App Store Connect record exactly.

Evidence: Bundle ID and app name recorded in the project.

App Review Guidelines 2.3 — Accurate Metadata ↗ · reviewed 2026-10-23

App Review must be able to reach you, and both the app and its support URL must offer an easy way to contact you (1.5).

Verify: Open the support URL on a phone: a form or contact address is visible without an account.

Evidence: Support URL and a screenshot of the page.

Common failure: A support URL that leads to an empty page or an unconfigured domain.

App Review Guidelines ↗ · reviewed 2026-10-23

As of 23 October 2026, Apple’s Upcoming Requirements page states that uploads must be built with Xcode 26 or later and a 26 SDK (iOS, iPadOS, tvOS, visionOS, watchOS) since 28 April 2026, and that iOS/iPadOS apps must target iOS 13 or later since 9 September 2026. Apple announces 27 SDKs and an iOS 15 minimum target from April 2027. Check the page before every upload: these values change every year.

Verify: In Xcode → About, note the version; in the target settings, note the SDK and minimum deployment target; compare with the Upcoming Requirements page on the day of upload.

Evidence: Xcode version, SDK and deployment target of the uploaded build.

Common failure: The upload is refused by App Store Connect before review even starts.

Apple — Upcoming Requirements ↗ · reviewed 2026-10-23

The build is signed for App Store distribution (Apple Distribution certificate and matching profile). Every capability used (push notifications, iCloud, Sign in with Apple, App Groups, in-app purchase…) is enabled on the App ID, and no other.

Verify: Product → Archive then Distribute App → App Store Connect completes without signing errors; compare the archive’s entitlements with the App ID capabilities.

Evidence: Build visible in App Store Connect with its number.

Common failure: Push notifications that work in development but not in production because the production entitlement is missing.

Xcode — Distributing your app for beta testing and releases ↗ · reviewed 2026-10-23

The submitted build points to production services, exposes no debug menu or environment switch, and logs no password, token or personal data. Version and build numbers are incremented.

Verify: Install the TestFlight build and check which server it calls (proxy or server logs); look through settings for debug options.

Evidence: Build number and a screenshot of production server logs during the test.

Common failure: The Apple reviewer lands on test data or a staging server that is offline.

Since 1 May 2024, new and updated apps must declare approved reasons for the APIs Apple lists (“required reason APIs”), including those used by third-party SDKs. Many apps use them without knowing (UserDefaults, file timestamps…).

Verify: Open PrivacyInfo.xcprivacy in the project and in each SDK; generate the archive’s privacy report (Organizer → Generate Privacy Report).

Evidence: Privacy report generated from the archive.

Common failure: Upload refused, or an App Store Connect email reporting missing reasons.

Apple — Privacy manifest files ↗ · reviewed 2026-10-23

Each build declares whether the app uses non-exempt encryption. System-provided HTTPS is usually exempt; proprietary encryption may require documentation. Setting ITSAppUsesNonExemptEncryption avoids the question on every build.

Verify: The build does not show “Missing Compliance” in App Store Connect.

Evidence: ITSAppUsesNonExemptEncryption value in Info.plist or the recorded answer.

Apple — Complying with encryption export regulations ↗ · reviewed 2026-10-23

Apple asks for final versions: placeholder text, empty pages, “coming soon” and temporary content must be removed before submission (2.1(a)). Incomplete builds are rejected.

Verify: Walk through every screen of the TestFlight build looking for lorem ipsum, “TODO”, buttons without action and empty screens.

Evidence: List of screens reviewed with the build number.

Common failure: Rejection under 2.1 for a “Coming soon” tab.

App Review Guidelines 2.1 — App Completeness ↗ · reviewed 2026-10-23

Apple rejects builds that crash or show obvious technical problems (2.1). The simulator does not replace a device: memory, network, permissions and performance differ.

Verify: Install the build via TestFlight on at least one device per supported family, on the oldest and the newest supported OS versions.

Evidence: List of devices and OS versions tested (it also goes in the App Review notes).

Common failure: Crash at launch on the reviewer’s device, 2.1 rejection.

App Review Help — Test on compatible devices ↗ · reviewed 2026-10-23

First launch, sign-up or sign-in, the main task, purchase and restore if any, sign-out: each flow works on the submitted build, including with a brand-new account.

Verify: Delete the app, reinstall the TestFlight build and run each flow again with a new account.

Evidence: A short video or a dated list of the flows tested.

Common failure: The demo account works, but signing up a new account fails.

App Review Guidelines 2.1 — App Completeness ↗ · reviewed 2026-10-23

Support, privacy policy, marketing and terms URLs and in-app links: Apple expects fully functional URLs (2.1(a)).

Verify: Open every link from the app and from the App Store Connect record, on a mobile network.

Evidence: List of URLs checked, with the date.

Common failure: Privacy policy returning 404: 5.1.1 rejection.

App Review Guidelines 2.1 — App Completeness ↗ · reviewed 2026-10-23

A known blocking bug is almost always found by the reviewer or the first users. Fix it or remove the affected feature from the build.

Verify: Filter your issue tracker on open critical defects for this version.

Evidence: An empty list, or links to the closed defects with the build that fixed them.

The app must offer features, content and UI that go beyond a repackaged website (4.2) and must not duplicate an existing app or your own apps (4.3).

Verify: List what the app does that your website does not (device features, offline, useful notifications…).

Evidence: That list, repeated in the App Review notes if the app resembles a website.

Common failure: 4.2 rejection for an app that only shows a WebView of the website.

App Review Guidelines 4.2 — Minimum Functionality ↗ · reviewed 2026-10-23

Apps use only public APIs, run on the currently shipping OS (2.5.1) and do not download or execute code that adds or changes features (2.5.2). Background modes are used only for their intended purpose (2.5.4).

Verify: Review the SDKs and declared background modes; look for any remote code loading or runtime module download.

Evidence: List of SDKs and background modes with their justification.

App Review Guidelines 2.5 — Software Requirements ↗ · reviewed 2026-10-23

Apple recommends that iPhone apps run on iPad whenever possible (2.4.1), and reviewers may open them on iPad. A broken layout there is a frequent rejection reason.

Verify: Open the build on an iPad (or the iPad simulator) and repeat the critical flows, in portrait and landscape.

Evidence: iPad screenshots of the main screens.

Common failure: Buttons off screen or the keyboard hiding the form on iPad.

App Review Guidelines ↗ · reviewed 2026-10-23

Standalone behaviour (with or without iPhone), sync, complications and notifications behave differently on a real watch, network and battery included.

Verify: Install via TestFlight on an Apple Watch, with the iPhone away and then nearby.

Evidence: Watch model, watchOS version and flows tested.

App Review Help — Test on compatible devices ↗ · reviewed 2026-10-23

Gaze and gesture interaction, windows and spaces, comfort and legibility: test on Apple Vision Pro when possible, otherwise state the limits of your testing precisely.

Verify: Critical flows on the device or, failing that, in the visionOS simulator with varied window sizes.

Evidence: Test environment and flows covered.

App Review Help — Test on compatible devices ↗ · reviewed 2026-10-23

On Apple TV everything goes through focus and the remote: every actionable element must be reachable, and the Back button must behave as expected.

Verify: Go through the app using only the Siri Remote, no keyboard.

Evidence: Flows tested with the Apple TV model.

App Review Help — Test on compatible devices ↗ · reviewed 2026-10-23

VoiceOver labels on buttons, support for large text sizes and sufficient contrast make the app usable by more people — and avoid unusable screens.

Verify: Turn on VoiceOver and the largest text size, then repeat the main flow.

Evidence: Notes from the VoiceOver and large-text test.

Human Interface Guidelines — Accessibility ↗ · reviewed 2026-10-23

All apps must link to their privacy policy in the metadata and inside the app, easy to reach. It explains what is collected, how it is used, third-party sharing, retention and deletion, and how to withdraw consent (5.1.1(i)).

Verify: Find the link in the app in under three taps; reread the policy against the data actually collected.

Evidence: Policy URL and a screenshot of where it appears in the app.

Common failure: 5.1.1 rejection: policy missing from the app or not covering third-party SDKs.

App Review Guidelines 5.1.1 — Data Collection and Storage ↗ · reviewed 2026-10-23

Privacy details are required to submit new apps and updates. They also cover the practices of integrated third-party SDKs (analytics, ads, crash reporting, payments).

Verify: Compare each declared data type with what the app and its SDKs actually send (SDK inventory, network calls).

Evidence: SDK inventory and a screenshot of the App Privacy section.

Common failure: A label declaring “no data collected” while an analytics SDK is present.

Apple — App privacy details on the App Store ↗ · reviewed 2026-10-23

Purpose strings describe the use of the data clearly and completely. Request only what the core function needs, prefer the system pickers (photos, contacts), and do not lock the app when the person declines (5.1.1(ii)–(iv), 5.1.2).

Verify: Reinstall the app, decline every permission, and check that the app stays usable and explains what is missing.

Evidence: List of NS…UsageDescription keys with their text, and the result of the decline test.

Common failure: A vague string (“We need your location”): 5.1.1 rejection.

Apple — Requesting access to protected resources ↗ · reviewed 2026-10-23

Any recording of user activity (camera, microphone, screen, inputs) requires explicit consent and a clear visual or audible indication while recording (2.5.14).

Verify: Start each recording feature: an indicator is visible for as long as it runs.

Evidence: Screenshot of the indicator while recording.

App Review Guidelines 2.5 — Software Requirements ↗ · reviewed 2026-10-23

Tracking a person’s activity across other companies’ apps and websites requires their explicit permission through App Tracking Transparency (5.1.2(i)). No feature may depend on granting it.

Verify: Decline tracking at first launch and check that no advertising identifier or tracking event is sent (network tool).

Evidence: Screenshot of the ATT prompt and network log after declining.

Apple — App Tracking Transparency ↗ · reviewed 2026-10-23

An app that lets people create an account must let them start its deletion inside the app, with the associated data — deactivation alone is not enough (5.1.1(v)). A direct link to a web page that completes the deletion is accepted. With Sign in with Apple, revoke tokens through the REST API.

Verify: Create a test account, delete it from the app, then check on the server that the account and its data are gone.

Evidence: Path in the app (screenshot) and proof of deletion on the server.

Common failure: Deletion that requires emailing support: 5.1.1(v) rejection.

Apple — Offering account deletion in your app ↗ · reviewed 2026-10-23

If the app has no significant account-based features, it must be usable without logging in (5.1.1(v)).

Verify: List what the account brings; check that the rest is reachable without logging in.

Evidence: That list, summarised in the App Review notes.

App Review Guidelines 5.1.1 — Data Collection and Storage ↗ · reviewed 2026-10-23

An app whose primary login uses a third-party or social service must also offer an equivalent option that limits collection to name and email, lets people keep their email private and does not collect interactions for advertising without consent (4.8).

Verify: On the login screen, the equivalent option is present and works with a new account.

Evidence: Screenshot of the login screen.

Common failure: Google sign-in only: 4.8 rejection.

App Review Guidelines 4.8 — Login Services ↗ · reviewed 2026-10-23

Apps with user-generated content must filter objectionable material, offer a way to report content with timely responses, block abusive users and publish contact information (1.2).

Verify: With two accounts, post content, report it, block the author: each action works and reaches you.

Evidence: Screenshots of the Report and Block actions, and your report-handling procedure.

Common failure: 1.2 rejection for lack of a reporting mechanism.

App Review Guidelines 1.2 — User-Generated Content ↗ · reviewed 2026-10-23

Kids category apps include no third-party analytics or advertising, and outbound links and purchases sit behind a parental gate (1.3, 5.1.4).

Verify: SDK inventory: no third-party analytics or ad SDK; every link and purchase asks for the parental gate.

Evidence: SDK inventory and a screenshot of the parental gate.

App Review Guidelines 1.3 — Kids Category ↗ · reviewed 2026-10-23

Health with medical claims, finance and lending, crypto, gambling: the app is submitted by the entity providing the service, and the authorisations (licence, clearance, partnership) are attached in App Review Information, for each country concerned. Health data follows its own rules (5.1.3).

Verify: List the distribution countries and the document covering each; check that they are attached before submitting.

Evidence: Documents attached in App Review Information.

Common failure: 5.1.1(ix) rejection, or a document request that stalls the review.

App Review Help — Provide information for a complete review ↗ · reviewed 2026-10-23

Unlocking features or content (subscriptions, premium access, full version…) goes through In-App Purchase; licence keys, QR codes and other custom mechanisms are not allowed (3.1.1). Exceptions exist by app type and storefront: check 3.1.1 to 3.1.3 in the current guidelines for your storefronts.

Verify: List each paid item and how it is unlocked; each case outside In-App Purchase cites the exception that allows it.

Evidence: That list with the applicable rule.

Common failure: A “Pay on our website” button not allowed for that storefront: 3.1.1 rejection.

App Review Guidelines 3.1 — Payments ↗ · reviewed 2026-10-23

In-app purchases are complete, up to date, visible and functional for App Review; any that cannot be found in the app are explained in the notes (2.1(b)). New products are submitted together with an app version.

Verify: Buy each product with a sandbox account on the TestFlight build, then check the access granted on the server.

Evidence: List of products with “Ready to Submit” status and the sandbox purchase result.

Common failure: A product in “Missing Metadata”: the reviewer cannot find it, 2.1 rejection.

App Review Help — Configure In-App Purchases for review ↗ · reviewed 2026-10-23

Restorable purchases (non-consumables, subscriptions) must be restorable, for example on a new device (3.1.1).

Verify: Buy in sandbox, delete the app, reinstall, restore: access comes back.

Evidence: Screenshot of the Restore button and the test result.

App Review Guidelines 3.1 — Payments ↗ · reviewed 2026-10-23

Before subscribing, the app clearly describes what the person gets for the price; the period lasts at least seven days and the subscription is available on all their devices (3.1.2). Links to terms and privacy policy are reachable.

Verify: Read the subscription screen as a stranger would: price, period, renewal and content are readable without scrolling.

Evidence: Screenshot of the subscription screen.

Common failure: Price shown only in small print under the button: 3.1.2 rejection.

App Store Connect Help — Offer auto-renewable subscriptions ↗ · reviewed 2026-10-23

For auto-renewable subscriptions, Apple asks for a demo account whose subscription has expired, so the whole purchase flow can be reviewed.

Verify: Sign in with that account on the submitted build: the subscription screen appears.

Evidence: Account entered in App Review Information (without copying it anywhere else).

App Review Help — Provide information for a complete review ↗ · reviewed 2026-10-23

Screenshots show the app in use, not just title art, a login page or a splash screen (2.3.3), and stay suitable for a 4+ rating (2.3.8). They follow App Store Connect size specifications.

Verify: Each screenshot matches a real screen of the submitted build; all sizes App Store Connect asks for are provided.

Evidence: Folder of screenshots per device size.

Common failure: Screenshots of a feature missing from the build: 2.3 rejection.

App Store Connect Help — Screenshot specifications ↗ · reviewed 2026-10-23

Metadata reflects the app’s actual experience (2.3). No third-party trademarks, popular app names, pricing or unrelated terms in the name or keywords (2.3.7). New features are described in the App Review notes (2.3.1).

Verify: Reread the description sentence by sentence: every feature mentioned exists in the submitted build.

Evidence: Product page text reviewed, with the date.

Common failure: A competitor’s name in the keywords: 2.3.7 rejection.

App Review Guidelines 2.3 — Accurate Metadata ↗ · reviewed 2026-10-23

Apple uses a new rating system (4+, 9+, 13+, 16+, 18+); answers to the updated questions were due by 31 January 2026 to avoid blocking updates. Answer honestly, including about user-generated content, messaging and advertising (2.3.6).

Verify: App Store Connect → App Information → Age Rating: every question is answered and matches the app.

Evidence: Screenshot of the completed questionnaire.

App Store Connect Help — Age ratings values and definitions ↗ · reviewed 2026-10-23

“What’s New” and the App Review notes describe what changed and where to find it; generic descriptions are rejected (2.3.1(a)).

Verify: Each listed change points to a specific screen in the build.

Evidence: What’s New text and App Review notes.

App Review Guidelines 2.3 — Accurate Metadata ↗ · reviewed 2026-10-23

TestFlight allows up to 100 internal testers (team members) and up to 10,000 external testers; the first build for external testers goes through review. A build stays testable for 90 days.

Verify: At least one person outside development installs the build and completes the main task without help.

Evidence: TestFlight build number and tester feedback.

Apple — TestFlight ↗ · reviewed 2026-10-23

The Apple reviewer may be on a different network from yours. A first launch with no data, a slow or missing connection and a server error must show an understandable state, not a blank screen or a crash.

Verify: Use Network Link Conditioner or airplane mode during the critical flows.

Evidence: Screenshots of the offline, empty and error states.

App Review Help — Test on compatible devices ↗ · reviewed 2026-10-23

If the app has account-based features, provide an active demo account (or a demo mode approved by Apple). Credentials must work when the review happens; one account per role in the notes; any authentication code provided in advance. Never hand over real customer accounts.

Verify: The day before submitting, sign in with those credentials on the submitted build, from a fresh device.

Evidence: “Sign-in required” checked and the date of the last sign-in test.

Common failure: Password changed or unexpected two-factor prompt: 2.1 rejection.

App Review Help — Provide information for a complete review ↗ · reviewed 2026-10-23

Apple asks that backend services be live and accessible during review, and that the external services the app depends on be listed (authentication, payments, data, AI).

Verify: For the whole review period, uptime monitoring alerts on downtime; no maintenance is scheduled.

Evidence: Uptime history over the review period.

Common failure: Demo server switched off during the review weekend: 2.1 rejection.

App Review Guidelines 2.1 — App Completeness ↗ · reviewed 2026-10-23

Concept and business model (new app) or changes (update), non-obvious features, hard-to-find in-app purchases, devices tested, regional differences, and a video on a physical device when hardware is required.

Verify: Someone who does not know the app can reach every important feature using only these notes.

Evidence: App Review notes text.

App Review Help — Provide information for a complete review ↗ · reviewed 2026-10-23

The build is selected for the version, every required section is complete, and no previous rejection is waiting for a reply or a fix in App Review. A ready submission does not guarantee approval: the decision belongs to Apple.

Verify: App Store Connect shows no missing field when adding the version to the submission; the App Review history holds no open message.

Evidence: Screenshot of the ready submission and of the App Review history.

Common failure: Resubmitting the same build after a rejection without addressing the cited reason.

App Store Connect Help — Submit an app ↗ · reviewed 2026-10-23

A rejection cites a guideline and describes an issue. You can reply to the message, fix and resubmit, or appeal. Decide who reads the message, who fixes and how the fix is verified.

Verify: The responsible person and the target delay are written down in the project.

Evidence: Procedure written in the project.

App Review Help — Rejections ↗ · reviewed 2026-10-23

A manual release lets you check the approved version before it goes out. For an update, a phased release limits exposure if a problem appears.

Verify: The chosen option is written down, with the person who triggers the release.

Evidence: Option selected in App Store Connect.

App Store Connect Help — Release a version update in phases ↗ · reviewed 2026-10-23

A released version cannot be rolled back like a web deployment. Keep server-side settings or feature flags to switch off a failing feature, and know how to request an expedited review for a critical fix.

Verify: Pick a risky feature and check it can be switched off without a new version.

Evidence: List of available switches and the link to request an expedited review.

App Store Connect Help — Request an expedited app review ↗ · reviewed 2026-10-23

Crash reports (Xcode Organizer or a third-party tool), reviews, support messages and App Store Connect metrics are checked daily during the first week.

Verify: A test crash report reaches the chosen tool.

Evidence: Chosen tool and responsible person.