Shipping a Mac app outside the App Store: the boring parts matter more than the checkout

I’ve been spending a lot of time on direct distribution for Mac apps recently, and one thing became pretty clear:

selling outside the App Store is not really about “adding Stripe”.

That part is easy.

The real work is everything around it.

The basic checklist looks something like this:

  1. Sign the app with a Developer ID certificate
  2. Notarize it
  3. Staple the notarization ticket
  4. Ship a DMG or ZIP from your own site
  5. Handle payments
  6. Issue licenses
  7. Let the app verify those licenses
  8. Support trials, renewals, refunds, device limits, and reinstall cases

The first few steps are annoying, but at least they are mostly one-time release pipeline work.

The licensing part is where it starts to grow.

If you sell through the App Store, Apple quietly handles a lot through receipts. When you sell directly, you suddenly need to answer questions like:

  • is this customer paid?
  • can this license work on this Mac?
  • how many devices are already activated?
  • what happens when they reinstall macOS?
  • what happens if Stripe is down?
  • what happens if the customer is offline?
  • how do you revoke after a refund?
  • how do you handle a trial without building a second system?

The mistake I made at first was thinking of license keys as just strings.

But for a desktop app, especially a Mac app, I think the better model is a signed entitlement.

The server signs a small license document. The app ships with the public key. On launch, it can verify the license locally, without asking your server every time.

That gives you offline launches, which matter more than I expected.

People open Mac apps on planes, trains, bad hotel Wi-Fi, corporate networks, or just when your own backend is having a bad day. Blocking launch on a network request is a pretty bad user experience for someone who already paid.

The tradeoff is revocation.

A fully offline check cannot instantly know that someone refunded or charged back. So the practical model is offline-first, not offline-only:

  • verify locally on launch
  • let the user in immediately if the signed license is valid
  • re-check with the server periodically in the background
  • pick up revocations, subscription changes, and device state when online

That feels like the right default for desktop software to me.

You get reliability for honest customers, and you still have a way to clean up revoked access later.

I ended up building this into Keylight because I got tired of rebuilding the same boring licensing layer for Mac apps: trials, signed licenses, device activations, offline grace, Stripe events, renewals, refunds, all of it.

Not posting this as “everyone should leave the App Store”. For some apps, the App Store is still the right move.

But if you are building a pro tool, developer tool, niche utility, or anything where you already know how to reach your customers, selling directly gives you more control:

  • you own the customer relationship
  • you can offer upgrade pricing
  • you can use your own checkout
  • you are not boxed into App Store rules
  • you can support business customers better

Curious how other macOS devs here handle this.

Do you build licensing yourself, use Paddle/Lemon Squeezy/Stripe, or just stay inside the App Store to avoid the whole mess?

Posted Jun 8, 2026, 5:04 AM UTC

34
Loading comments…