App Store Submission Checklist for 2026

Most App Store rejections come from small gaps that were easy to avoid: a demo account that 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 of features the build does not have. A single big problem is rare.

Mefasoft has shipped many iOS apps for startups and established companies since 2019, and we run the same working checklist before every submission. This is the 2026 version. It sticks to requirements that have stayed stable for years and to the process around them, so it should stay useful while Apple adjusts the details.

No checklist guarantees approval. App Review is done by people applying the App Store Review Guidelines, and Apple changes those guidelines several times a year. Read the current version before each major release. If you get rejected, read the reason as feedback: 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, and often on a device size and OS version your team does not use day to day.

• Run a full regression pass on the release build (the debug build does not count) and look for crashes and dead ends. Cover fresh installs, upgrades from the previous version, poor network conditions and denied permissions.
• Remove placeholder content. Lorem ipsum, test products, "coming soon" buttons and empty screens are a common reason for rejection under the completeness rules.
• Keep resource use reasonable. Heavy battery drain, overheating or a lot of background activity can get the app rejected, so profile it with Instruments before you submit.
• Check every link. The support URL, privacy policy URL, marketing URL and all links inside the app must open and lead to real content.
• Stay on current tooling. Apple periodically raises the minimum Xcode and SDK versions required for uploads. Look up the upcoming requirements on the Apple Developer site early in release planning, well before submission day.

2. Enough real functionality

The minimum functionality guideline (4.2) still catches many first submissions. A wrapped website, a thin catalogue or an app with one trivial feature is likely to be rejected. Reviewers want to see the app use the platform: native navigation, offline behaviour, notifications, device features or a workflow that clearly belongs in an app.

If your product is web-first, design the mobile app as its own experience instead of a container for the site. That is one reason many founders pay for a proper native or cross-platform build, such as native iOS development in Swift, over a webview shell.

3. Privacy: labels, manifest and permissions

Most modern rejections and delays come from privacy, because it involves your own code and every third-party SDK inside it.

App privacy details (privacy nutrition labels)

In App Store Connect you 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 have to include data collected by analytics, crash reporting, advertising and payment SDKs as well as 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). It 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 keeps a list of commonly used SDKs that must ship with their own manifest and signature. In practice:

• 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.
• Check that the manifest, the privacy labels and your privacy policy say the same thing.

Permission prompts

Each request for camera, location, contacts, photos, microphone, Bluetooth or similar access needs a purpose string that says why the app needs it. Ask when the user reaches the feature instead of firing every prompt on first launch. If the user says no, the app must keep working, with reduced features if necessary.

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. Features cannot depend on the user agreeing to tracking.

4. Accounts, login and data deletion

• If users can create an account in your app, they must be able to start deleting it from inside the app (guideline 5.1.1(v)). An email to support or a desktop-only page is not enough, and deactivation alone does not count.
• If you offer third-party or social login, such as Google or Facebook, the guidelines also require an equivalent login option with strong privacy protections. Most teams meet this with Sign in with Apple. Apps that use only their own account system, and enterprise or education tools with their own sign-in, are typically exempt.
• Do not force registration without a reason. If core features work without an account, let people use them first. Reviewers often push back on unnecessary sign-up walls.
• Give the reviewer demo access: 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. When they get added a week before launch, the UX is usually awkward and the review raises more questions.

6. Payments and in-app purchases

Digital goods and subscriptions consumed inside the app generally have to go through 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.

A subscription paywall must show the price, the billing period and what the user gets, and the 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

The product page is reviewed like the rest of the app, and it is also where most of your conversions happen.

• The name, subtitle and description must describe what the app actually does. Leave out 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 cover 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 and help. They have to be captured from the app itself.
• Answer the age rating questionnaire honestly. Apple revised the age rating system recently, so go through the answers again instead of copying last year's.
• Every app needs a privacy policy URL. The policy has to explain what you collect, how you use it and how users can request deletion.
• If the app uses licensed music, video, fonts, images or third-party trademarks, make sure you have the rights and can show documentation.
• Answer the export compliance question about encryption. If you distribute in the European Union, complete your trader status information in App Store Connect.

Screenshots and copy keep driving installs after launch, so write them for users first and reviewers second. Text that explains the app clearly to a reviewer usually converts best with users too.

8. Beta testing with TestFlight

TestFlight is the closest rehearsal for App Review you can get. Internal testers on your team can install builds immediately. External testers, such as early customers, need a lighter Beta App Review for the first build of a version, and that review often catches guideline problems before the real submission.

• Distribute the exact release candidate instead of 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

Few teams make good use of the Notes field in App Review Information. A short, factual note can save days. Include:

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

If a feature depends on a backend, keep it running and monitored during review. A reviewer who hits a server error will reject the build.

10. Submission and release strategy

• Use manual or phased release. Approval does not have to mean an instant launch: you can release manually at a time you choose, or use phased release for updates so problems reach fewer users.
• Plan for review time. Most reviews finish within a day or two, but leave a buffer before marketing dates. You can request expedited review for critical fixes, though you should not count on it for a launch.
• When you are rejected, reply in App Store Connect, quote the specific guideline, explain or fix, and resubmit. If you think the decision is wrong, you can appeal to the App Review Board.
• Keep a release log of what was rejected and why. The same issues come back, and over time the log turns into your team's own checklist.

Quick pre-submission checklist

Conclusion

Teams that build privacy, account deletion and moderation in from the first sprint, test through TestFlight and give reviewers what they need usually pass on the first or second attempt. Teams that leave submission as a formality for the last day tend to lose weeks.

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

If you want someone to look over your app before submission, or need help with a rejection, tell us about your project. We have delivered 400+ projects and are glad to share what we learned along the way.