Launch a macOS app on the Mac App Store

Choose the Mac app before you choose the listing

There are three different ways an iPhone or iPad product can reach Mac users. They do not create the same product, distribution path, or store story.

Native macOS

Build for the desktop

Choose this when menus, windows, keyboard work, file behavior, automation, and deep Mac conventions are central to the product.

Mac Catalyst

Bring the iPad foundation

Choose this when the iPad codebase is the right starting point and you can still finish the experience for Mac input, windows, menus, and layout.

iOS app on Mac

Offer compatibility

Apple silicon Macs can run eligible iPhone and iPad apps. This is availability, not a substitute for a deliberately designed Mac product.

Editorial rule: do not call an app “made for Mac” because it launches on a Mac. The store promise should match the interaction model you actually ship.

Add macOS to the existing app record

For a Universal Purchase, open the existing app record in App Store Connect and add macOS as a platform. Apple says the Mac app uses the same Apple ID, SKU, and bundle ID as the iOS app. You upload the Mac build from a separate target, and the platform versions may use different version and build numbers.

Identity

Shared: Apple ID, SKU, bundle ID, app record
Platform delivery: A separate macOS target and build

Versioning

Allowed: Different platform version and build numbers
Operational advice: Document the mapping for support and release notes

Initial transfer

Apple transfers: Most existing app information
Prepare for macOS: Promotional text, description, and screenshots

If an eligible iPhone or iPad app is already offered on Apple silicon Macs, releasing a native macOS platform version replaces that iOS-on-Mac version in the Mac App Store. Existing users receive the Mac app as an update. Test data, files, accounts, and purchase restoration with that transition in mind.

Build a Mac product page, not a stretched phone page

A Mac prospect wants evidence about a desktop workflow: what the window contains, how much context stays visible, what keyboard and pointer use feel like, how files or sync behave, and whether the app belongs beside the tools they already use.

Mac screenshots

Apple currently accepts 1–10 Mac screenshots. They must use a 16:10 aspect ratio, contain no transparency, and use one of these exact pixel dimensions:

1280 × 8001440 × 9002560 × 16002880 × 1800

01
Lead with the desktop promise
Show the main window at a readable scale and make the outcome clear without relying on tiny UI.
02
Prove the working surface
Use a real, credible state that reveals navigation, information density, or the canvas.
03
Show native interaction
Include the Mac value that matters: multiple windows, keyboard flow, menus, drag and drop, files, or pointer precision.
04
Connect the ecosystem
If it is true, show how the Mac experience continues work from iPhone or iPad without implying functionality you do not ship.
05
Close on trust
Use the final frame for privacy, offline ownership, purchase continuity, or another concrete decision-making proof.

App previews are optional. Apple allows up to three per supported display size and language; macOS previews must be landscape. A preview should demonstrate interaction that a still image cannot explain—not repeat the screenshot captions with motion.

App Sandbox is required for Mac App Store distribution. Configure only the entitlements the product needs, then exercise the signed release build against the real file, network, account, purchase, notification, and data paths those entitlements affect.

01
Test supported Macs
Use real supported hardware where possible, not only a debug build on the primary development machine.
02
Test window life cycles
Open, resize, minimize, restore, close, relaunch, and use multiple windows if the product supports them.
03
Test every input path
Keyboard navigation, shortcuts, pointer states, menus, scrolling, focus, drag and drop, and text editing should feel intentional.
04
Test continuity and migration
Verify sign-in, sync, local files, entitlements, subscription access, and restoration from the existing iOS customer state.
05
Test accessibility by task
Complete common workflows using the accessibility features you intend to declare for Mac, not merely a component checklist.
06
Run TestFlight
TestFlight for Mac requires a supported Xcode toolchain. External testing can include up to 10,000 testers; the first external build needs beta review and builds expire after 90 days.

App privacy answers are app-level and should represent data practices across every platform. Re-audit them when Mac adds new file access, diagnostics, accounts, third-party SDK behavior, or data collection. Accessibility labels are device-specific; declare the Mac experience based on what common Mac tasks actually support.

Give App Review a reproducible path

Each platform version is submitted separately. Attach the Mac build to the macOS version, add the version to review, and submit it. Review notes should remove uncertainty: give a working account, state where a reviewer finds the primary workflow, explain entitlements or unusual file access, list purchase products to exercise, and describe any dependency on the iPhone or iPad app.

Choose the release method deliberately and verify price, tax category, territories, agreements, and availability. Apple notes that an approved release can take up to 24 hours to appear.

Measure whether the Mac promise holds

Watch product-page conversion by source and territory, but do not stop at the download. Segment activation, purchase restoration, subscription access, retained use, review themes, support contacts, and crashes by platform and app version. A Mac launch is successful when the store page attracts people whose desktop job the product can keep serving.

Need the architecture?Read Universal Purchase →Preparing assets?Compare requirements →Ready to submit?Run the checklist →