How to submit an app for App Review

Submitting for App Review should feel like a controlled handoff, not a scramble. This guide walks through what Apple expects, the order that saves rework, and how Helm releases keep the moving parts visible before you submit.

What “submit for review” actually means

You are asking Apple to evaluate a specific version: its binary, metadata, screenshots, and review materials. Until that package is complete and consistent, submission will fail validation or come back with questions.

Think in layers:

1. Binary: the build you selected for the version
2. Listing: name, description, screenshots, and localized text that will go live
3. Review package: contact info, demo account, notes, and attachments App Review needs
4. Release timing: automatic, manual, or after approval

Before you create the submission

Confirm the build

Pick a build that matches what you tested. Check export compliance answers, and finish any App Clip default experience work if your app uses one. Rejecting the wrong binary later costs a full cycle.

Write What’s New for every locale you ship

Empty or placeholder release notes are a common last-minute miss. See how to write What’s New for a structure that stays honest and scannable.

Refresh screenshots when the UI changed

If the update changes primary flows, update App Store screenshots for the devices you support. Outdated screenshots are a trust problem even when review accepts them.

Fill App Review information

Contact name, phone, email, and a demo account when parts of the app are gated. Use App Review notes to explain non-obvious paths, sandboxed features, or hardware requirements.

A reliable submit order

1. Create or open the version in App Store Connect (or in Helm).
2. Attach the correct build.
3. Complete What’s New, promotional text if you use it, and any version-level metadata.
4. Verify screenshots and previews for required device sizes.
5. Confirm App Review contact details and notes.
6. Run a launch checklist for missing fields.
7. Choose release timing (automatic, manual, or after approval).
8. Submit for review.
9. Watch status, and keep a teammate ready if Resolution Center needs a reply.

Using Helm for the handoff

Releases in Helm are designed for this sequence on Mac, with a focused companion experience on iPhone.

• Create versions and edit What’s New per language without tab hopping.
• Select or auto-select a build for the version.
• Track export compliance and review information alongside the release.
• Use the launch checklist covering What’s New, build, encryption, review info, screenshots, and listing fields.
• Submit for review, reject a binary, or ship when ready from the same place.
• Prefer automatic, manual, or after-approval release with defaults you can set in Settings.

If you automate preparation with agents or scripts, the helm-asc CLI (Pro) can help stage versions and submissions. Still do a visual pass in the app before anything customer-facing goes out.

Common rejection and delay causes

• Demo account missing or expired when login is required
• Review notes that do not explain how to reach the new feature
• Broken deep links or placeholder content in the build
• Missing privacy nutrition or age rating updates when behavior changed
• Screenshots that show a different product than the binary

Most of these are process issues, not surprises. A checklist catches them earlier than hope.

After you submit

Stay reachable. Resolution Center questions often have short windows in practice even when the formal clock feels longer. Keep review contacts current in Helm so whoever is on point can answer from Mac or iPhone.

If you use phased release, decide that policy before approval day so you are not improvising while the version flips to Ready for Sale.

Related reading

• Prepare a launch checklist
• Write What’s New
• Manage phased release
• App Review notes
• Export compliance