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

Most of what I know about App Review I learned from rejection emails. So when Apple's November 2026 Hello Developer said "Browse new App Review help articles", I read all of them. They live in one place now, App Review Help, 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, 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 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 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 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 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 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 checks the sizes, and you can count the rest yourself.
• Copycats, 4.1. Don't put popular app names or trademarked terms in any metadata field. That includes your keywords, where a rival's name is the classic slip. The 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, 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 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. 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 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. 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 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, 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
• Apple Developer: App Review Help
• App Review Help: Track a submission's review status
• App Review Help: Provide information for a complete review
• App Review Help: Accept Bug Fix Submission offers
• App Review Help: Request an expedited review
• App Review Help: Appeal to the App Review Board
• App Review Help: 2.3.3, Show your app in use with screenshots
• App Review Help: 4.1, Preventing copycat and impersonation rejections
• App Review Help: 5.1.1(ii), Write clear purpose strings
• App Review Help: 5.1.1(v), Offering account deletion in your app
• App Review Help: Test your app on compatible devices
• Apple Developer: App Review Guidelines

Keep reading

• Claude Fable 5.2 and Mythos 5.2: what's new, the benchmarks, and what it means for your MacClaude Fable 5.2 and Mythos 5.2 came out on November 9, 2026. Anthropic's benchmarks as charts, the prices, what changes on a Mac, and four free tools.
• The Swift Student Challenge takes Mac apps now. Here is what I would buildApple's Swift Student Challenge 2027 opens February 8 to 28 and, for the first time, takes apps for any Apple platform, macOS included. The rules, the dates, and how I would plan a Mac entry.
• macOS 27.2.1 stops curl trusting eMudhra. Here is what I would check in my Mac appmacOS 27.2.1, 26.7.3 and 15.8.3 remove five root certificates from /etc/ssl/cert.pem after the eMudhra key compromise. What changed, who it reaches, and what Mac app makers should test.
• Live Activities are coming to the Mac menu bar. Here is what I would do with my Mac appThe macOS 27.3 beta puts Live Activities in the menu bar of Apple silicon Macs, and Mac apps can start their own. What changed, the limits, and what to try first.
• Memory is making Macs dearer. Here is what I would do with my Mac appApple says memory will keep Macs short and pricier into 2027, and the cheapest Mac has 8 GB. Why that matters for your Mac app, and the checks to run this week.
• Apple now lets you talk to people who cancel. Here is what I would do with my Mac appSince November 4, App Store subscriptions can show a message or offer when someone cancels. The rules, what Apple says it does, and what to check on the Mac.
• Apple is adding two age rating questions. Here is what I would do with my Mac appFrom November 16, App Store Connect asks about shared location and dating features, and every app must answer by January 12, 2027. What changed and what to do.
• Siri AI is open to every developer now. Here is what I would do with my Mac appApple opened Siri AI to all developers in the macOS 27.3 beta. What changed, what you can and cannot ship yet, and a short plan for a small Mac app.
• Touchscreen Macs ship on November 6. Here is what I would check in my Mac appApple's first touch Macs arrive November 6. What changed, what Apple tells developers to do, and a short list of things to test in your own Mac app.
• Introducing MacPipWhat MacPip is, why I built it, how listing and launch day work, what a blue tick really means, and the real numbers from its first days.
• How to launch a Mac app: a checklist that fits on one pageWhat to do before, on and after launch day for a Mac app: signing, your page, directories, Product Hunt, Show HN and what to measure.
• How to write a one-line description that says what your Mac app doesA plain way to write the one line under your Mac app's name: name the job, cut the hype, and test it on someone who has never seen the app.
• Signing and notarization, in plain words, for people making their first Mac appWhat code signing, notarization and stapling each do, in what order, what your users see without them, and how to check your own build.
• What a dofollow link is honestly worth, from a site that offers oneWhat dofollow means, what Google says about links, why a link from a new directory is worth little today, and what to do instead of buying links.

Submit your appFree tools for makers