# Apple wrote down how App Review works. Here is what I would change before I submit

> In its November 2026 Hello Developer note, Apple pointed developers to new App Review help articles. They put in writing things most of us learned from rejections: Apple aims to review 50% of submissions in under 24 hours and 90% in under 48; demo logins must still work when the review starts; you should reply in App Store Connect instead of resubmitting to answer a question; a rejection that starts with "Bug Fix Submissions:" lets you ship the fix and deal with the issue next time; more than half of your screenshots must show the app in use; and every permission needs its own clear purpose string. Only one article mentions the Mac by name, but every rule applies to a Mac App Store submission.

By Justinas Rolando, maker of MacPip. Published November 13, 2026. Page: https://macpip.com/blog/app-review-help-articles-mac-apps

Most of what I know about App Review I learned from rejection emails. So when Apple's [November 2026 Hello Developer](https://developer.apple.com/hello/november26/) said "Browse new App Review help articles", I read all of them. They live in one place now, [App Review Help](https://developer.apple.com/help/app-review/), and they say out loud a lot of things that used to be folklore.

Here's what's in them that matters for a Mac app, and what I'd change before my next submission.

## First, who this is for

App Review only looks at what goes through App Store Connect: the Mac App Store, TestFlight, In-App Purchases and the rest. If you sell your Mac app from your own site with a Developer ID, nobody at Apple reviews it. It goes through [notarization](/guides/what-is-notarization-on-mac), which is an automated check. So if you're direct only, skim this and save it for the day you add a Mac App Store version.

## How long a review takes

The [review status article](https://developer.apple.com/help/app-review/after-submitting-for-review/review-status) gives Apple's own target: review at least 50% of submissions in less than 24 hours and 90% in less than 48 hours. It also says what makes one slower, like a limited review history, documents Apple needs, or complex or novel issues.

What I'd do: plan a launch day with two clear days before it, more for a first app. And submit early with a manual release, so you can pick the minute it goes live.

## The Notes field is where reviews are won

The [complete review article](https://developer.apple.com/help/app-review/before-submitting-for-review/complete-review) is blunt: "Incomplete submissions will be rejected." The details that matter:

- **Demo logins have to work when the review starts**, not just when you submit. A test account that expires or changes in between can get you rejected.
- **If login needs a code, put it in Notes.** Without it, Apple may need a call, and calls are typically done within three to five business days. That's a week gone.
- **Subscriptions need a demo account with an expired subscription**, so the reviewer can see the whole purchase flow.

What I'd do: write the Notes field like a short how-to for a stranger. Where to click first, which account to use, and what the menu bar icon does if your app has no window. That last one is very Mac.

## When it gets rejected

This is the part I wish I'd had in writing years ago.

- **Don't resubmit to answer a question.** If App Review asks for information, reply in App Store Connect. Resubmit only for a fix in the build, and only once you've fixed every issue they named.
- **Look for "Bug Fix Submissions:" at the top.** If a rejection starts with that note, the [Bug Fix Submissions article](https://developer.apple.com/help/app-review/after-submitting-for-review/bug-fix-submissions) says you can reply to accept it and deal with the issue in your next update. Don't resubmit. It only works for apps that were approved before, never for legal or safety issues, and an issue can't be put off twice.
- **Expedite only when it's real.** Apple says expedite requests "should be reserved for matters of genuine urgency", and only for builds already sent to review. For a launch tied to an event, put the event and its date in Notes.
- **Appeal last.** First reply to the rejection and explain. If that doesn't work, the [App Review Board](https://developer.apple.com/help/app-review/after-submitting-for-review/appeal-to-the-app-review-board) takes one appeal per app, and once you've resubmitted, you can't appeal that rejection.

## Four rules, with numbers

The guideline articles are short and concrete.

- **Screenshots, 2.3.3.** [More than half](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots) of your screenshots must show the app in use, counted per device type. Three screenshots means two must be the app. A splash screen or a title card is fine as long as it's the minority. MacPip's [screenshot checker](/tools/app-store-screenshot-checker) checks the sizes, and you can count the rest yourself.
- **Copycats, 4.1.** Don't put [popular app names or trademarked terms](https://developer.apple.com/help/app-review/guideline-reference/4-1-prevent-copycat-rejection) in any metadata field. That includes your keywords, where a rival's name is the classic slip. The [App Store keyword checker](/tools/app-store-keyword-checker) counts your fields so you can see what's in them.
- **Purpose strings, 5.1.1(ii).** Each protected resource needs its [own clear purpose string](https://developer.apple.com/help/app-review/guideline-reference/5-1-1-purpose-strings), localized if your app is. Apple's own bad example is "To use location." And you're responsible for what your SDKs ask for, too. Paste your Info.plist into the [Info.plist explainer](/tools/info-plist-explainer) and it flags empty and vague ones.
- **Account deletion, 5.1.1(v).** If people can make an account in your app, they must be able to [start deleting it in the app](https://developer.apple.com/help/app-review/guideline-reference/5-1-1-account-deletion). Deactivating isn't enough, and you can't make them phone you. If they subscribe, tell them billing continues through Apple until they cancel.

## The one line about the Mac

Only the [compatible devices article](https://developer.apple.com/help/app-review/before-submitting-for-review/test-compatible-devices) names the Mac. It says compatible iPhone and iPad apps can run unmodified on Macs with Apple silicon, and that apps that lean on touch you can't do with a keyboard are not well suited for macOS. If you make an iPad app, check whether it's showing up on the Mac App Store, and turn that off if it doesn't work well with a keyboard and trackpad. The same page says TestFlight takes up to 100 internal and 10,000 external testers, and that the first build you give to external testers goes to App Review too.

## What's New counts too

One more from the guidelines, not the new articles. Guideline 2.3.12 says your What's New text must describe new features and changes, and only simple bug fixes and performance work can get away with a generic line. "Bug fixes and improvements" on a release with a new feature is asking for a question.

So today's new free tool is the [release notes formatter](/tools/release-notes-formatter). Paste rough notes or your `git log --oneline` lines. It sorts them into New, Improved and Fixed, drops the chore, ci and merge lines, flags ticket numbers and file names, checks the 4,000 character limit, and gives you three copies: plain text for App Store Connect, HTML for your Sparkle appcast, and Markdown for GitHub. Your notes stay in your browser. The [Sparkle appcast checker](/tools/sparkle-appcast-checker) is next door for the feed they go in.

## My short list

1. Two clear days before launch day, and a manual release.
2. A Notes field a stranger could follow, with a working demo account.
3. Reply, don't resubmit, when they only ask a question.
4. Count screenshots, read every purpose string, and keep other apps' names out of the keywords.
5. What's New that says what changed.

And once it's out, [listing it on MacPip is free](/submit), Mac App Store or not. Listings are scanned automatically when they're submitted, and a blue tick only means a person tried the app on a date.

## Sources
- [Apple Developer: Hello Developer, November 2026](https://developer.apple.com/hello/november26/)
- [Apple Developer: App Review Help](https://developer.apple.com/help/app-review/)
- [App Review Help: Track a submission's review status](https://developer.apple.com/help/app-review/after-submitting-for-review/review-status)
- [App Review Help: Provide information for a complete review](https://developer.apple.com/help/app-review/before-submitting-for-review/complete-review)
- [App Review Help: Accept Bug Fix Submission offers](https://developer.apple.com/help/app-review/after-submitting-for-review/bug-fix-submissions)
- [App Review Help: Request an expedited review](https://developer.apple.com/help/app-review/after-submitting-for-review/request-expedited-review)
- [App Review Help: Appeal to the App Review Board](https://developer.apple.com/help/app-review/after-submitting-for-review/appeal-to-the-app-review-board)
- [App Review Help: 2.3.3, Show your app in use with screenshots](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots)
- [App Review Help: 4.1, Preventing copycat and impersonation rejections](https://developer.apple.com/help/app-review/guideline-reference/4-1-prevent-copycat-rejection)
- [App Review Help: 5.1.1(ii), Write clear purpose strings](https://developer.apple.com/help/app-review/guideline-reference/5-1-1-purpose-strings)
- [App Review Help: 5.1.1(v), Offering account deletion in your app](https://developer.apple.com/help/app-review/guideline-reference/5-1-1-account-deletion)
- [App Review Help: Test your app on compatible devices](https://developer.apple.com/help/app-review/before-submitting-for-review/test-compatible-devices)
- [Apple Developer: App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)