App Store submission checklist: 25 things to check (2026)

By Sigsten Gustavii· 27 October 2026· 8 min read

An App Store submission checklist is the list of things Apple's reviewers and App Store Connect will check, done by you beforehand, so your app passes on the initial try.

Apple says it reviews 90% of submissions in under 48 hours, which means the time you lose is almost always to a rejection, not to the queue. Most rejections are avoidable. Below are 25 checks in five groups, each tied to Apple's own pages, followed by how Borel's Publish flow covers them.

The app itself (1 to 7)

1. It does not crash. Test on a real device running current iOS, as Apple asks, including the moment it opens right after install.
2. No placeholder content. No lorem ipsum, "coming soon" screens or test data left visible.
3. Every button and link works. Apple lists broken links among common issues.
4. It does what the listing says. Guideline 2.3 asks that your app perform as advertised.
5. It has lasting value. Apps with minimal functionality can fail guideline 4.2; an app that is only a website in a wrapper is a common case.
6. It is your own. Copycats fail guideline 4.1, and near-duplicates of your other apps fail 4.3.
7. It follows Apple's interface conventions. Apple points to the Human Interface Guidelines; standard navigation and controls are the safe choice.

The store listing (8 to 14)

1. Name, 2 to 30 characters, unique on the store.
2. Subtitle, up to 30 characters.
3. Keywords, up to 100 bytes, with no other apps' or companies' names.
4. Description, up to 4,000 characters, plain text, accurate.
5. Screenshots: at least one for the iPhone Dynamic Island (medium) class, and 13-inch iPad if the app runs on iPad, showing the real app. See App Store screenshot sizes.
6. App icon: a 1024 × 1024 square with no transparency in the flattened icon. See iOS app icon sizes.
7. Category, age rating and copyright filled in; Apple marks the age rating and copyright as required.

Privacy and accounts (15 to 19)

1. A privacy policy URL in App Store Connect, publicly reachable.
2. The same policy linked inside the app, easy to find; guideline 5.1.1(i) requires both.
3. App Privacy answers completed and matching what the app really collects, including third-party code.
4. Account deletion inside the app if people can create accounts, per guideline 5.1.1(v).
5. A clear purpose string for every permission: camera, photos, location, microphone, contacts.

Our post on whether your app needs a privacy policy explains each of these.

Payments (20 to 21)

1. Digital unlocks use in-app purchase. Guideline 3.1.1 rules out your own checkout, license keys or codes for features inside the app.
2. Restore Purchases is there for anything restorable, and the paywall shows the real price and period.

Physical goods and real-world services are the exception: they must use another payment method. See how much Apple takes from app sales.

Build and paperwork (22 to 25)

1. Built with Xcode 26 or later, which Apple has required for uploads since April 28, 2026.
2. Apple Developer Program active, and for paid apps the Paid Apps Agreement, tax and banking set up. See how to enroll.
3. App Review Information complete: contact details and notes for anything unusual, plus a demo video or hardware details if a feature is hard to reach.
4. A working demo account if the app needs sign-in, with the username and password in App Review Information.

The checks that catch people out

A week before you submit

Some items on the list take days, not minutes, because they depend on Apple or on other people. Start these a week ahead:

With those under way, the day you submit is just the final pass through the 25 checks above.

After you submit

Once submitted, the version moves through Waiting for Review and In Review. If it is rejected, Apple's message names the guideline; fix it and resubmit, or reply in App Store Connect to clarify. Our post on how long App Store review takes explains each status and when to ask for an expedited review. Keep a copy of this checklist with your app: every update goes through the same review, and the same checks apply to version two as to version one, especially when you add sign-in, payments or a new permission.

How Borel's Publish flow covers the checklist, step by step

Borel builds this checklist into publishing, so most of it is checked or filled for you before anything reaches Apple.

1. Your app: the name, icon, category, screenshots, description and a phone number for Apple's reviewer, one question per screen. Borel drafts the category from your app.
2. Ready to send: a page listing what Apple needs, each with a tick or a cross and a reason; Fix jumps to the screen, and Continue to Apple stays off until every row is ticked.
3. The review check: Borel builds this exact version on its Mac, opens it, and reads its code for what Apple asks of every app (a reason for each permission, nothing collected that the privacy answers leave out, no placeholder text, no secret keys) and for the rules apps are most often turned down for, such as a missing Delete account option. It lowers the chance of rejection and never promises approval.
4. Privacy pages: Borel drafts a privacy policy and support page for your app, which you read and edit, and hosts them at public addresses.
5. Demo account: if the app has accounts in Borel's cloud, Borel checks the reviewer's demo account before each submission and recreates it if a reviewer deleted it.
6. Send to Apple: Xcode builds, signs and uploads the app on Borel's Mac with current tools. It appears in TestFlight, and you submit it for review from the same window.

Check this app against the App Store submission checklist: placeholder text, buttons that do nothing, a Delete account option, a privacy policy link in Settings, and a clear reason in every permission prompt. Fix anything you find.

The Learn page on getting ready for Apple describes the check in detail, and publishing to the App Store without a Mac covers the whole route.

The bottom line

Most App Store rejections come from things you can check yourself: a crash, a placeholder, a missing link, a missing deletion option or a login the reviewer cannot get past. Run these 25 checks before you submit and review becomes a formality more often than not, and keep the list for every update you send after it. If you are building the app on Borel, its Publish flow and review check work through most of the list with you.

I think a checklist is the cheapest way to save a week of review. If you find something Apple asked for that is missing here, tell me and I will add it.

– Sigsten

Make your iPhone app in Borel

Describe the app you want and see its first screens before you pay anything.