Mac App Store review checks things that iPhone review never does, and none of them show up in a local build or a test run. They are about where the app is distributed and how a Mac user expects an app to behave. It helps to go through this list by hand, on a real Mac, in this order, before you submit.
1. The app is sandboxed, and user files go where the user chose
Apple's docs say: "To distribute a macOS app through the Mac App Store, you must enable the App Sandbox capability." Guideline 2.4.5(i) adds that apps "must be appropriately sandboxed".
The trap is that a sandboxed write to the Documents folder still succeeds. The file just lands inside the app's container, a hidden folder the user never opens. One of our Mac apps was rejected for exactly that: Apple's message said the app "saves user data to the app's container, which is not user accessible".
- Save anything the user made through a Save dialog:
NSSavePanelin AppKit,fileExporterin SwiftUI. - Turn on User Selected File: Read/Write in the App Sandbox capability (
com.apple.security.files.user-selected.read-write). - Keep the container for your own data: databases, caches, settings.
Details and code in 2.4.5, sandbox saves and update checks.
2. Every entitlement is one you can explain
Over-broad entitlements are a 2.4.5(i) rejection too. Print the signed entitlements of the archive you are about to upload:
codesign -d --entitlements - YourApp.appRead every line. get-task-allow must not be there in a store build, and anything you cannot explain in one sentence should go. To read a .provisionprofile or paste an .entitlements file as a table, use our provisioning profile viewer.
3. No update checks, no installers, no license keys
Guideline 2.4.5 lists what a Mac App Store app may not do. The ones that catch indie Mac apps:
- (vii) Updates only through the Mac App Store. "Other update mechanisms are not allowed." Apple's message to us named "frameworks or APIs that may be used to update the app", so hiding the menu item is not enough. Keep the updater framework out of the store build entirely.
- (vi) No license screen at launch, no license keys, no copy protection of your own.
- (iii) Nothing at login without consent, and no processes left running after the user quits.
- (ii) No third-party installers. One self-contained app bundle, built and submitted with Xcode.
If you also sell a direct-download version, give it its own build configuration and keep its updater and licensing code behind a compilation condition.
4. The main window can always be reopened
Close the main window with ⌘W. If the app keeps running and no menu item brings the window back, that is a Guideline 4 (Design) rejection we have received ourselves. Either quit when the last window closes (after saving), or give the window a menu item that reopens it. Fixes for SwiftUI and AppKit are in no way to reopen the window.
5. Screenshots are 16:10
App Store Connect requires Mac screenshots in one of four sizes, all 16:10:
- 1280 × 800
- 1440 × 900
- 2560 × 1600
- 2880 × 1800
A capture of a window, or of a display with a different shape, will not fit. Like all App Store screenshots, they can't include alpha channels or transparency. Check and resize them with the screenshot sizes tool. If you add an app preview, Apple accepts Mac previews in landscape only.
Use your own clean desktop for screenshots: no other apps in the Dock, no personal files, your own sample content. A Mac screenshot shows a lot more than your app.
6. The name under the icon matches the store name
On a Mac, the name the user sees in Finder, the Dock and the app menu comes from the bundle, not from App Store Connect. Apple's docs say CFBundleName can be up to 15 characters and that the system may show it if CFBundleDisplayName isn't set. Guideline 2.3.8 asks that your app name and icons are "similar to avoid creating confusion".
Install the build, look at the app menu, Finder and the Dock in every language you sell in, and compare each with the store name. See 2.3.8, name mismatch.
7. "Mac" is not part of your app's identity
It is tempting to put "for Mac" or "Mac" in a subtitle. We have had a Guideline 5.2.5 citation for an Apple trademark in our metadata. Apple's trademark guidelines say you "may not use the Mac trademark standing alone except to denote or refer to the Apple Macintosh product line", and that a compatibility reference should be a referential phrase such as "runs on", "for use with" or "compatible with", less prominent than your own product name. Apple's marketing guidelines give the same pattern: "app name for iPhone", not "iPhone app name".
In practice, use the 30 characters of the subtitle to say what the app does. The store already tells people it is a Mac app. More in brand names in metadata.
8. The Mac version has its own review information
Apple's help says app versions for each platform are submitted separately. If your record also has an iOS app, the Mac version has its own screenshots, copyright line, build and App Review Information. Check on the Mac version page:
- Copyright is filled in; it is required.
- Sign-in required is ticked only if the app really has a login, with a working demo account.
- Review notes explain anything a reviewer could miss, such as a menu bar item or a feature that needs a file to open. Attach a sample file if they need one.
- Export compliance: set
ITSAppUsesNonExemptEncryptionin the Mac target'sInfo.plisttoo, or App Store Connect asks the questions again on every upload.
9. Test on the kind of Mac the reviewer uses
Reviewers note the device they used in their messages, and for our Mac apps it has been a laptop, not a large external display. Test at a laptop screen size: the window fits, nothing is cut off at the bottom, and the app is usable at the default window size. Launch it once with a fresh user account, too, so you see the first run with no settings and no files.
One-minute check
On the archive you are about to upload: save something and confirm a Save dialog asked where; press ⌘W and find a way back from the menu bar; open the app menu and Settings and confirm there is no update item; read the output of codesign -d --entitlements -. Then go through the rest of the pre-submit checklist and, if it comes back anyway, what to do after a rejection. More release tools are on the toolkit page.
These notes are from Obelisk Club's own submissions. Apple's wording and requirements change; check the current App Review Guidelines, App Store Connect Help and Apple's trademark guidelines.