Developer ID vs License Keys for Mac Apps

Developer ID and license keys are often mentioned together when people talk about selling a Mac app outside the App Store, but they do not do the same job. Developer ID helps macOS trust the app. License keys help your app trust the customer. A complete direct-sales setup needs both; the full flow is explained in how to license a macOS app outside the App Store.

Developer ID is about installation trust

Developer ID is Apple’s signing system for Mac apps distributed outside the Mac App Store. When you sign with a Developer ID Application certificate, you are proving that the build came from an identified Apple Developer account.

Notarization adds another check. You upload the signed app to Apple’s notary service, Apple scans it, and you staple the notarization ticket to the app or installer. Gatekeeper can then open the app without the alarming warnings users see for unsigned software.

That answers a distribution question: “Can this app be installed safely?”

It does not answer a commercial question: “Did this customer pay?”

License keys are about paid access

A license key is an entitlement. It says that a customer is allowed to use a product, plan, feature set, or subscription until some condition changes.

For a Mac app, the licensing layer usually handles:

• creating a key after purchase;
• validating the key inside the app;
• tracking which devices are activated;
• storing a signed local license token;
• allowing offline launches;
• revoking access after refunds or failed renewals.

That is the part Apple handles for App Store apps through receipts. If you sell directly, you need your own equivalent. The software license keys guide covers the general model.

They happen at different points in the flow

Developer ID is part of your release pipeline. Before customers download the app, you sign and notarize the build.

License keys are part of your sales and app-runtime pipeline. After a customer pays through Stripe, Paddle, Lemon Squeezy, FastSpring, Polar, or another checkout, a licensing system creates a key. When the customer opens the app, the app activates the key and stores a signed local lease.

The order looks like this:

1. Build the app.
2. Sign it with Developer ID.
3. Notarize it with Apple.
4. Sell it from your website.
5. Create a license key after payment.
6. Activate the license inside the Mac app.

Developer ID gets the app onto the Mac. License keys unlock the paid product once it is there.

What happens if you only do one of them?

If you only use Developer ID, anyone who gets a copy of the app can run the paid features. macOS may trust the binary, but your app has no idea whether the user paid.

If you only use license keys and skip Developer ID, you can technically check payment, but customers will hit scary macOS warnings during installation. That hurts trust and support before they ever reach the activation screen.

For direct Mac app sales, the professional setup is not either-or. It is Developer ID for safe distribution and license keys for paid access.

Where Keylight fits

Keylight does not replace Developer ID, code signing, or notarization. You still use Apple’s tools to ship a trusted Mac app.

Keylight replaces the licensing layer you would otherwise build yourself: key creation after payment, device activation limits, offline license validation, and refund revocation. If you are using Stripe for direct sales, Stripe webhooks for macOS license keys explains the payment handoff.