How to Sell an App Outside the App Store

Selling a Mac app outside the App Store is a well-trodden path — many of the best-known macOS apps are sold directly, and have been for years. But Apple handles a lot quietly when you ship through the store, and direct distribution means taking that work back. This playbook covers every piece: why to do it, how to distribute legally, how to take payment, and how to license the app so it stays paid.

Why sell outside the App Store

The headline reason is economics. The Mac App Store takes 15% from developers in the Small Business Program and 30% from everyone else. Selling directly, your costs are Stripe’s processing fee — roughly 2.9% + $0.30 (US card pricing; rates vary by country, card type, and Stripe products used) — plus a small licensing cost. On a $49 app that is a difference of several dollars per sale that stays with you.

The deeper reason is ownership of the customer. Through the App Store, Apple holds the relationship: you get a sale notification, not an email address. You cannot contact buyers about a major update, run a win-back campaign, offer a targeted discount, or migrate them to a new pricing model. Selling directly through Stripe, the customer record is yours — email, billing history, subscription status — and you can build an actual relationship with the people who use your software.

Direct distribution also gives you control over the roadmap. No review delays on a critical bug fix, no policy change that forces a business-model rewrite, no rejection over a feature Apple dislikes. You ship when your build is ready.

The honest tradeoffs: you lose App Store discovery and must do all your own marketing, you handle your own support and refunds, and you must build licensing — the function Apple performs invisibly through receipt validation. For focused tools with an identifiable audience — developer tools, creative and productivity software, niche utilities — those tradeoffs are usually worth it. For an app that depends entirely on store browsing for discovery, they may not be.

Distributing a Mac app legally

Selling outside the App Store does not mean sidestepping Apple’s security model. macOS will refuse to cleanly open an app that is not properly signed and notarized, and users will see scary warnings. Two requirements matter.

Developer ID signing. You sign the app with a Developer ID Application certificate from your Apple Developer account (the same $99/year membership). This proves the app comes from an identified developer.

Notarization. You upload the signed build to Apple’s notary service, which scans it for malware and returns a ticket. You then “staple” that ticket to the app. A notarized app opens without Gatekeeper warnings; an un-notarized one is effectively unusable for non-technical customers.

This is a build-pipeline step, not an ongoing burden — xcrun notarytool and stapler are scriptable into your release process. Once it works, it keeps working. You distribute the resulting app as a DMG or ZIP downloaded from your own site.

Taking payment

With distribution solved, you need to collect money. The practical choice is between a payment processor and a merchant of record.

A payment processor — Stripe is the standard — charges cards and deposits funds in your account. You are the legal seller. You own the customer data. You handle sales-tax compliance yourself, either by adding Stripe Tax (about 0.5% of the transaction) or a third-party tool.

A merchant of record — Paddle, Lemon Squeezy, Gumroad — is the legal seller on your behalf. It charges a higher fee (around 5%) but handles global sales-tax and VAT compliance for you, and owns the customer relationship.

For most developers selling directly, Stripe plus a tax tool wins on both cost and customer ownership — the very things you left the App Store to gain. The Stripe vs Paddle comparison works through this decision in detail. If global tax compliance genuinely keeps you up at night and you would rather pay to never think about it, a merchant of record is a defensible choice.

This guide assumes Stripe from here, because it pairs cleanly with proper licensing.

Licensing the app

This is the part Apple was doing for you. Inside the App Store, the receipt is the license — the app validates a receipt with Apple and unlocks. Remove the store and you need an independent equivalent.

A complete licensing system for a direct-sold Mac app has five parts:

1. Key issuance — minting a unique license when a payment completes.
2. Cryptographic signing — signing the entitlement so the key cannot be forged or edited.
3. Offline verification — the app checks the key locally, so it launches without a network connection.
4. Activation tracking — enforcing how many Macs a key may run on.
5. Revocation — invalidating a key after a refund or chargeback.

You can build this yourself. The cryptography is not the hard part — it is the operational surface: the webhook handlers, the license database, the email delivery, the customer portal, the admin dashboard, all of which you then maintain forever. Most solo developers either under-build (a plain key with no offline check and no revocation) or over-build (a backend that becomes its own product).

The alternative is a licensing layer. Keylight connects to your Stripe account and turns a completed payment into a signed license automatically. When Stripe fires checkout.session.completed, Keylight mints an Ed25519-signed lease, emails it to the customer, and tracks it — no webhook code from you. Your app verifies the lease locally with a bundled public key:

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()
}

Verification is local and instant, so the app launches with no network call; revalidation and revocation are handled in the background. The offline license validation guide explains why that matters, and macOS app licensing with Stripe covers the Stripe wiring specifically.

A realistic launch checklist

Pulling it together, shipping a direct-sold Mac app looks like this:

• Build: sign with Developer ID, notarize, staple, package as a DMG.
• Site: a landing page, a download link, and a buy button.
• Payment: a Stripe account with your products and prices; add Stripe Tax when revenue makes tax obligations real.
• Licensing: a licensing layer connected to Stripe, issuing signed keys your app verifies offline.
• Trial: a built-in trial so customers can evaluate before buying.
• Support: a way for customers to retrieve keys and move them between Macs — a customer portal handles most of this without you.

None of these steps is large on its own. The one that quietly grows if you build it by hand is licensing — which is why most developers selling outside the App Store reach for a dedicated layer. Keylight plans start at $19/month with a free tier to test the full flow; see Pricing.