Selling a macOS app outside the App Store is easy. Licensing is the hard part.

A lot of indie macOS developers eventually ask the same question:

“Should I sell through the Mac App Store, or sell directly?”

Selling directly sounds simple at first.

You add Stripe, Paddle, Lemon Squeezy, Gumroad, Polar, or another payment provider.

You create a checkout page.

Someone pays.

You send them a license key.

Done.

Except not really.

The payment is usually the easiest part.

The hard part is everything that happens after the payment.

You need to know:

• Is this license active?


• Is it a lifetime license or a subscription?


• Has the subscription renewed?


• Was the payment refunded?


• How many devices can this license activate?


• Can the app work offline?


• What happens if the customer upgrades?


• What happens if they lose their key?


• Can they manage their own license?


• Can you see which licenses are actually being used?

Most payment platforms are payment-first.

That makes sense. Their main job is checkout, tax, invoices, subscriptions, merchant of record workflows, and payment operations.

But for a desktop app, especially a macOS app sold outside the App Store, licensing becomes its own product surface.

A basic license key field is not always enough.

For a serious direct-sale macOS app, the licensing layer usually needs:

• License key generation


• In-app validation


• Device activation


• Device limits


• Offline access


• Subscription-based access


• Lifetime access


• Trials


• Free tiers


• Upgrade flows


• Renewal handling


• Refund handling


• Customer self-service


• License analytics


• A native Swift SDK

A lot of developers solve this by building their own license server.

That works, but it also means maintaining webhook logic, access states, activation rules, customer support tools, edge cases, and SDK code forever.

The other option is to depend fully on your payment provider’s licensing features.

That can also work, but licensing is usually not the main product. It is often an extra feature attached to the payment platform.

This is the gap I’m working on with Keylight.

Keylight is a license-first backend for macOS apps sold outside the App Store.

The idea is simple:

Use the payment provider you want.

Use Keylight for the licensing layer.

Keylight handles license issuing, activations, access validation, subscription and lifetime licenses, renewals, upgrades, customer portal flows, offline fallback, analytics, and Swift SDK integration.

The goal is not to replace Stripe, Paddle, Lemon Squeezy, Gumroad, or Polar.

The goal is to handle what happens after checkout, inside the app.

I’m building it mainly for indie macOS developers who want to sell directly, keep more control, and avoid spending weeks building licensing infrastructure from scratch.

Curious how other macOS devs are handling this today.

Are you using Paddle, Lemon Squeezy, Stripe, Gumroad, Polar, or your own custom license server?

Keylight: https://keylight.dev