How to Sell a Mac App Outside the App Store

Every Mac developer who charges for software eventually asks the same question: should this be in the App Store, or should I sell it myself? It is a real decision with real tradeoffs, and the answer is not the same for every app. This post walks through what selling a Mac app directly actually involves, so you can make that call with clear eyes.

The case for selling directly

The number everyone quotes is the commission. The App Store takes 30%, or 15% if you qualify for the Small Business Program. On a $49 app, that is somewhere between $7 and $15 per sale that never reaches you. Across a year of sales, it adds up to a meaningful fraction of a salary.

But the commission is not the most important reason developers leave. The bigger one is the customer relationship. When someone buys through the App Store, Apple owns that relationship. You get a sales figure, not an email address. You cannot tell your customers about a major new version, you cannot offer an upgrade discount, you cannot run a survey, and you cannot move them onto a new pricing model without Apple’s machinery in the way.

Selling directly flips that. Payments run through your own Stripe account, so you hold the customer record — email, purchase history, everything. You can email customers, offer coupons, and change your business model whenever you decide to. For a product you intend to support for years, that ownership compounds.

What you give up

This post is not a sales pitch for leaving the App Store, so here is the honest other side.

You lose discovery. The App Store is a place people browse; your website is not. If a meaningful share of your sales comes from store search and featuring, direct distribution will cost you those.

You take on all of your own marketing. No charts, no editorial features, no “you might also like.” Every customer arrives because something you did brought them there.

You handle support and refunds yourself, and you have to build licensing — the part Apple quietly does for you through receipt validation.

For a focused tool with an identifiable audience that you can reach directly — developer tools, pro creative software, niche utilities — those costs are usually worth paying. For an app that lives or dies on casual store browsing, they may not be. Be honest with yourself about which one you have.

Distributing the app

Selling outside the App Store does not mean bypassing Apple’s security model. macOS will refuse to cleanly open an app that is not properly signed and notarized, and your customers will see alarming warnings.

Two requirements matter:

• Developer ID signing — you sign the app with a Developer ID Application certificate from your Apple Developer account, proving it comes from an identified developer.
• Notarization — you upload the signed build to Apple’s notary service, which scans it and returns a ticket you “staple” to the app. A notarized app opens cleanly; an un-notarized one is effectively unusable for non-technical customers.

Both steps are scriptable into your release pipeline with xcrun notarytool and stapler. You then ship the app as a DMG or ZIP downloaded from your own site.

Taking payment and licensing the app

With distribution handled, you need to collect money and decide who is allowed to run the paid features.

For payment, the practical choice is Stripe — a payment processor where you are the legal seller and you own the customer data. (A merchant of record like Paddle or Lemon Squeezy is the alternative; it handles tax compliance for you but takes a larger cut and owns the customer.)

For licensing, you need a system that issues a key when a payment completes and lets your app verify that key — ideally offline, so the app launches without a network call. This is the piece Apple’s receipt validation used to handle, and it is the part most developers underestimate. A complete write-up of the moving parts lives in the guide to selling an app outside the App Store.

The short version of the licensing flow in code:

import KeylightSDK

let licensing = try! Keylight.manager(
    sdkKey: "sdk_live_...",
    tenantId: "acme",
    productId: "myapp",
    keyPrefix: "ACME",
    trustedPublicKeyBase64: "<your-public-key>",
    trialDurationDays: 14,
    branding: .init(appName: "My App", purchaseURL: URL(string: "https://acme.example.com/buy")!, supportEmail: "[email protected]", tintColor: .blue)
)

await licensing.checkOnLaunch()

switch licensing.state {
case .licensed:
    unlockFeatures()
case .trial(let daysLeft):
    showTrialBanner(daysLeft: daysLeft)
case .expired:
    showRenewalPrompt()
case .invalid:
    promptForLicenseKey()
}

That is the whole client-side surface: create a manager, check on launch, switch on the state.

Making the decision

Selling a Mac app outside the App Store is well-trodden ground — many of the best-known Mac apps have done it for years. The build-pipeline work (signing, notarization) is a one-time setup. The licensing work is the part that quietly grows if you build it by hand, which is why most direct sellers reach for a dedicated licensing layer rather than maintaining their own.

If your audience is reachable and your product is worth supporting for the long term, direct distribution gives you margin, customer ownership, and control of your roadmap. If you would find a topic like this useful in more depth, send us your feedback — reader questions shape what we write next.