Your App Store reviewer is a user. Your listing is a product page.

Most submission guides are engineering documents. They explain how to make the technical parts work.

Almost none treat submission as a UX problem, which it is. The reviewer is a user with a time budget. Your listing is a product page competing in a grid. The same first-impression rules that apply to onboarding apply here, and almost nobody applies them.

The reviewer is a user

A first-pass reviewer spends a short, bounded time in your app. Roughly what they encounter:

• The launch screen. Is it branded, or is it a white rectangle?
• A sign-in screen, if you have one. Do they even need to sign in?
• The first functional screen. Does it work with the account you provided?
• One or two feature interactions. Do these match what your description claims?

If any of that breaks, you're rejected. If it merely takes too long to work out — a demo account that doesn't support the sign-in method they tried first, for instance — you can also be rejected for missing information, which is the same outcome with more steps.

The dry run: hand your app and your demo account to someone who has never seen it, give them a minute, and watch. Don't help. Wherever they hesitate, the reviewer will hesitate too, except the reviewer has other apps to get to.

Review notes: write a route, not credentials

This is the highest-value item here and it costs ten minutes.

Most teams fill the App Review Notes field with the minimum:

Email: reviewer@yourapp.com
Password: TestPass123!

That gets the reviewer into the app and no further. They then explore on their own, in whatever order occurs to them, and whatever they don't find, they conclude isn't there.

Better:

Email: reviewer@yourapp.com
Password: TestPass123!

Once signed in:
1. Tap + on the home screen to create a Budget.
2. Add two or three expenses.
3. Tap Reports in the tab bar for the visualisation.
4. Tap Share, top right, for the export flow.

All features are unlocked on this account. No paywall.

Same amount of reviewer time, far more of your app actually seen. It also pre-empts the most common completeness rejection, which is a reviewer concluding a feature doesn't exist because they didn't reach it.

The last line matters more than it looks. A reviewer hitting an unexpected paywall has to decide whether that's the intended experience, and that decision doesn't go your way.

Screenshots that survive being small

Search results render your screenshots at thumbnail size. That's where the install decision gets made, and text sized for a full-screen preview is unreadable there.

A hierarchy that works:

Screenshot 1. One enormous headline stating the single most valuable outcome. Nothing else. It must be readable at thumbnail size, which means far larger type than feels reasonable in the design file.

Screenshots 2 and 3. One feature each, device UI, short caption.

Screenshots 4 onward. Supporting features and social proof, for the minority who swipe.

The test costs nothing: scale your first screenshot down to roughly the width of a thumbnail and look at it. If you can't read the headline, neither can anyone else, and that's the only one most people ever see.

Changelogs people actually read

"Bug fixes and improvements" tells a user nothing, which means it gives them no reason to update, which means they stay on an older build and eventually conclude the app is abandoned.

One line per user-visible change:

• Faster launch on iOS 18
• Fixed: widget showing stale data after a sync
• Fixed: dark mode contrast on Settings
• Added: CSV export for Reports

Note what that does beyond informing. "Fixed: widget showing stale data" tells someone who hit that bug that you saw it. That's worth more than the fix, because a user who reported something and never heard back assumes nobody is home.

The connecting idea

Every item here is the same move: treating someone you can't talk to as a user with limited time and no context.

The reviewer can't ask you where the feature is. The person scrolling search results can't zoom in. The user on an old build can't tell whether the update is worth the download. In each case they make a decision with whatever you gave them, and in each case most teams gave them very little.

Automating the mechanical parts — generating changelog stubs from the release diff, checking listing assets before submission, keeping the workflow in one place — is what letsdeploy.it does. The judgement parts stay yours, and the review notes especially are worth writing by hand.

What's in your App Review Notes field right now? My guess is an email and a password, and that ten minutes spent there has a better return than anything else on this list.