Apple's reviewer gets one try at your app. Make it an easy one.

One person, one try

When you submit an iPhone app, a person at Apple installs it and tries it. They don't know your business. They haven't seen your demo. They can't ask the developer what a button is for. If they can't get in, or can't find what's new, or can't tell what the app is for, the simplest thing for them to do is send it back.

Apple is fairly open about what goes wrong. Its App Review Guidelines, last updated June 8, 2026, open with a "Before You Submit" list of common missteps that can slow review or cause a rejection. Read it and you'll notice how few of them are about code. They're about access, explanation and paperwork.

It also helps to know what review is not for. Guideline 2.2 says demos, betas and trial versions belong on TestFlight, Apple's beta testing service, not the App Store. If the app isn't finished, test it with real users there first, and submit for review when it's the version you mean to release.

So here are the mistakes we'd check for before pressing submit, with the guideline each one comes from. The reviewer can only approve what they can reach.

Mistake one: the reviewer can't get in

If your app has a login, the reviewer needs one too. Guideline 2.1(a) asks you to "include demo account info (and turn on your back-end service!)" if your app includes a login, and the Before You Submit list adds "any other hardware or resources that might be needed," with a sample QR code as an example.

The ways this goes wrong are mundane. The demo account's password was changed by someone on the team last week. The account works, but it's empty, so every screen shows nothing. The app needs a code sent by text to a phone the reviewer doesn't have. The staging server the demo account lives on was switched off for the weekend. Or the app only works in one country and the reviewer isn't there.

Before you submit, log in with the demo account on a fresh device, on mobile data, and walk through the main job. Fill the account with realistic sample data, and leave it alone until review is done. If your app depends on hardware or a location, say so in the review notes and explain how the reviewer can see the feature anyway.

Mistake two: the reviewer can't see what's new

The review notes field in App Store Connect is the only conversation you get, so use it. Apple asks for "detailed explanations of non-obvious features and in-app purchases" there, and guideline 2.3.1(a) says new features must be described "with specificity" in the notes, adding that "generic descriptions will be rejected."

So say what's changed and where to find it. "New: shift swap. Tap Schedule, then press and hold any shift. The demo account has two shifts set up for this." That kind of note takes five minutes and saves a round trip.

The same goes for in-app purchases. Guideline 2.1(b) says they need to be complete, visible to the reviewer and working. If one can't be found in the app, explain why in the notes.

And check the store listing itself. Guideline 2.3.3 says screenshots "should show the app in use, and not merely the title art, login page, or splash screen."

Mistake three: it's a website in a wrapper

Guideline 4.2 sets a minimum: your app should include "features, content, and UI that elevate it beyond a repackaged website." An app that's just your mobile site inside a frame, with nothing that uses the phone or works better as an app, is at risk here.

This is less a review problem than a product question that review exposes. If you're unsure whether you need an app at all, our note on telling whether you need an app or a good mobile website is a better place to start than the submit button. If you do need one, make sure the reviewer can see why: offline access, notifications people actually want, the camera, location, faster repeat tasks.

Mistake four: the account rules

A few account rules catch teams out because they're easy to forget until review.

Account deletion. Guideline 5.1.1(v): "If your app supports account creation, you must also offer account deletion within the app." A link to email support isn't the same thing. Plan it as a real feature, including what happens to the person's data afterward.

Login options. If people sign in with a third-party or social login, such as Google, guideline 4.8 generally requires you to also offer an equivalent login option with privacy features Apple lists, with some exceptions, such as apps that only use your company's own sign-in. Our note on why the Google button shouldn't be the only way in covers the product side of the same decision.

Privacy policy. Guideline 5.1.1(i) requires a link to your privacy policy in App Store Connect and inside the app, and the policy has to explain what you collect and how people can ask for deletion.

Mistake five: treating a rejection as the end

Rejections happen to careful teams too. The guidelines say that if you have questions or more information, you can reply to App Review directly in App Store Connect, and if you disagree you can appeal. A calm, specific reply that shows where the feature is or what you've changed often resolves it.

If timing really is critical, Apple lets you request an expedited review, and asks developers to use it only when they truly need it. It's a safety valve for a genuine emergency, like a broken payment flow in a live app, not a substitute for submitting early.

Two things help here. First, build review into the launch plan. Don't announce a launch date that depends on approval coming through on the first try. Second, if the app is already live and a fix is urgent, the guidelines describe a path for bug fix submissions not to be held up by unrelated guideline issues, except legal or safety ones. And keep an eye on old versions of your app still out there while the new one waits.

We design and build mobile apps, including the unglamorous part where they get through review and out to people. If an app is stuck in review, or you're about to submit your first one, we're happy to take a look.

Related work: WorkStep.