How to Launch a Mac App (2026)

Mac App Store or Sell Directly?

A Mac app can be sold in the Mac App Store, on your own website, or both. Either way you need the paid Apple Developer Program membership: Apple's Mac distribution page says it's required for the store and for a Developer ID certificate. Our iOS launch guide covers enrolling and the fee, and it applies to Mac apps too.

Here's how the two compare, drawing on Apple's table on the same page:

In the store, Apple takes a commission on sales. The App Store Small Business Program lowers it to 15% for developers new to the App Store and those with up to 1 million USD in proceeds in the prior calendar year, but you have to enroll.

In short, the store gives you trust, one-click purchase and a chance of being featured; selling directly gives you control over pricing, trials and upgrades, and room for apps the sandbox won't allow. You can do both, but the store version can't use license keys or its own updater. Decide early between the Mac App Store and selling directly, because the two need different builds.

A third route is Setapp, a marketplace and subscription service for Mac apps. Its developer page says each app goes through a technical review, and membership revenue is shared by usage.

Developer ID and Notarization

If you sell directly, two Apple steps decide whether your app opens cleanly.

Developer ID is a certificate that lets Gatekeeper verify you're a trusted developer when people download and open your app from outside the Mac App Store (Apple's Developer ID page). Only the Account Holder of your developer team can create one.

Notarization is an automated scan, not App Review. Apple's notarization docs say the notary service checks Developer ID-signed software for malicious content and code-signing issues, usually in less than an hour. Since macOS 10.15, all software built after June 1, 2019 and distributed with Developer ID must be notarized. Store apps don't need it, because App Store submission includes equivalent checks.

Since macOS Sequoia, users can't Control-click to open software that isn't signed correctly or notarized; they have to allow it in System Settings, under Privacy & Security (Apple's announcement). That's an unfamiliar extra step at the moment someone decides whether to trust you.

Before you notarize, the build needs:

1. A Developer ID certificate for the signature, not a Mac Distribution, ad hoc or development one.
2. The Hardened Runtime turned on for the app and any command-line tools you ship.
3. A secure timestamp on the signature. Xcode's distribution workflow adds one by default.
4. No com.apple.security.get-task-allow entitlement set to true.
5. The macOS 10.9 SDK or later to link against.

Then notarize from Xcode when you export, or with notarytool; the service no longer accepts uploads from altool or Xcode 13 and earlier. Submit the app in a ZIP, a disk image or an installer package, and staple the ticket with stapler so it travels with the file. Finally, download it from your own site onto a Mac that has never run a development build, and open it as a customer would.

The Sandbox and Mac App Store Rules

The biggest store-only rule: you must enable the App Sandbox (Apple's App Sandbox docs), which limits your app to the resources it requests through entitlements, such as outgoing network connections or access to files the user picks in an Open or Save dialog.

Guideline 2.4.5 of the App Review Guidelines adds more. Store apps:

• Are packaged and submitted with Xcode, as one self-contained bundle, with no third-party installers.
• Don't run at startup or login without consent, and don't leave processes running after the user quits without consent.
• Don't download extra code or standalone apps that add features or change the app from what was reviewed, and don't ask for root privileges.
• Don't show a license screen at launch, require license keys or use their own copy protection.
• Use the Mac App Store for updates; other update mechanisms aren't allowed.

If your app automates other apps, needs wide file access or installs helpers, build a sandboxed version early and see what breaks. Some apps can't do their job inside the sandbox, and launch week is the expensive time to find out.

Every store version goes through App Review, and the App Review section of our iOS guide applies here too. For a beta, TestFlight works with Mac apps built with Xcode 13 or later (TestFlight overview); for a direct build, a notarized download link does the same job. Our guide to finding beta testers covers recruiting.

Your Product Page, in the Store and on Your Site

In the store, the text fields follow the same limits as on iPhone: a 30-character name and subtitle, 100 characters of keywords, 170 characters of promotional text and a description of up to 4,000 characters (App Store Connect reference). The iOS guide covers how to use each one. The Mac-specific part is visual:

• Screenshots: 16:10, at 1280 × 800, 1440 × 900, 2560 × 1600 or 2880 × 1800 pixels, JPEG or PNG with no transparency. You need at least one and can add up to 10 (screenshot specifications).
• App previews: up to three, in landscape at 1920 × 1080, 15 to 30 seconds long and up to 500MB (preview specifications).

Mac screenshots are already wide, so the same images work on launch boards, which mostly show wide images too. Show the app doing its main job on a clean desktop.

If you sell directly, your website is the product page, and it has to answer what the store would answer for you:

1. What it does, in one line, above a screenshot of the real app.
2. Requirements: the oldest macOS version you support, and whether it runs on Apple silicon, Intel or both.
3. Price and trial: what's free, for how long, and what it costs after that.
4. A download button for a notarized DMG or ZIP, with no form in front of it.
5. A changelog and a contact address, so visitors can see someone maintains it.

Our guides to landing page copy for developers and making a product demo video cover the words and the preview.

Free Trials and Pricing

Plan the trial together with the price, because how you can offer one depends on where you sell.

In the Mac App Store

• Paid up front: the simplest option, but there's no trial in the store itself.
• Free with a trial unlock: guideline 3.1.1 lets non-subscription apps offer a free time-based trial through a Non-Consumable in-app purchase at Price Tier 0, named "XX-day Trial". Before the trial starts, the app must say how long it lasts, what stops working when it ends and what the full version costs.
• A subscription with an introductory offer: a free trial, pay as you go, or pay up front. Customers can redeem one introductory offer per subscription group, and the purchase flow must say how long a free trial lasts and the price billed after it (Apple's subscriptions page).

For the price itself, App Store Connect offers up to 800 price points by default. Set a price for your base country or region, and Apple generates prices for the other 174 storefronts, adjusted for exchange rates and certain taxes (setting a price).

If you also have an iOS app, universal purchase lets one purchase cover both, using the same bundle ID. Decide before launch: separate app records can't be merged later (you'd have to remove one from sale, and its ratings and reviews don't transfer), and once two platform versions are approved, the app stays a universal purchase.

Selling directly

You build the trial yourself, usually a time-limited or feature-limited version unlocked by a license key, and a payment provider runs the checkout. Check what it handles, such as sales tax and VAT, refunds and license delivery: in the store, Apple handles payments, and outside it that's on you and your provider.

Either way, show the price on your site before the download. The pricing calculator helps you test the numbers, and our guide to pricing a micro SaaS covers the subscription side.

Where Mac App Makers Launch

Neither the Mac App Store nor your own site brings visitors on its own, so plan where launch-day traffic comes from.

1. Your beta testers, first. They know the app, and their early ratings and replies come from real use.
2. Show HN, for developer tools and utilities people can try right away. A download with a free trial counts; a waitlist doesn't. See how to write a Show HN post.
3. Product Hunt, if you can bring people with you on a single day.
4. Communities such as r/SideProject, Indie Hackers and Mac-focused subreddits. Read each one's self-promotion rules before you post.
5. Launch boards with longer windows, such as Peerlist, Fazier and Hauntboard, where a person reviews every launch and its page views and visits are shown in public.
6. X and building in public: see our guide to announcing your launch on X.

A community post that tells Mac users what they need to know before they click:

If you sell directly, tag each link you post with the UTM builder so your analytics show which channel sent each download. The launch post generator drafts a version for each community.

Shipping Updates After Launch

Your first fix will probably ship days after launch, so set up the update path first.

In the Mac App Store, updates go through App Review like the first version, and phased release works on macOS: an update reaches users with automatic updates turned on over 7 days (1%, 2%, 5%, 10%, 20%, 50%, then 100%), and you can pause it for up to 30 days in total (phased release). Every version after the first also needs "What's New" text, up to 4,000 characters.

Selling directly, you ship updates yourself. One option is Sparkle, an open-source update framework for macOS apps that supports signed updates, delta updates and sandboxed apps. Each release has to be signed with Developer ID and notarized again before you publish it, so script the steps once: build, sign, notarize, staple, upload.

Ratings follow the same rules as on iPhone. StoreKit's review request works on macOS 13 and later, appears at most three times in a 365-day period, and shouldn't be tied to a button, since it may not appear (RequestReviewAction). For a permanent "Write a review" link, add action=write-review to your product page URL. The iOS guide covers the rest of Apple's rules on asking.

For release notes people actually read, see how to write a changelog. Then read what to do after launch day, and once your app is live, launch it on Hauntboard for a permanent page that search engines and other makers can find.