App Store Submission for iPhone Apps: The Full Checklist
Everything we prepare before pressing Submit for Review, and the handful of items that cause almost every avoidable rejection.
Short answer
An App Store submission passes on the first attempt when four things are ready: honest metadata in App Store Connect, privacy labels that match what the binary collects, a working demo account with review notes, and a build hardened through TestFlight. Apple reviews most apps within a day per its App Review page, so preparation, not review speed, decides your launch date.
Know what review actually checks
Everything App Review evaluates is published in the App Store Review Guidelines. Reviewers install your build, follow your metadata, and try to use the app like a new customer with no context. That framing explains most rejections: anything a stranger cannot reach, understand, or verify becomes a rejection ticket.
The speed cuts both ways. A reviewer spends minutes, not hours, in your app, so friction in the first minutes lands as a rejection. The goal of everything below is a first session that works flawlessly for someone who knows nothing about your product and is actively looking for reasons to stop.
Two environment details trip up teams every year. Reviewers test on current iOS and current hardware, so a build that only got real testing on your two-year-old office devices can behave differently in review. And review traffic can come over IPv6-only networks, so a backend or third-party endpoint that fails without IPv4 will crash the session even though everything worked on your office wifi. Both are cheap to test ahead of time and miserable to discover in a rejection.
Harden the build first
- Build with the current toolchain, because App Store Connect enforces it at upload: per Apple’s upcoming requirements page, since April 28, 2026, iOS and iPadOS submissions must be built with Xcode 26 and the iOS 26 SDK. An old Xcode fails before review even starts.
- Ship through TestFlight before submitting, with testers who are not on your team. TestFlight distribution uses the same signing and entitlements path as the store, so it flushes out missing permission strings and provisioning issues early, on real devices and real networks.
- Kill every crash you can reproduce. A crash during review is close to a guaranteed rejection, and the crash the reviewer hits is usually the one on a fresh install with no cached state, which is exactly the state your own devices are never in.
- Remove placeholder content. Lorem ipsum, empty states with TODO text, and dead menu items all read as an unfinished app under the completeness guideline.
- Make sure every declared permission has a clear purpose string. Vague strings like “needs camera access” invite questions; “scans your receipts to import expenses” does not.
- Test the true first-run path: fresh install, airplane mode off, no account, decline every permission prompt once. The app must degrade gracefully, not dead-end.
Get the metadata right
All of this lives in App Store Connect, and Apple’s App Store Connect help documents each field:
- Name and subtitle that describe the app without keyword stuffing. The name is 30 characters; spend them on clarity, not repetition of the category.
- Screenshots that show the real app. Screenshots showing features that do not exist in the build are a rejection on their own under the accurate metadata guideline. Re-shoot them from the submitted build, not last month’s design file.
- Description and keywords written for customers first. Ranking games that misrepresent the app violate the guidelines and age badly anyway.
- Support URL and privacy policy URL that both load. Reviewers click them, and a parked domain reads as an abandoned product.
- Age rating answered honestly; an understated rating is a rejection when the reviewer finds the mismatch.
- What’s New text for updates that says what changed in plain language. “Bug fixes and improvements” is permitted but wastes the one field existing users actually read.
Metadata is also editable without a new binary for most fields, but screenshots and the app name changes ride along with a version submission. Sequence accordingly: lock naming decisions before the final build, because renaming after submission means another review cycle.
Match the privacy labels to reality
Your privacy answers must match what the binary does. Apple documents the required declarations on its app privacy details page. The trap is third-party SDKs: analytics, ads, and crash reporting frameworks collect data even when your own code does not. Audit every SDK before answering, because a mismatch between the labels and observed network traffic undermines the credibility of the entire submission.
Two adjacent requirements bite hardest:
- Account deletion. Any app that lets people create an account must let them delete it, in the app, per Apple’s account deletion requirement. A deactivation toggle or a support email does not count, and reviewers check this flow specifically.
- Payments. Digital goods and subscriptions go through in-app purchase; physical goods and services use outside payment. Routing digital purchases around IAP is the fastest way into a drawn-out review conversation, whatever the current state of regional rule carve-outs.
Fill in App Review Information
This small form prevents more rejections than any other:
- A working demo account if anything requires sign-in. Test the exact credentials on a clean install the day you submit, because a password rotated by a teammate is invisible until the rejection arrives.
- Review notes explaining anything non-obvious: hardware requirements, region-locked content, how to reach gated features, what a companion backend does, test card numbers for sandbox payments.
- A contact phone number someone actually answers during business hours.
If the app needs special hardware, a QR code, or a second device to demonstrate, record a short demo video and link it in the notes. Reviewers use them, and a two-minute video regularly saves a two-day rejection loop.
The demo account deserves one more level of paranoia: seed it with realistic data. A reviewer who logs into an empty dashboard cannot verify your screenshots, and an app that only makes sense with content reads as broken when there is none. Populate the account with the same kind of data your screenshots show, and keep a second seeded account in reserve in case the first gets locked by your own security rules during review.
The rejections we see most, and their fixes
| Rejection trigger | Guideline area | Fix before submitting |
|---|---|---|
| Demo login fails | 2.1 App Completeness | Test credentials on a clean install |
| Crash during review | 2.1 App Completeness | TestFlight round with external testers |
| Screenshots misrepresent app | 2.3 Accurate Metadata | Re-shoot from the submitted build |
| Privacy labels wrong | 5.1 Privacy | Audit SDK data collection |
| Sign-in with no account deletion | 5.1.1 Data Collection | Ship in-app account deletion |
| Payment outside IAP for digital goods | 3.1 Payments | Route digital purchases through IAP |
| Broken support or privacy URL | 1.5 / 5.1 | Click every URL the day you submit |
After you press submit
If you get rejected
Read the rejection literally. Reviewers cite a specific guideline and usually attach a screenshot. Fix exactly what is cited, reply in the Resolution Center describing the change, and resubmit. Replies are answered by people, and a clear, specific response speeds up the second pass. It also matters whether the rejection is against the binary or only the metadata: metadata-only rejections can often be resolved by editing fields and replying, without uploading a new build, which turns a two-day loop into an afternoon.
If you believe the decision is wrong, you can appeal to the App Review Board, but for most teams fixing and resubmitting is faster than appealing. A rejection is not a mark against your account, and it does not slow down future submissions. Repeated identical rejections without changes are what erode trust.
Choose the release deliberately
Approval is not launch. In App Store Connect you pick automatic release, manual release, or phased release, which rolls an update out to a growing percentage of existing users over seven days. For a first launch, manual release is the safe default: approve early, check the live listing, then release when the announcement is ready. For updates with risky changes, phased release plus a monitored crash dashboard gives you a brake to pull, and pausing a phased rollout takes one click while a bad full release takes an expedited re-review to fix.
Plan the timeline backwards
| Days before launch | What happens |
|---|---|
| 10 | Code freeze; TestFlight build to external testers |
| 7 | Fix TestFlight findings; write metadata + privacy labels |
| 5 | Final build; re-shoot screenshots from it |
| 4 | Submit with demo account + review notes |
| 2 | Review buffer; respond to any reviewer question same-day |
| 0 | Manual release, listing verified |
Ten days between code freeze and launch is the comfortable minimum, and it is the schedule we default to on client projects. Compressing it works right up until the one rejection you had no buffer for. If the date is truly immovable, submit earlier with manual release and hold the approved build, because an approved app waiting in your account is a launch you control, while an app still in review is a launch Apple controls.
One honest caveat: none of the process above rescues a product that is not ready. Review checks completeness and compliance, not product quality, and passing review is the starting line. If you would rather hand the whole path to a team that has walked it many times, from design through submission, that is what we do: see our work or book a call.
FAQ
How long does App Store review take in 2026?
Most submissions are reviewed within 24 to 48 hours. Apple states that the majority of apps are reviewed in under 24 hours, but plan for two business days on a first submission, and longer if the app needs extra scrutiny such as account deletion checks, payments, or health data. Resubmissions after a rejection usually come back faster than the first pass.
What is the most common reason iPhone apps get rejected?
Incomplete information is the most common avoidable cause: a demo account that does not work, features reviewers cannot reach, or missing review notes. Crashes and placeholder content are close behind. All of these are fixable before you submit, which is why a pre-submission checklist catches most rejections before Apple does.
Do I need a demo account for App Store review?
Yes, if any part of your app requires sign-in. Provide a working username and password in the App Review Information section of App Store Connect, and test the login on a clean install right before submitting. A dead demo account is an automatic rejection under the app completeness guideline, and it is the single most self-inflicted rejection there is.
Can I submit an iPhone app without TestFlight testing?
You can, but you should not. TestFlight uses the same signing and distribution path as the App Store, so it catches crashes, missing permission strings, and real-device issues the Simulator hides. A build that has survived a week of TestFlight with testers outside your team passes review far more often on the first attempt.
What happens after my app is approved?
You choose the release. Approved apps can go live automatically, wait for your manual release, or roll out gradually with phased release, which delivers the update to an increasing percentage of users over seven days. For a first launch, manual release is safest: approve, verify the store listing looks right, then press release when your announcement is ready.