App Store Requirements: What to Verify Before You Submit

Your launch date is in the hands of a reviewer who has never seen your product. They can send the entire build back over an expired demo password or an unanswered age rating form. App Store requirements are mostly administrative, and that work is the first thing to slip when a release gets tight. Easy problems are the ones nobody checks. Catching them before you submit is what App Store compliance testing is for.

Apple’s own App Review page says over 40% of unresolved issues trace back to guideline 2.1, App Completeness. The category covers crashes, placeholder content, and anything left blank. So your app can work perfectly and still fail review. Approval starts with a short list that has nothing to do with how good your app is.

You need an active Apple Developer Program membership and a complete App Store Connect record. The build itself has to be compiled with Xcode 26 and the iOS 26 SDK. Apple also asks for a working demo account, current age rating answers, and a privacy policy that matches what your app collects.

Every item on that list is easy to confirm, but any one of them can stop a release. This article covers what to check before you submit, what a rejection costs in calendar time, and who should own each decision.

App Store Requirements You Must Clear Before Submitting

Two Apple App Store submission requirements changed in 2026, and neither has anything to do with testing. However, they still catch teams shipping their first update of the year. One made answers to Apple’s revised age rating questions mandatory on January 31. The other requires you to build every binary with Xcode 26 and the iOS 26 SDK. It became active on April 28 and now applies to all apps.

Both deadlines sit on the upcoming requirements page, and missing either one stops you at the upload stage, before review begins. Confirming each takes minutes, but nobody schedules time for something that isn’t a feature.

The third item is export compliance, and it has nothing to do with testing either. American trade law covers software that uses encryption, so Apple has to ask whether yours does. The truth of the matter is that almost every app does, because any connection over HTTPS counts. You can answer that question by hand on each submission. The alternative is to settle it once inside the app’s Info.plist configuration file, after which Apple stops asking.

Those three are part of a longer list. The table below shows the App Store requirements that gate the upload, along with who in your company actually owns each one.

That last row is a hard stop if you sell in the European Union. The Digital Services Act makes Apple publish a verified trading name and address for every developer who lists an app there. Therefore, until you supply yours and Apple verifies it, your app comes off the EU App Store entirely. Legal and finance own this one, not engineering, so start it early. A gap like this belongs with software compliance testing rather than the mobile QA cycle.

Apple App Store requirements run deeper than this table, though only the rows above actually block the upload. If you’re shipping the Android build in the same window, our guide to getting through Google Play review covers the equivalent ground.

The Six Questions to Answer Before You Submit

Clearing those requirements only gets you into the queue. Then everything depends on what a reviewer can actually do with your build. Search for an App Store submission checklist and you’ll find one written for engineers. It lists everything a developer clicks and tells a business owner nothing about whether the launch is safe. Instead, the version below is organized around what you should be able to confirm, out loud, in a release meeting.

Can a Stranger Get Into Your App Without Your Help?

A reviewer has to reach every feature you’re shipping, and they start with nothing but your build. That’s why Apple’s guideline 2.1 asks for demo account details and a live back end whenever your app includes a login. Most teams supply both, yet fewer confirm that the credentials still work on the morning a reviewer opens them.

Verify three things:

• The demo account doesn’t expire or lock after failed attempts.
• The back end it points at is running, not merely deployed.
• Notes for Review describes each new feature specifically, since Apple rejects generic wording.

If legal or security rules stop you from handing over a live account, Apple accepts a built-in demo mode instead, with prior approval. Getting that sign-off takes time you have to budget for.

Is the Build You're Submitting the Build You Tested?

In many cases, release builds diverge from what you tested in small, expensive ways:

• A feature flag left switched on
• A staging endpoint hard-coded in a config file
• An in-app purchase still pointing at the sandbox

None of those show up in daily use, because your team is running a different build. The confirmation is one sentence: someone installed the exact binary on a clean device and walked the main path end to end. Getting that is why mobile application testing should run against the release candidate rather than an earlier branch. That is also the cheapest place to catch stability issues.

Does Your Listing Promise Anything the Build Doesn't Do?

Marketing writes the store listing weeks before engineering finishes the build, pulling screenshots from designs and descriptions from the roadmap. Then a feature slips, and nobody updates the copy.

Apple’s guideline 2.3 treats that mismatch as inaccurate metadata, so read your own listing against the build you’re about to send. Every claim needs a matching feature a reviewer can reach without instructions.

Have You Answered Every Question Apple Now Asks?

The forms in App Store Connect aren’t a formality, and they change more often than teams expect. Privacy declarations in particular have to match what your app actually collects, including data pulled in by third-party SDKs you didn’t write. Nobody on your team may know what those libraries transmit, which is why this one needs checking rather than remembering.

Artificial intelligence (AI) is the newest area Apple has tightened. Guideline 5.1.2(i) requires you to disclose any personal data you send to a third-party AI. You also need explicit permission before it moves, which we covered in Apple’s AI data sharing guidelines.

Can Users Delete, Restore, and Report Inside Your App?

Some requirements are about what your app does, not what you say about it. Any product that supports sign-up must also offer in-app account deletion. Purchases have to be restorable, and every one of them must be visible to the reviewer. Apps that let users publish content must give everyone the option to report a post and block its author.

A reviewer will try each of these, so test them the same way on the shipping build. Deletion carries the most edge cases, so budget time for it.

Who Owns the Reply If It Comes Back?

This is the question business owners skip, and it costs the most calendar time. A rejection arrives in Apple’s Resolution Center, the message thread attached to your submission, with a guideline number and a short explanation. Then somebody has to read it, decide whether it needs a metadata edit or a new build, and respond.

Name that person before you submit, add a backup, and check that neither is on holiday during the review window. Every hour that reply sits unread pushes your launch date back.

What a Failed Submission Costs Your Launch

A rejection isn’t an engineering ticket but rather a business event with a bill attached. Most of the cost lands on people who never read the guidelines. Apple clears 90% of submissions in less than 24 hours, so a clean build moves fast. However, the second review only starts once your fix is ready, and that wait is what costs you days. The table below shows what slips and who absorbs it.

How long that runs depends on what broke. A screenshot or description fix is an afternoon of work, then a fresh review. Code changes need regression testing first, which is how a small bug turns into a week of delay.

The cheapest way to shorten that loop is to know what usually triggers it. We list the common causes in App Store rejection reasons, the article to open if your submission has already come back.

Where Pre-Submission Checks Usually Break Down

Teams get this wrong in two opposite ways:

• The first is treating the iOS app submission checklist as a one-time event. They run it thoroughly before the initial launch, then skip it for updates, which is exactly when the platform has moved underneath them. Apple’s rules changed twice in the first 4 months of 2026 alone.
• The second is over-testing the wrong layer. Accessibility is the clearest example, since it rarely blocks an App Store review. Teams therefore either ignore it or treat it as a submission gate, and both readings miss the point. The real pressure comes from the European Accessibility Act and the users you quietly lose. That puts mobile app accessibility testing on the release plan rather than the submission form.

Checking App Store requirements early takes an hour, plus a calendar reminder for the slower ones. Finding the same gaps during review can cost you the launch date.

How QAwerk Verifies an iOS Build Before Submission

We test your actual release candidate, not a description of it. That means running the App Store review checklist against the exact binary, installed on real devices. Our engineers complete the sign-up, purchase, restore, and deletion flows, then compare your listing with what the build actually does.

You get a written report of what could fail and why, with each item tied to the guideline it touches. We did exactly that for BeFamily, running more than 500 test cases across 9 devices before launch. The app has had no major issues in production since. Bring us in while the submission date can still move, and there’s room to fix what we find without an emergency sprint.

QAwerk has been testing mobile releases since 2015, and we plug into whatever stage your project is at. Your launch date is the one thing you can’t get back, so talk to us and let’s find what Apple could flag.

FAQ

How long does it take to fix a rejected App Store submission?

It depends on which App Store requirements you missed. Metadata problems like a screenshot or description take a few hours, then a fresh review that Apple usually returns within a day. Code fixes run longer, because the rebuilt app needs regression testing first. Plan for the slower case, since you won’t know which one you’re facing until you hear back.

How long does App Store review take?

Apple reviews 90% of what it receives in less than 24 hours. First submissions from a new developer account often sit longer, as do apps in sensitive categories. Budget 1 to 3 days rather than same-day approval, and never schedule a launch event around a 24-hour turnaround.

Do you need a demo account if your app has no login?

You don’t need one, because Apple asks for demo credentials only when your app includes a login. The Notes for Review field still matters, though, describing any feature that isn’t obvious from the interface, since generic wording gets rejected. Without credentials, whoever picks up your submission simply opens the product and works through it unaided.

Can you ask Apple to review your app faster?

You can, though only two situations qualify for an expedited review request. The first is a critical bug affecting users in production, and the second is an app tied to a fixed public deadline. Supply reproduction steps for the defect, or the name and date of the event. Approval is decided individually and is never guaranteed, so don’t plan around it.

Should you appeal a rejection or fix and resubmit?

Fix and resubmit when Apple is right, which is most of the time. Challenge it with the App Review Board when you believe the guideline was applied incorrectly. Apple allows one appeal per submission that didn’t pass, and expects you to answer any request for more information first. Contesting a genuine violation just costs you days.