App Store Submission Checklist for 2026

Getting an iOS app approved is rarely about one big problem. Most rejections come from small, avoidable gaps: a demo account that has expired, a privacy answer that does not match what an SDK actually collects, a sign-up flow with no way to delete the account, or screenshots that show features the build does not have.

Since 2010 EmphaSoft has shipped many iOS apps for startups and established companies, and we keep a working checklist that we run before every submission. This is the 2026 version of it. It focuses on the requirements that have stayed stable for years and on the process around them, so it remains useful even as Apple adjusts details.

One honest caveat first: no checklist guarantees approval. App Review is done by people applying the App Store Review Guidelines, and those guidelines change several times a year. Read the current version before each major release, and treat a rejection as feedback rather than a disaster. Most rejections are fixed and resubmitted within days.

1. Product readiness: the build itself

Apple rejects apps that crash, show placeholder content or feel unfinished. Reviewers test on real devices, often on a different device size and OS version than your team uses day to day.

• No crashes or dead ends. Run a full regression pass on the release build, not the debug build. Test fresh installs, upgrades from the previous version, poor network conditions and denied permissions.
• No placeholder content. Lorem ipsum, test products, "coming soon" buttons and empty screens are a common reason for rejection under the completeness rules.
• Reasonable resource use. Excessive battery drain, overheating or heavy background activity can lead to rejection. Profile the app with Instruments before you submit.
• Working links everywhere. Support URL, privacy policy URL, marketing URL and every link inside the app must open and lead to real content.
• Current tooling. Apple periodically raises the minimum Xcode and SDK versions required for uploads. Check the upcoming requirements announced on the Apple Developer site early in your release planning, not on submission day.

2. Enough real functionality

The minimum functionality guideline (4.2) still catches many first submissions. An app that is mostly a wrapped website, a thin catalogue or a single trivial feature is likely to be rejected. Reviewers look for something that uses the platform: native navigation, offline behaviour, notifications, device features or a clearly app-shaped workflow.

If your product is web-first, plan the mobile app as its own experience rather than a container for your site. This is one of the reasons many founders choose a proper native or cross-platform build, such as native iOS development in Swift, instead of a webview shell.

3. Privacy: labels, manifest and permissions

Privacy is where most modern rejections and delays come from, because it involves both your code and every third-party SDK inside it.

App privacy details (privacy nutrition labels)

In App Store Connect you must declare what data your app collects, whether it is linked to the user's identity and whether it is used for tracking. These answers appear on your product page. They must cover data collected by analytics, crash reporting, advertising and payment SDKs, not just your own backend. Audit every SDK before you fill in the form, and update the answers whenever you add or remove one.

Privacy manifest

Apps and many third-party SDKs now include a privacy manifest file (PrivacyInfo.xcprivacy) that describes the data they collect and declares the approved reasons for using certain sensitive APIs, such as some file timestamp and user defaults APIs. Apple maintains a list of commonly used SDKs that must ship with their own manifest and signature. In practice this means:

• Keep SDKs up to date, because older versions may lack a manifest.
• Add your own manifest and declare reasons for any required-reason APIs your code uses.
• Make sure the manifest, the privacy labels and your privacy policy tell the same story.

Permission prompts

Every request for camera, location, contacts, photos, microphone, Bluetooth or similar access needs a clear purpose string that explains why the app needs it. Ask at the moment the feature is used, not all at once on first launch. The app must keep working, in a reduced way if needed, when the user says no.

Tracking

If you track users across apps and websites owned by other companies, for example for ad attribution, you must ask permission through the App Tracking Transparency prompt and respect the answer. Do not gate features behind consent to tracking.

4. Accounts, login and data deletion

• In-app account deletion. If users can create an account in your app, they must be able to start deleting that account from within the app (guideline 5.1.1(v)). Hiding it behind an email to support or a desktop-only page is not enough. Deactivation alone does not count.
• Equivalent login option. If you offer third-party or social login, such as Google or Facebook, the guidelines require you to also offer an equivalent login option with strong privacy protections. Sign in with Apple is the most common way to meet this requirement. Apps that use only their own account system, or that are enterprise and education tools with their own sign-in, are typically exempt.
• Do not force registration without reason. If core features do not depend on an account, let people use them first. Unnecessary sign-up walls are a frequent source of reviewer pushback.
• Demo access for the reviewer. Provide a working demo account in the App Review Information section, with sample data already in it. If login uses one-time codes, hardware or a specific region, explain how the reviewer can get in, or provide a demo mode. An expired or locked demo account is one of the most common avoidable rejections.

5. User-generated content and safety

If users can post content or contact each other, the guidelines expect basic moderation tools:

• A way to filter objectionable material.
• A way to report offensive content, with timely responses.
• A way to block abusive users.
• Published contact information so people can reach you.

Dating, social, marketplace and chat apps should design these flows from the start. Adding them a week before launch usually produces awkward UX and more review questions.

6. Payments and in-app purchases

Digital goods and subscriptions consumed inside the app generally have to use Apple's in-app purchase system. Physical goods and services consumed outside the app, such as deliveries or rides, use regular payment processors. The rules on linking to external purchase options differ by country and storefront and have changed in recent years, so check the current guidelines for each market you launch in.

For subscriptions, the paywall must clearly show the price, billing period and what the user gets, and a restore purchases option must be easy to find. Make sure your subscription products are approved and attached to the build you submit.

7. Product page and metadata

Your product page is both a review artifact and your main conversion tool, so it deserves real attention.

• Name, subtitle and description must describe what the app actually does. Avoid other brands' names, unverifiable claims like "number one" and references to other platforms.
• Screenshots must show the app in use, match the current build and be provided for the device families you support, including iPad if the app runs there. Apple can scale screenshots from the largest required size, but check the current specifications in App Store Connect.
• App previews (short videos) are optional but helpful. They must be captured from the app itself.
• Age rating questionnaire must be answered honestly. Apple has revised the age rating system recently, so review your answers rather than copying last year's.
• Privacy policy URL is required for every app, and the policy must explain what you collect, how you use it and how users can request deletion.
• Rights to content. If the app uses licensed music, video, fonts, images or third-party trademarks, make sure you have the rights and be ready to show documentation.
• Regional and legal details. Answer the export compliance question about encryption, and if you distribute in the European Union, complete your trader status information in App Store Connect.

Good screenshots and copy also drive installs once you are live, so write them for users first and reviewers second. The same text that explains the app clearly to a reviewer is usually the text that converts best.

8. Beta testing with TestFlight

TestFlight is the best rehearsal for App Review. Internal testers on your team can install builds immediately. External testers, such as early customers, require a lighter Beta App Review for the first build of a version, which often surfaces guideline problems before the real submission.

• Distribute the exact release candidate, not a special test build.
• Collect crash reports and screenshot feedback from TestFlight and fix them before submitting.
• Test on the oldest iOS version and smallest screen you support.
• Ask testers to go through onboarding, purchase, permission denial and account deletion flows specifically.

9. Notes for the reviewer

The Notes field in App Review Information is underused. A short, factual note saves days:

• Where the main features are and how to reach them.
• Why the app requests each sensitive permission.
• How hardware-dependent or location-dependent features can be tested.
• Anything that looks unusual but is intentional, such as a feature only available to paying business customers.

If a feature needs a backend that might be unavailable, keep it running and monitored during review. A reviewer hitting a server error will reject the build.

10. Submission and release strategy

• Use manual or phased release. Approval does not have to mean instant launch. Release manually at a time you choose, or use phased release for updates so problems reach fewer users.
• Plan for review time. Most reviews are completed within a day or two, but leave buffer before marketing dates. Expedited review can be requested for critical fixes, but do not rely on it for launches.
• Handle rejections calmly. Reply in App Store Connect, quote the specific guideline, explain or fix, and resubmit. If you believe the decision is wrong, you can appeal to the App Review Board.
• Keep a release log. Record what was rejected and why. Patterns repeat, and the log becomes your team's own checklist.

Quick pre-submission checklist

Conclusion

App Store submission rewards preparation. Teams that design for privacy, account deletion and moderation from the first sprint, test through TestFlight and give reviewers what they need usually pass on the first or second attempt. Teams that treat submission as a final formality tend to lose weeks.

If you are planning a launch, our mobile app development for startups covers the whole path from MVP to App Store release, whether you build natively or with React Native.

If you would like a second pair of eyes on your app before submission, or help fixing a rejection, tell us about your project. We have delivered 400+ projects and are happy to share what we have learned.