DEV Community: Nico

Why I Built My Own Licensing SDK Instead of Using Paddle

Nico — Sat, 27 Jun 2026 09:27:00 +0000

Originally published on the Keylight blog.

A short founder note on why Keylight exists. Every product starts as somebody's unsolved problem; this is mine, and if you are shipping a paid app you have probably run into the same one.

The problem I kept hitting

I wanted to sell a desktop app directly. Not through the App Store — directly, to customers I could actually talk to. The payment side was easy: Stripe is excellent and the decision took an afternoon.

Then I got to licensing, and everything slowed down.

Stripe takes the money. It does not give you a license key. It does not sign anything your app can verify. It does not know what a device activation is. The moment a customer has paid, you are on your own: you need to mint a key, sign it so it cannot be forged, deliver it, let the app check it, track devices, and revoke it on a refund. None of that is payment processing, so none of it is in Stripe.

So I looked at the platforms that do bundle licensing.

Why the merchant-of-record platforms did not fit

Paddle, Gumroad, and Lemon Squeezy all advertise license keys. I looked hard at each, and the same three problems came up.

The fee. As merchants of record they charge around 5%, against Stripe's ~2.9%. On every sale, forever. Reasonable if it solved my problem well — but it did not.

Offline validation. This was the dealbreaker. Their licensing is built around an online validation API: to check a key, the app calls the platform's server. My app is a desktop app, and desktop apps run on planes, behind firewalls, and offline. An online-only check leaves no good option. Fail closed — refuse to run without a server response — and a paying customer who is simply offline cannot use what they bought. Fail open — keep running when the server is unreachable — and the check is trivially bypassed: block the app's network access and it can never re-check the license or learn it was revoked. The app never actually verifies anything itself; it only knows what the server last told it. I wanted keys the app could verify locally and cryptographically — confirm a license is genuine with no server call, while revocation still lands on a periodic re-check. That is not what these platforms are built for.

Lock-in. Their license keys are tied to their platform. The customer relationship is tied to their platform. If I ever wanted to leave, I would be re-issuing every license and renegotiating my own customer data. I did not want to start a multi-year product on a foundation I could not walk away from.

None of these platforms is bad. They are just built for selling digital goods broadly, not for licensing a desktop app that has to work offline and outlive any one vendor.

And then Paddle proved the point

Since I made this call, Paddle went and did the exact thing I was afraid of. Paddle Classic — the version with built-in license keys and the Mac licensing framework — is being wound down, and Paddle Billing, the platform everyone is now pushed onto, doesn't generate license keys or handle Mac trials and licensing at all. Paddle-led fulfillment, license keys included, simply wasn't carried forward. (Paddle's own migration docs spell it out, and there's a help page literally titled "What happens when the v3 Mac SDK is no longer updated?".)

Read that again: every developer who built their licensing on Paddle now has to tear it out and migrate to something else — not because they did anything wrong, but because the platform deprecated the layer underneath them. That is the precise failure mode that made me want to own this part of my stack. When licensing lives in signed keys your app verifies itself, on your own Stripe account, a vendor sunsetting a product is an inconvenience — not a forced migration of your entire customer base.

What I actually wanted

Stripped down, my requirements were small:

Keep my own Stripe account — my customers, my data, my standard rate.
License keys that are cryptographically signed, so they cannot be forged or edited.
Offline verification — the app checks the key locally, no network call to launch.
Device activation limits, so one key is not a master key.
Automatic revocation when Stripe processes a refund.
An integration small enough to add in an afternoon, not a sprint.

That list is not exotic. It is just the licensing layer — the piece that belongs between Stripe and the app, that nobody was selling as its own thing.

So I built the layer

Keylight is that layer. It connects to your own Stripe account. When a payment completes, it mints an Ed25519-signed license lease and delivers it. Your app ships with a public key and verifies the lease locally — offline, instantly. Refunds revoke the license automatically. Device limits are enforced per machine. The whole client side is a manager and a state switch:

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: "support@acme.example.com", tintColor: .blue)
)

await licensing.checkOnLaunch()

switch licensing.state {
case .licensed:     enablePaidFeatures()
case .trial(let d): showTrialBanner(daysLeft: d)
case .expired:      showRenewalPrompt()
case .invalid:      showActivationSheet()
}

The positioning is deliberate and narrow: use Stripe for payments, use Keylight for licensing. Keylight is not a Stripe competitor and not a merchant of record. It is the missing layer — the one I went looking for, did not find, and decided to build. What began as a Swift SDK is cross-platform now — Rust and JavaScript/TypeScript too — but the model never changed: signed leases your app verifies offline, on your own Stripe.

If you are weighing the same decision, the Paddle alternative page lays out the comparison in full. And if your licensing story took a different turn than mine, I would genuinely like to hear it — send us your feedback.

FAQ

Why build a licensing SDK instead of using Paddle?

Merchant-of-record platforms bundle licensing into their fee, but their license handling is platform-tied and weak on offline validation. A dedicated layer on Stripe gives lower fees, customer ownership, and proper offline keys.

What is wrong with licensing from Gumroad or Lemon Squeezy?

Their license keys are tied to the platform and built around an online validation API. For a desktop app that must launch offline, that is the wrong model, and the keys are not portable if you leave.

What does Keylight do differently?

Keylight sits on top of your own Stripe account and issues Ed25519-signed license leases your app verifies offline, with device activation limits and automatic revocation on refund.

Migrate License Keys Without Breaking Existing Customers

Nico — Sat, 27 Jun 2026 09:26:56 +0000

Originally published on the Keylight blog.

The thing that stops developers from moving their licensing isn't the work. It's the fear of one specific moment: a paying customer opens the app after you've switched, and it tells them they're unlicensed. That's the nightmare — you reach for lower fees and customer ownership, and the bill comes due as a wave of "I already paid for this" support tickets.

It's a reasonable fear, and it's also avoidable. Migrating onto Keylight doesn't require invalidating anything, re-issuing anything, or asking customers to do anything. This post is about the one rule that keeps everyone working, the two situations you might be in, and why a scary-sounding "major version" jump changes none of it. When you're ready for the click-by-click mechanics, the companion piece covers them: How to Import an Existing Customer Base into Keylight.

Why migrating licensing feels risky

A license check is binary in the moment a customer experiences it: the app either lets them in or it doesn't. So any change to the system behind that check feels like it's playing with a live wire. Switch the layer that answers "is this person allowed in," the thinking goes, and you risk every existing customer getting the wrong answer at once.

That instinct is right about the stakes and wrong about the mechanism. The wave of lockouts people picture comes from one specific mistake: treating migration as a cutover, where the old keys stop being recognized the instant the new system goes live. If your migration invalidates the old keys, yes — everyone breaks. The entire trick is to not do that.

The one rule: old keys stay valid

Here's the rule the whole migration hangs on: you bring your customers' keys in as they are, and nothing gets invalidated.

When you import an existing customer, their license is a live, active record from the first second. If you include the key string they already have, that key is what Keylight stores — not a replacement. So when your new build asks Keylight "is this key good," the answer is yes, because it's the same key, now on a system that recognizes it. The customer never repurchases and never loses access — though how that key first reaches Keylight (your app reads it, or the customer enters it once) deserves its own section, below.

This is also why running both systems in parallel for a little while is the safe play, not a hedge. Keep your old checkout and verification alive for a few weeks while customers drift onto the new build, then retire the old path once it's quiet. There's no single instant where everything has to flip. Migrations break when someone tries to flip everything at once; they're uneventful when the old keys keep working the whole way through.

From your app's side, an imported key needs no special handling. It resolves to the same state a freshly minted key would:

// Once a key has been activated once, an imported license validates exactly
// like one you minted by hand — there is no "migrated" branch in your launch
// logic. checkOnLaunch() reads the cached, locally-verified lease and maps it.
switch await licenseManager.checkOnLaunch() {
case .licensed:
    // The customer's existing key resolved to an active lease.
    // Show the full app. Imported or not, this looks identical.
    showMainWindow()
case .limited:
    // A lapsed subscription with fallback access — renew prompt, keep
    // export available. Not relevant to most one-time-license imports.
    showRenewBanner()
case .invalid:
    // No license stored, or verification failed. New users land here.
    showActivationSheet()
default:
    break
}

There's no case .migrated. Provenance lives in your dashboard, not in your app's control flow — the SDK has nothing to special-case, because an imported active license is an active license.

How your app picks up the existing key

This is the honest crux, and the question that decides whether the migration is invisible or merely painless: a customer who bought before Keylight existed has no Keylight lease on their machine — no Keychain entry, no signed token, nothing to find. The lease that proves entitlement gets created the first time their key is activated against Keylight. Import seeds the record on Keylight's servers; it never reaches onto the customer's device. So something has to hand the key to Keylight once. There are three ways, and they differ only in how much you do.

1. The customer enters their key once — you write no migration code. Ship your new build with the activation UI you already integrated (LicensePromptView). A returning customer who isn't activated yet sees the prompt, pastes the key they already own, and it validates immediately — because you imported it. One paste, no purchase. This is the floor: it always works and costs you nothing.

2. Your app reads the old key and activates it silently — a few lines of your code. If your previous system stored the raw key somewhere your new build can read — UserDefaults, a plist, its own Keychain item — read it on first launch and call manager.activate(key:) yourself. The customer sees nothing at all:

// One-time migration shim. If this install has no Keylight license yet, read
// the key your OLD system stored and activate it. After this, the cached lease
// drives every launch.
if case .licensed = manager.licenseState {
    // already migrated — nothing to do
} else if let legacyKey = UserDefaults.standard.string(forKey: "licenseKey") {
    // ^ YOUR previous storage — NOT a KeylightSDK call. Swap in your own read
    //   (plist, a file, your old Keychain item). Only your app knows where the
    //   legacy key lived; the SDK can't, so there's no helper for this part.
    try? await manager.activate(key: legacyKey)   // ← this IS the SDK call
}

That UserDefaults read is a stand-in for your old storage — it is not a KeylightSDK call, and Keylight can't ship one, because only you know where the key lived or whether it's recoverable at all. The only SDK call here is manager.activate(key:). Two things have to be true for this path: the old key is readable on the device, and you imported with that same key string (the license_key column) so the server record matches. When they are, the migration is genuinely invisible.

3. Keylight's hosted claim page — no app code at all. Turn on Claim a legacy key and customers prove ownership of their old key at a Keylight-hosted portal page; Keylight mints a license and emails it, white-labeled. You write nothing in the app. The tradeoff: it mints a fresh key rather than preserving the old string, and it's customer-driven — a good fit for a frozen app whose key you can't read anyway.

The takeaway for the nervous developer: none of this requires you to write code for the migration to work. Routes 1 and 3 are zero app code. You only reach for the shim in Route 2 when you want the customer to notice nothing whatsoever — and even then it's a few lines against a key you've already preserved.

Two paths — pick yours

There are two situations a developer is usually in when they migrate, and they call for different moves. The good news is that both are safe; they're just safe for different reasons.

Your old app can't ship an update. Maybe it's a frozen build you no longer maintain, or it can't be resubmitted, or there's simply no v-next on the way. Here's the freeing part: nothing you do in Keylight can break it, because that old build runs its own licensing and never calls Keylight at all. So you import those customers not to keep the old app alive — it's already fine on its own — but to make them reachable. Once they're in Keylight, the customer portal can offer them the move to a new version, and the old build keeps running untouched until each customer upgrades or drifts away on their own schedule.

Your app is shipping a new version. This is the more common case: v-next is going out, and you want existing customers to keep working when they update. You import their keys as they are, and those keys validate in the new build immediately — no re-issuing, no re-delivery. Whether the customer enters that key once or your app reads it for them (the section above) is your call; either way the key they've always had is the one that works.

Both paths share the same backbone — import as-is, invalidate nothing — they just differ in whether the old binary is part of the picture at all. If you're unsure which is yours, the migration overview walks the decision, including the messier cases (missing key strings, very large bases) where emailing us first is the right call.

Shipping a major version (v1 → v15)

A version number does a lot of psychological work here. "I'm going from v1 to v15" sounds like the kind of leap that breaks things. It doesn't, and seeing why makes the whole migration feel less fragile.

Say you've sold v1 through v14 over the years and v15 is the build that adopts Keylight. The sequence:

Import the old keys. Upload your customer list as a CSV; every imported license is tagged Migrated so you can see your backlog at a glance. The keys are live immediately.
Offer the upgrade. Attach an upgrade to your v15 key type. An upgrade swaps the key type in place and keeps the same key string — a customer's v1 key simply becomes a v15 key, with v15's entitlements and limits. They are not handed a brand-new key to install.
Let the old versions fade. They keep running on their own; customers come over on their own schedule, and you're not chasing anyone.

The gap between "1" and "15" never matters, because at no point is a key replaced or revoked out from under a customer. The number is just a label on the product; the key is the thing that has to keep working, and it does.

"Migrated" is provenance, not a downgrade

One last thing worth defusing, because it trips people up: the Migrated label is not a penalty box.

It's tempting to read it as a second-class status — a license that's "only sort of" active, or one the customer has to do something to fully claim. It isn't either. Migrated records where a license came from, full stop. It's a neutral gray pill in your dashboard so you can tell your imported backlog apart from licenses sold natively through Keylight. It imposes no restriction on the customer, expires nothing, and changes no entitlement. A migrated license and a native one are the same kind of object; one just carries a note about its origin.

That's deliberate. We don't auto-remint imported customers or force any change on them, precisely because the whole promise of this migration is "your customers keep what they have." A flag that quietly downgraded them would break that promise. It doesn't.

Where to go next

If this is the reassurance you were after and you're ready to actually do it, the mechanics — CSV columns, the preview-and-confirm flow, when keys are preserved — are in How to Import an Existing Customer Base into Keylight and the migration hub. For the deciding-to-switch view, including the tax-versus-fees tradeoff if you're leaving a merchant of record, see Migrating Your App's Licensing to Keylight.

Still not sure your situation is safe? Tell us what you're migrating from and we'll talk it through — send us your feedback and we read everything. Keylight starts at $19/month with a free tier, so you can import your base and keep your current setup running alongside it. Full details on Pricing.

FAQ

Will my customers' apps stop working when I migrate?

Not if you import their keys as they are. An imported license is active immediately and validates exactly like a key you minted by hand. Your app activates that key once — the customer enters it, or your code reads it from your old storage — and from then on it works offline like any other license. A customer who never updates isn't affected at all, because their old build doesn't talk to Keylight.

Do I have to re-issue everyone a new key?

No. If you still have the plaintext key strings, you import them and every customer keeps the exact key they already have. You only generate new keys for customers whose original key you no longer hold.

What if my old app can't ship an update?

Then nothing you do in Keylight can break it — the old build runs its own validation and never calls Keylight. You import those customers so the portal can offer them your new version, and the old build keeps running on its own until they move.

One-Time vs Subscription Licensing: Which to Use?

Nico — Sat, 27 Jun 2026 09:26:51 +0000

Originally published on the Keylight blog.

"Should I charge once or charge monthly?" is one of the first real decisions an indie app faces, and it is usually answered by copying whoever the founder admires rather than by what fits the product. Both models are legitimate. This post lays out when each one actually makes sense, the honest tradeoffs, and how Keylight models perpetual keys and renewing subscriptions so the licensing follows your pricing instead of constraining it.

The two models, defined

A one-time (perpetual) license is a single payment for a license that does not expire. The customer owns that version — and usually some agreed window of updates — forever. Think of the classic "buy version 3, use it as long as you like" desktop app.

A subscription license is a recurring payment for continued access. The license is valid while the customer keeps paying; stop paying and access ends or degrades. The recurring revenue funds ongoing development and any server-side costs the app carries.

The distinction is not about the dollar amount — it is about what the customer is buying: ownership of a thing, or ongoing access to a service. Get that framing right and the model usually picks itself.

When a one-time license is the right call

A perpetual license fits when your app is a tool the customer owns and runs locally, with low ongoing cost to you per user. A focused Mac utility, an audio plugin, a developer tool that does its job on the user's machine — these have little marginal server cost, so charging rent for access is hard to justify and customers feel it.

One-time pricing also builds trust. There is no metering, no "what happens if I stop paying," no fear of being locked out of work they already did. For tools people depend on, that ownership feeling is a genuine selling point, and it is exactly the kind of no-value-extraction stance that earns goodwill with developers and power users.

The tradeoff is honest: revenue is lumpy and front-loaded. You get paid once per customer, so growth depends on continually reaching new buyers, and a quiet month is a lean month. The usual answer is paid major upgrades — version 4 is a new purchase — which we will come back to.

When a subscription is the right call

A subscription fits when your app is genuinely a service, not just a binary. If you run sync infrastructure, host an API, ship inference that costs you per call, or provide content and models that need continuous updates, those costs recur — so the revenue should too. Charging once for a product that costs you every month to keep running is how indie apps quietly go underwater.

Subscriptions also suit apps under continuous, fast development, where customers are paying for an evolving product rather than a fixed version. The recurring revenue is what lets a solo developer keep working on it full-time.

The tradeoff, again honestly: subscriptions ask more of the customer and carry an implicit promise. People resist renting software that feels like it should be owned, and a subscription obligates you to keep delivering — let development stall and churn follows fast. Subscribe-to-use should map to a real, ongoing service. If you are reaching for a subscription only because the recurring revenue looks nicer on a chart, that is the SaaS playbook pointed at a product that does not need it, and customers can tell.

How Keylight models each

The point of a good licensing layer is that it expresses your pricing rather than dictating it. Both models are the same signed lease with a different expiry.

A perpetual license is a lease with expiresAt set to null. It verifies offline forever; nothing time-bound ever ends it. The only thing that revokes it is an explicit action — most often a refund, which marks the key revoked so the app rejects it on the next revalidation. This is the model behind perpetual licenses.

A subscription license is a lease whose expiresAt is tied to the Stripe billing period. When Stripe reports a renewal, Keylight reissues the lease with a later expiry; the app picks up the extension on its next revalidation. If the subscription lapses, the lease simply expires — and Keylight's default is to drop the customer to a free or expired state, not to hard-lock the app, so a failed card does not lock someone out of their own work mid-task.

Because both are just leases, switching models or running both is a configuration choice, not a re-architecture. Your app reads the same license state machine either way.

The hybrid most indie apps actually want

In practice many indie apps want neither pure model — they want a perpetual license with a bounded updates window. The customer pays once, owns the version they bought forever, and gets updates for, say, a year; after that the app keeps working indefinitely, but new versions are a fresh purchase. It is the "fair perpetual" model: customers are never locked out of what they paid for, and you still have a recurring reason for them to pay again.

This maps cleanly onto leases. The perpetual entitlement never expires; the updates window is its own expiry your app checks before offering a newer build. The customer's app never stops working — only the "free updates" entitlement lapses. You get a renewal motion without the rented-software resentment a hard subscription can create. For a deeper treatment of the subscription mechanics specifically — renewals, upgrades, and downgrades — see subscription licensing for Mac apps.

There is no universally correct answer, only a fit. Own-it tools lean one-time; real services lean subscription; a lot of indie apps are happiest in the fair-perpetual middle. Decide based on what the customer is actually buying and what the app costs you to run — and let the licensing layer express that decision rather than push you toward whichever model bills more. If you are weighing this for your own app, send us your feedback and we'll think it through with you.

FAQ

Is a one-time license or a subscription better for an indie app?

Neither is universally better. One-time fits focused tools customers buy and own; subscriptions fit apps with ongoing server costs or continuous development. Many indie apps land on a hybrid: a perpetual license with a bounded window of free updates.

How does Keylight model a perpetual license?

As a lease with no expiry — the expiresAt field is null. The signed lease verifies offline forever; the only thing that ends it is an explicit revocation, such as after a refund.

How does Keylight model a subscription?

The lease carries an expiry tied to the Stripe subscription period. On renewal the lease is reissued with a later expiry; if the subscription lapses, the lease expires and the app moves to an expired or free state rather than hard-locking.

Stripe vs Paddle vs Lemon Squeezy for Indie Developers

Nico — Sat, 27 Jun 2026 09:26:46 +0000

Originally published on the Keylight blog.

If you are an indie developer about to charge for an app, you have three names in front of you: Stripe, Paddle, and Lemon Squeezy. They get discussed as if they are the same kind of choice. They are not. This post lays out the real differences so you can pick deliberately.

They are not the same kind of thing

The single most important distinction is processor versus merchant of record.

Stripe is a payment processor. It moves money from your customer's card to your bank account. You are the legal seller. The customer relationship, and the sales-tax liability, are yours.

Paddle and Lemon Squeezy are merchants of record. They are the legal seller of your product. The customer's receipt comes from them. They calculate, collect, and remit sales tax and VAT worldwide, then pay you the remainder. You are, in effect, a supplier selling through their storefront.

Everything else — fees, customer ownership, lock-in — flows from this one difference.

Fees

Stripe: about 2.9% + $0.30 per card charge (US card pricing; rates vary by country, card type, and Stripe products used). On a $49 sale, roughly $1.72.

Paddle: approximately 5% plus the underlying payment fee. On that $49 sale, closer to $2.45-$2.75.

Lemon Squeezy: 5% + $0.50 per transaction. On $49, roughly $2.95.

Stripe is plainly the cheapest on raw processing. But the merchant-of-record fee is not pure overhead — it is buying tax compliance. To compare honestly, you have to price that in.

Tax compliance: the real tradeoff

Paddle and Lemon Squeezy handle sales tax and VAT for you, everywhere. If you sell to a customer in Germany, Australia, or California, they apply the right rate, collect it, and remit it. You never think about it.

With Stripe, that is your responsibility. The practical answer is Stripe Tax — built into Stripe Checkout, about 0.5% of the transaction — or a third-party tool like Quaderno or TaxJar. These work well, but they require setup and occasional maintenance as rules change.

So the fair comparison is not 2.9% vs 5%. It is roughly 2.9% + 0.5% tax + a small licensing cost for the Stripe path, versus ~5% all-in for a merchant of record. At meaningful revenue the Stripe path is still cheaper — and below tax thresholds, cheaper still. But it is not hands-off the way a merchant of record is.

Customer ownership

With Stripe you own the customer: email, billing history, subscription status, all exportable. You can email customers, run win-back campaigns, and migrate processors if you ever need to.

With Paddle or Lemon Squeezy, the customer is theirs. Your invoice shows their name. How much customer data flows back to you is governed by their terms, and those terms can change. Migrating away later is a renegotiation, not an export.

For a product you plan to support for years, an owned customer list is a genuine business asset. For a first product or a small catalogue, the difference matters less.

Licensing is a separate question

Here is the part the comparison usually misses: none of these three issues license keys in the sense a desktop app needs.

A desktop app needs a key it can verify offline — a cryptographically signed entitlement, checked locally with no server call. Stripe has nothing for this; it is a payment processor and stops at the payment. Paddle and Lemon Squeezy each have a license-key feature, but it is tied to their platform and oriented around an online validation API, not offline signature verification.

So whichever of the three you choose for payments, licensing is a separate layer. The clean architecture is: a processor for payments, and a licensing layer for keys, connected by webhooks. In code, the licensing half looks the same regardless:

import KeylightSDK

await licensing.checkOnLaunch()

switch licensing.state {
case .licensed:    enablePaidFeatures()
case .trial(let d): showTrialBanner(daysLeft: d)
case .expired:     showRenewalPrompt()
case .invalid:     showActivationSheet()
}

Which to choose

Choose Stripe if you want the lowest fees, full customer ownership, and you are willing to add a tax tool. At any meaningful revenue this is the strongest long-term position. Pair it with a licensing layer for keys.

Choose Paddle or Lemon Squeezy if you want the simplest possible setup, you sell globally from day one, and you genuinely do not want to think about tax. You pay more and give up the customer list in exchange for never handling compliance. Between the two, Lemon Squeezy leans toward a friendlier indie experience; Paddle toward more established tooling.

For most indie developers building a paid app to support for years, Stripe plus a licensing layer wins. For a first product where simplicity beats everything, a merchant of record is a defensible call. If you would like a deeper comparison on any one of these, send us your feedback.

FAQ

Which is cheapest: Stripe, Paddle, or Lemon Squeezy?

Stripe has the lowest processing fee at about 2.9% + $0.30. Paddle and Lemon Squeezy charge around 5% because their fee bundles global tax compliance. Adding a tax tool to Stripe usually still totals less.

What is the difference between a payment processor and a merchant of record?

A payment processor like Stripe moves money while you remain the legal seller. A merchant of record like Paddle or Lemon Squeezy is the legal seller, assuming sales tax and VAT liability on your behalf.

Do any of them handle license keys?

None of them issue cryptographically signed license keys an app verifies offline. Paddle and Lemon Squeezy offer platform-tied key APIs; Stripe has none. Licensing is a separate layer.

Licensing a Cross-Platform App from One Control Plane

Nico — Sat, 27 Jun 2026 09:26:42 +0000

Originally published on the Keylight blog.

If you ship the same product on more than one platform — a native Mac build, an Electron or Tauri desktop app, a Rust CLI — the licensing question is not "how do I license each one?" It is "how do I license all of them without running three disconnected systems?" The answer is a single control plane: one tenant that owns your customers, keys, and device limits, with thin SDKs in each app that all read the same signed lease. This post is the build guide for that setup.

What "one control plane" means

A control plane is the place the licensing truth lives. With Keylight it is your tenant: one account that holds every customer record, every license key, the activation count and limit on each key, the entitlements each key grants, and the Stripe connection that mints keys on purchase. The dashboard, the revocation controls, the activation resets — all of it operates on that one set of records.

The SDKs are deliberately not the control plane. They are clients. Each one does the same three things in its own language: exchange a key for a signed lease, verify that lease locally, and read entitlements from it. None of them holds authority over whether a license is valid — they verify a document the control plane signed. That separation is the whole point. It means a customer who buys once exists once, and a device limit of three means three devices total, not three per platform.

This is the universal licensing layer idea made concrete: licensing is infrastructure you configure once, not a backend you rebuild per app.

One lease format, every SDK

What makes a single control plane work across languages is that the lease format is shared. A Keylight lease is an Ed25519-signed document with a fixed wire format. Signing happens once, server-side; every SDK reconstructs and verifies that same format against the tenant's public keys. The Swift SDK and the Rust crate are not two implementations of "a license" — they are two readers of one signed artifact.

The practical consequence: the SDKs are at parity by construction. The same license states exist everywhere — Licensed, Trial, Limited, FreeTier, Expired, Invalid — because they are derived from the same lease fields. hasEntitlement("pro") means the identical thing in Swift, JavaScript, and Rust, because all three are checking the same signed entitlements field. For the field-by-field anatomy of that shared document, see what is inside a Keylight lease.

Wiring every SDK to one tenant

Here is the same product, configured against one tenant in each of Keylight's SDKs. Notice that the tenantId and productId are identical in every one — that is what binds them to the same control plane.

The native Mac build, in Swift, via the Keylight.manager factory:

let licensing = try Keylight.manager(
    sdkKey: "sdk_live_…",
    tenantId: "your-tenant",
    productId: "your-product",
    keyPrefix: "PROD",
    trustedPublicKeyBase64: "<tenant public key>",
    trialDurationDays: 14,
    branding: .init(
        appName: "My App",
        purchaseURL: URL(string: "https://example.com/buy")!,
        supportEmail: "support@example.com",
        tintColor: .accentColor
    )
)

A Tauri desktop build, registered in the Rust core:

use keylight::KeylightConfig;

let cfg = KeylightConfig::builder("your-tenant", "your-product", "sdk_live_…").build();
tauri::Builder::default()
    .plugin(tauri_plugin_keylight::init(cfg));

A Rust CLI or a non-Tauri Rust app, using the crate directly:

use keylight::{Keylight, KeylightConfig};

let cfg = KeylightConfig::builder("your-tenant", "your-product", "sdk_live_…").build();
let kl = Keylight::new(cfg)?;
let res = kl.activate("USER-LICENSE-KEY")?;

And an Electron build, with the JavaScript SDK in the main process:

const kl = new Keylight({
  tenantId: "your-tenant",
  productId: "your-product",
});

Four apps, one tenant. A customer's key activates on their Mac app and their CLI, and both activations count against the same limit. Revoke that key once in the dashboard and every app rejects it on the next revalidation. There are per-platform integration walkthroughs in how to add license keys to a Swift macOS app, an Electron app, and a Tauri app.

Where this lands today, honestly

The control plane is real and shared, but it is worth being precise about what "cross-platform" covers right now rather than overselling it. The shipped SDKs are Swift (Apple platforms), JavaScript/TypeScript (web, Node, Electron, edge), Rust, and the first-party Tauri plugin. Those cover the bulk of where independent desktop apps ship today.

What this is not, yet, is a drop-in REST API you can call from any language that lacks a native SDK. Additional language SDKs are added based on real demand, not to fill a matrix. The design makes that cheap: because the lease format and the control plane are shared, a new SDK is another reader of the same document, not a new system. So the honest framing is "one control plane across the SDKs that exist" — which is most of the market — rather than "licenses any language anywhere." When you only ship on platforms with a Keylight SDK, the single-tenant model already holds end to end.

A cross-platform app does not need cross-platform licensing complexity. It needs one place the licensing truth lives and thin, identical clients in each app reading the same signed lease. Configure the tenant once, point each SDK at it, and the platform count stops being a licensing problem. If you are wiring up a stack this post does not cover, send us your feedback and we'll help.

FAQ

Can one license system cover apps written in different languages?

Yes. Keylight issues the same Ed25519-signed lease format regardless of which SDK reads it. The Swift, JavaScript, Rust, and Tauri SDKs all verify that one format, so a single tenant covers a Mac app, an Electron app, and a Rust CLI at once.

Do customers and device limits carry across platforms?

Yes — they live on the tenant, not in the SDK. A customer, their key, its activation count, and its entitlements are one record. Whichever SDK activates a device increments the same count against the same limit.

Which platforms does Keylight cover today?

Shipped SDKs are Swift (Apple), JavaScript/TypeScript (web, Node, Electron), Rust, and a first-party Tauri plugin. More language SDKs are added based on demand; the lease format and control plane are shared, so new SDKs slot into the same tenant.

Offline License Validation in Rust

Nico — Sat, 27 Jun 2026 09:26:37 +0000

Originally published on the Keylight blog.

A license check that needs a server is a license check that fails on a plane. For desktop and CLI apps that is unacceptable, so Keylight makes the license itself verifiable offline: it is an Ed25519-signed document your app checks locally with only a bundled public key. This post walks through how that works in Rust with the keylight crate — the synchronous verifier, the trusted keys, and the cached lease that keeps an app licensed without a connection.

The shape of offline validation

There are two distinct jobs in any licensing system, and the mistake most DIY implementations make is fusing them. The first job is verification: is this license genuine and unexpired? The second is revalidation: has anything changed server-side — a refund, a downgrade, a revocation — since the last time we checked?

Verification can and should be local. A Keylight lease is a small JSON document signed with Keylight's Ed25519 private key. Your app ships with the matching public key, so it can confirm the lease is authentic and untampered using only math, in microseconds, with no connection. Revalidation is the only part that needs the network, and it is periodic and can happen in the background — never on the critical path of launching the app.

Splitting them is what makes offline-first possible. The app verifies the cached lease at startup and unlocks immediately; it reaches out to revalidate only when a check is actually due. For the broader model, see how offline license validation works; for the anatomy of the signed document itself, what is inside a Keylight lease.

Setting up the keylight crate

The crate is synchronous — it uses blocking HTTP via ureq, so there is no tokio runtime to set up. Add it:

cargo add keylight

Build a config with your tenant and product IDs, pull the tenant's public keyset so leases verify offline, and create the client:

use keylight::{Keylight, KeylightConfig};

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let mut cfg = KeylightConfig::builder("your-tenant", "your-product", "sdk_live_…")
        .max_offline_days(7) // bound how long a cached lease is accepted offline
        .build();

    // Fetch the tenant's trusted Ed25519 keyset. You can also pin keys at build
    // time with .trusted_key(kid, pub_b64) if you'd rather not fetch them.
    if let Some((_, keys)) = keylight::keyset::fetch_keyset(
        &keylight::http::ureq_transport::UreqTransport::default(),
        &cfg.base_url,
        &cfg.tenant_id,
    ) {
        cfg.trusted_keys.extend(keys);
    }

    let kl = Keylight::new(cfg)?;

    // The one online step: exchange a key for a signed lease. The lease is
    // Ed25519-verified *before* it is written to disk.
    let res = kl.activate("USER-LICENSE-KEY")?;
    println!("activated: {}", res.activated);

    // From here on, gating works offline from the cached lease.
    if kl.has_entitlement("pro") {
        println!("Pro features unlocked");
    }
    Ok(())
}

activate is the only call here that touches the network. Once it succeeds, the verified lease is persisted, and everything after that — entitlement checks, state resolution — reads from the cache.

Verifying a lease with no network call

The crate exposes the verifier as a standalone function, so you can check a lease yourself — in a CLI, in your own gating logic, or server-side — without constructing a client:

use keylight::verifier::{verify_lease, SKEW_SECONDS};

let result = verify_lease(
    &lease,          // the Lease you hold
    &trusted_keys,   // HashMap<kid, base64 ed25519 public key>
    now_seconds,     // current unix time
    SKEW_SECONDS,    // 300s tolerance for clock drift
);

if result.is_trusted() && !result.expired {
    // Genuine, unexpired lease — unlock.
}

verify_lease returns a VerifyResult with three independent booleans: kid_known (the lease was signed by a key your app trusts), signature_valid (the Ed25519 signature checks out), and expired (the lease is past its expiry window, accounting for clock skew). is_trusted() is the conjunction of the first two — a lease can be authentic but expired, and the struct lets you tell those cases apart.

This is the whole offline story in one function call: no HTTP, no I/O beyond reading the lease you already have. The trust anchor is the tenant's private key staying on Keylight's servers; an attacker who extracts the public key from your binary still cannot mint a lease that signature_valid accepts.

How the client stays valid offline

In normal use you do not call verify_lease directly — the client does it for you. state() resolves the current license state with no network call, reading the cached lease and re-verifying it each time:

use keylight::LicenseState;

match kl.state() {
    LicenseState::Licensed => { /* full access */ }
    LicenseState::Trial { days_left } => println!("{days_left} days left"),
    LicenseState::Limited => { /* on the offline grace window */ }
    LicenseState::FreeTier => { /* free features only */ }
    LicenseState::Expired => { /* renew */ }
    LicenseState::Invalid => { /* prompt for a key */ }
}

The cached lease lives in a device-bound encrypted file store (ChaCha20-Poly1305), in the per-OS application data directory, so it survives restarts and is the same code path on macOS, Windows, and Linux. The encryption is a hardening measure, not the trust boundary — the Ed25519 signature is what makes the lease unforgeable. Even decrypted, a lease edited to grant more entitlements fails signature_valid and is rejected.

The max_offline_days setting is what stops a device from drifting offline forever. When set, the client refuses a cached lease whose last successful online validation is older than that window, even if the lease itself has not expired. It is the honest middle ground between fail-closed (a server call on every launch, which breaks offline use) and fail-open (a cached lease accepted indefinitely): legitimate offline use keeps working for the window you choose, and the app revalidates when it can. At launch, kl.check_on_launch() triggers that background revalidation only when one is due.

That is offline license validation in Rust end to end: one online activation, then local Ed25519 verification on every check, bounded by a grace window you control. The same crate also backs the Tauri plugin, so a Tauri app and a plain Rust binary verify leases the same way. If your Rust setup has an angle this post does not cover, send us your feedback and we'll extend it.

FAQ

Can I validate a license in Rust without a network connection?

Yes. A Keylight lease is an Ed25519-signed document. The keylight crate verifies the signature locally against the tenant's public keys with verify_lease — no HTTP call. The network is only needed for the initial activation and periodic revalidation.

Is the keylight Rust crate async?

No. It is synchronous and uses blocking HTTP via ureq, so it works in a plain Rust binary or CLI without a tokio runtime. The offline verification path makes no network call at all.

How long can a Rust app stay offline before the license stops working?

Until the lease itself expires, unless you set max_offline_days. That bounds how long the cached lease is accepted since the last successful online validation, so a device cannot stay offline indefinitely.

Tauri vs Electron for Licensed Desktop Apps

Nico — Sat, 27 Jun 2026 09:26:32 +0000

Originally published on the Keylight blog.

If you are picking between Tauri and Electron for an app you intend to sell, the licensing implications rarely make the comparison — but they should, because both frameworks have a clean place to put a license check and the choice shapes where it goes. This post covers the real differences between the two, then where verification belongs in each, and why Keylight licenses both the same way.

The actual architectural difference

Electron bundles a full Chromium runtime and a Node.js process into every app. Your UI is a web page rendered by that bundled Chromium; your backend logic runs in the Node main process. You ship the browser with the app, which is why every Electron app behaves identically everywhere — and why every Electron app is large.

Tauri takes the opposite approach to rendering: it uses the operating system's native webview (WebView2 on Windows, WebKit on macOS and Linux) instead of bundling a browser, and the app core is Rust. Your UI is still a web frontend, but the binary does not carry a browser, and your native logic is compiled Rust rather than Node.

So the headline difference is two things at once: what renders the UI (bundled Chromium vs the system webview) and what language the core is (Node vs Rust). Everything else in this comparison flows from those two facts.

Bundle size, performance, and maturity

The honest tradeoffs, without picking a side:

Bundle size and memory. Tauri wins clearly here. A minimal Tauri app is a few megabytes; a minimal Electron app is tens to over a hundred, because it ships Chromium. Tauri's use of the system webview also tends to mean lower idle memory. If download size or footprint matters to your audience, this is real.

Consistency and maturity. Electron wins here. Bundling Chromium means your app renders the same on every machine, with no surprises from an older system WebKit on someone's Linux box. Electron is also older, with a deeper ecosystem, more native modules, and more answered Stack Overflow questions. For a complex app, that maturity has value.

Language of the core. This is a preference, not a winner. Electron's core is Node, so your whole app is JavaScript/TypeScript end to end. Tauri's core is Rust, which is more to learn if you do not know it, but gives you a fast, memory-safe native layer. For licensing specifically, the Rust core turns out to be a small advantage — covered next.

Neither framework is wrong for a paid app. Tauri leans lighter and more modern; Electron leans more proven and uniform. Pick on the merits of your app; the licensing layer is good on both.

Where license verification lives in each

The one rule that matters for both frameworks: do not verify in the renderer. The renderer is a web page. A user can open DevTools, read your tenant configuration, inspect variables, and watch network traffic. License logic in the renderer is license logic the user can see and poke at. So in both frameworks the check belongs in the privileged process, with only the result crossing to the UI.

In Tauri, that privileged place is the Rust core. The Keylight plugin runs activation and verification in Rust and exposes three commands — activate, validate, hasEntitlement — to the frontend over Tauri's command bridge. The verified lease and your config never enter the webview; the frontend only ever receives booleans. Because the core is compiled Rust rather than interpreted JavaScript, it is also meaningfully harder to patch.

In Electron, that privileged place is the Node main process. The JavaScript SDK runs there, and you expose a small surface to the renderer over IPC with ipcMain.handle, bridged through a contextBridge preload. The tenant config and the verified lease stay in Node, out of the renderer's reach.

The architectures rhyme: privileged process owns the lease, UI reads the result over a bridge. Tauri's edge is that its privileged process is compiled Rust; Electron's is a Node process, which is still fully out of the renderer's reach but is interpreted rather than compiled. Neither is DRM — a determined attacker with a disassembler can patch any client — but both stop the casual abuse that a renderer-side check invites. For the limits of what client-side verification can promise, see what is inside a Keylight lease.

How Keylight licenses both

Whichever you choose, the licensing setup is the same shape because both SDKs read the same Ed25519-signed lease from the same tenant. For Tauri, register the first-party plugin in your Rust core and call its three commands from the frontend. For Electron, run the JavaScript SDK in the main process and bridge it to the renderer over IPC. Both verify the lease offline against your tenant's public keys, both gate features by entitlement, and both report activations against one device limit.

That means the framework decision and the licensing decision are independent. You can choose Tauri or Electron purely on bundle size, ecosystem, and whether you want a Rust core — and your customers, keys, and device limits live in the same control plane either way. If you later ship the same product on the other framework, or add a native Mac build, they all share that one tenant. There is more framework-specific detail on the Licensing for Tauri Apps and Licensing for Electron Apps pages.

Tauri and Electron are both solid foundations for a paid desktop app. Tauri is lighter and gives you a Rust core that is a natural home for a tamper-resistant check; Electron is more mature and keeps everything in one language while still isolating the check in the main process. Choose on your app's needs — the license layer works the same on both. If your decision hinges on something this post did not weigh, send us your feedback.

FAQ

Is Tauri or Electron better for a paid desktop app?

Both ship cross-platform paid apps fine. Tauri produces smaller, lighter binaries and gives you a Rust core that is a natural place to put tamper-sensitive license checks. Electron is more mature with a larger ecosystem and a Node main process that is equally out of reach of the UI. The licensing story is strong on both.

Where should license verification run in each framework?

Out of the renderer either way. In Tauri, verify in the Rust core via the plugin. In Electron, verify in the Node main process. Both keep your tenant config and the verified lease away from the DevTools console, with the UI reading the result over the bridge.

Does Keylight support both Tauri and Electron?

Yes. The Tauri plugin verifies in the Rust core; the JavaScript SDK runs in the Electron main process. Both read the same Ed25519-signed lease from the same tenant, so the choice of framework does not change your licensing setup.

How to Prevent License Key Sharing

Nico — Sat, 27 Jun 2026 09:26:28 +0000

Originally published on the Keylight blog.

Once an app has paying customers, one key inevitably shows up in a forum or a group chat, working for everyone who pastes it. The instinct is to clamp down hard. But aggressive anti-sharing measures hurt honest customers far more reliably than they hurt sharers. This post is about preventing key sharing in a way that does not make your real customers collateral damage.

Accept what you cannot prevent

Start with an honest premise: you cannot make key sharing impossible. A determined person with one machine can always run one legitimate-looking copy. Any scheme that claims otherwise is either lying or about to break something for paying customers.

So the goal is not "zero sharing." The goal is to make a license key behave like what it is meant to be — a license for one person and their handful of devices — rather than a master key to your product. That is an achievable, well-defined target. "Stop all piracy" is not.

The mechanism: device activation limits

The tool that actually works is the device activation limit. Each key is valid for a bounded number of devices. When the app runs on a machine for the first time, it activates: it registers that device with the licensing server, which checks the count against the limit and admits or refuses it.

Devices are recognised by a fingerprint — a stable identifier derived from the machine's hardware and install characteristics, hashed before it leaves the device so the server stores an opaque token, not a description of anyone's computer. The fingerprint's only job is equality: same device, or new device?

This is what stops the forum-posted key. The key still works — but only on the first N machines that activate it. The hundred-and-first install is refused. Sharing is capped at the limit you set, instead of being unlimited. The mechanics are covered in full in the app activation system guide.

Why hard blocks backfire

Here is where most anti-sharing schemes go wrong: they treat every ambiguous signal as guilt and respond with a hard block.

A customer reinstalls macOS and their fingerprint shifts slightly — hard block, "this license is invalid." A customer replaces a drive — hard block. A customer is the first person to legitimately install on their new laptop, but the key is at its limit because the old one was never removed — hard block.

Every one of those is a paying customer hitting a wall you built for pirates. They do not experience it as anti-piracy; they experience it as your app being broken and hostile. You will lose more goodwill from these false positives than you ever lose revenue to the actual sharers, because there are far more honest customers than dishonest ones.

The fix is two principles.

Be generous. A limit of one device is hostile — most people have a laptop and a desktop. Three to five for a personal license stops a key being shared across an organisation while being invisible to any real customer. The limit should constrain sharing, not normal multi-machine use.

Degrade gracefully. When something is ambiguous, do not hard-block. If a periodic re-check cannot reach the server, keep running on the last valid license — do not lock the customer out over your own outage. Reserve the hard "no" for the unambiguous case: a genuinely new device, genuinely past a generous limit.

Deactivation is the other half

A device limit without deactivation is a trap that springs on honest customers. People replace computers constantly. If activations only ever accumulate, every loyal customer eventually hits the limit on hardware they no longer own.

The answer is self-service deactivation: a customer portal listing the customer's activated devices, each with a remove button. Removing a device frees a slot instantly. The customer rearranges their own machines without a support ticket, and the limit stays meaningful because it is never the thing blocking a legitimate move.

In the app, hitting the limit should surface as a clear, actionable message — not a dead end:

await licensing.activate(key: enteredKey)

if case .invalid = licensing.state {
    // activationError explains the limit was reached;
    // point the customer at the portal to free a device.
    showActivationError(licensing.activationError)
}

The balance

Preventing license key sharing is a balance, not a war. A generous device limit plus painless self-service deactivation caps sharing at a reasonable number while being effectively invisible to every honest customer. A stingy one-device limit with hard blocks and no deactivation barely inconveniences a determined sharer and reliably angers the people paying you.

Aim for the first. If you have an anti-sharing edge case worth a deeper post, send us your feedback.

FAQ

How do I stop customers sharing license keys?

Bind each key to a limited number of devices with an activation limit. The licensing system records each device and refuses activations past the limit, so one key cannot supply an unlimited number of installs.

How do I avoid punishing legitimate customers with anti-sharing measures?

Set a generous device limit, make deactivation self-service so customers can move between machines, and degrade gracefully rather than hard-blocking on an ambiguous signal.

Can license key sharing ever be fully prevented?

No. One person with one device can always run one copy. The realistic goal is to make a key behave like a personal license, not a site license — which activation limits achieve.

What Is Inside a Keylight Lease: The Ed25519 Format Explained

Nico — Sat, 27 Jun 2026 09:26:23 +0000

Originally published on the Keylight blog.

Most license systems answer "is this key valid?" by asking a server. Keylight answers it with math, locally, in milliseconds — because the license itself is a signed document your app can verify without a network call. Understanding what is inside that document, and why the signature protects it, is the fastest way to understand how Keylight's security model holds together.

Why signed leases beat opaque license strings + database lookups

The classic licensing approach is a lookup: the customer enters a key, your server checks it against a database, and the server says yes or no. An opaque license string — just a token or a checksum-passing sequence — means nothing by itself. The string carries no self-describing information; the app has to phone home to learn what it is allowed to do.

A signed lease flips the model. The lease is a self-describing document: it encodes who the customer is, which product they purchased, which features they have, and when the license expires. The Ed25519 signature over the document is proof that Keylight's server minted it for exactly those values. Your app ships with the public key baked into the binary and verifies the signature locally — no server call, no round-trip, no database to query or spoof.

The customer holds the document, but they cannot change what it says. The validity no longer lives in whether a server recognizes a token; it lives in a signature only Keylight's private key can produce. This is why the lease works offline, survives network outages, and still enforces your commercial limits correctly. For a broader introduction to why this model replaced opaque license strings, see how license keys work for desktop apps.

The lease payload, field by field

The canonical lease the SDK exposes after verification looks like this:

{
  "id": "lk_01hx9z4bqncktjvx6a2r3p8wy",
  "customerId": "cus_Qk3mN9vTpLx2Zr",
  "productId": "prod_macos_pro",
  "activationLimit": 3,
  "activationCount": 1,
  "features": ["pro", "export"],
  "issuedAt": "2026-05-15T09:12:00Z",
  "expiresAt": null,
  "revoked": false,
  "sig": "MEUCIQDkP3...base64url...=="
}

Every field carries specific meaning that the SDK reads and enforces:

id — a unique, immutable lease identifier. This is what Keylight uses to look up the lease server-side during revalidation. It never changes after issuance.

customerId — the Keylight customer record this lease was issued to, set at mint time from the Stripe payment. Ties the lease to a specific purchase.

productId — which product and tier this lease covers. If you have multiple products or multiple plans, the SDK reads this to know which entitlement bucket applies.

activationLimit — the maximum number of concurrent device activations. A standard license might allow 3; an enterprise tier might allow unlimited (represented as a very high number). This value is set at issuance based on the product tier purchased.

activationCount — the current number of active devices as of the last server sync. Keylight tracks this server-side and updates it on each activation and deactivation. This is a read-only tracking field exposed to your app via the lease object; it is not checked by LeaseVerifier.verify. The activation cap is enforced server-side when a device calls /activate — the verifier only checks signature, key ID, and expiry.

features — an array of entitlement strings the app reads to decide which capabilities to unlock. Your app checks whether "pro" or "export" appears here before enabling those features. This is the mechanism that lets you sell different tiers from a single binary. The strings are stored sorted so that the client and server always reconstruct an identical payload regardless of insertion order.

issuedAt — the ISO timestamp when the lease was minted. Used internally for clock-drift calculations and audit logging.

expiresAt — null for a lifetime license; an ISO timestamp for subscription or time-limited leases. The SDK rejects a lease that has expired beyond its skew tolerance window, even if the signature is valid.

revoked — a boolean flag set to true when a refund or chargeback is processed. On the next revalidation, the SDK picks this up and transitions the app to an invalid state. Because verification is offline-first, revocation is not instantaneous — a customer with no network access keeps using their cached lease until the app revalidates. This is the honest tradeoff: instant revocation would require a server call on every launch, which breaks offline usage.

sig — the Ed25519 signature over a compact wire payload, not over the JSON above. The JSON is the lease object as the SDK exposes it to your app. Internally, signing operates on a more compact wire payload — a pipe-delimited string with eight positional fields: v3|kid|licenseKeyHash|instanceId|issuedAt|expiresAt|status|entitlements. This is what the Ed25519 signature actually covers; the SDK reconstructs and verifies that string before exposing the structured lease to your code.

The fields covered by the signature are kid, licenseKeyHash, instanceId, issuedAt (integer seconds), expiresAt (integer seconds), status, and entitlements (sorted, comma-joined). Modifying any of them produces a signature mismatch and the lease is rejected immediately. Fields like customerId, productId, activationLimit, and activationCount are part of the API/customer-facing model but are not positional fields in the signed wire payload.

For a full treatment of how offline validation uses this structure, see how offline license validation works.

How Ed25519 signing protects every field

Ed25519 is a public-key signature algorithm. The important property for licensing is this: given only the public key (which your app ships with), it is computationally infeasible to produce a valid signature. The public key can verify signatures but cannot generate them.

Keylight's servers hold the private key — it never leaves Keylight's infrastructure. Your app ships with the matching public key baked into the binary. An attacker who extracts the public key from your binary still cannot mint a valid lease: they would need the private key to produce a signature the public key accepts, and the math does not help them get there. Embedding the public key in the app is safe by design.

Why Ed25519 over RSA? Three practical reasons. Ed25519 signatures are about 88 bytes; RSA-2048 signatures are around 344 bytes. Ed25519 verification is faster — relevant when your app verifies the lease on every launch. And Ed25519 has no parameter choices that can be gotten subtly wrong the way RSA key generation can. For desktop licensing where verification happens repeatedly and binary size matters, these add up.

What tampering does in practice: the SDK reconstructs the v3 pipe-delimited string from the lease's kid, licenseKeyHash, instanceId, issuedAt, expiresAt, status, and sorted-joined entitlements fields, then calls isValidSignature against the decoded sig. If any of those eight fields was changed after signing — even one character — the reconstructed string differs from the one that was signed, the check fails, and the SDK rejects the lease. There is no partial match, no tolerance for minor edits. The lease is either intact or it is rejected.

On the wire, Keylight uses the v3 pipe-delimited format. The SDK parses that format, derives the canonical payload string, and verifies the signature before populating the structured lease object. Your code never sees the raw wire format; it only sees a verified, structured lease — or a verification failure.

What the SDK does on verification, and what it deliberately does not do

LeaseVerifier.verify is the function the SDK calls on every lease read. It is explicit about its scope. Here is what it checks:

Signature validity — reconstructs the v3 pipe-delimited payload and verifies the Ed25519 signature against the trusted public key for this tenant. A lease with a missing or empty signature is rejected immediately, before any other check.
Key ID (kid) membership — the lease carries a kid identifying which signing keypair was used. LeaseVerifier.verify looks up kid in the tenant's trusted keyset (a dictionary keyed by kid) and rejects the lease if it is absent — even if the signature itself is mathematically valid against some other key. This is how a compromised signing key gets invalidated: ship an app update that drops the compromised kid from the trusted keyset.
Expiry — checks expiresAt against the current time with a skewTolerance window (default 300 s / 5 minutes) to absorb minor clock drift. A lease past its expiry window is rejected. Callers do not need to check expiry separately; the verifier handles it.

Here is how the SDK calls this at launch:

// Inside the SDK on app launch:
let isValid = LeaseVerifier.verify(
    lease: cachedLease,
    trustedKeys: configuration.trustedPublicKeys
)

The trustedKeys argument is your configuration's trustedPublicKeys — the dictionary of kid → Curve25519.Signing.PublicKey values from your KeylightConfiguration. The function returns a plain Bool — it does not throw.

What LeaseVerifier.verify explicitly does not do is equally important to understand:

It does not enforce activation count. The activationCount field is exposed in the lease object so your app can display it, but LeaseVerifier.verify does not compare it against activationLimit. Activation enforcement happens server-side when a device calls /activate; the verifier only checks signature, kid, and expiry.

It does not protect your binary against reverse engineering. A developer with a disassembler can find LicenseManager.isEntitled and patch the branch. The SDK source is public. The signed lease stops someone from forging entitlements by editing a file; it does not stop someone from patching the binary that reads it. Keylight is a commercial licensing system, not DRM.

It does not prevent use of a valid cached lease before revocation propagates. If a customer's lease was valid at last sync and the customer has no network access, the lease remains valid locally until the app revalidates online. This is the fail-open tradeoff of offline-first verification — and it is deliberate. The alternative (fail-closed, requiring a server call on every launch) locks out legitimate customers with no internet access.

It does not protect against a compromised private key. If Keylight's private key were compromised, an attacker could mint arbitrary valid leases. The trust anchor is the private key staying on Keylight's servers. Keylight's threat model is explicit: Keylight stops casual abuse and enforces commercial limits. It is not the last line of defense against a skilled attacker, and it does not claim to be.

The signed lease is a commercial licensing mechanism, not DRM. It raises the economic floor for abuse — editing the lease file does not work, sharing one key across more devices than the activation limit allows gets caught on the next revalidation — but it is not tamper-resistant in the DRM sense. For the full picture of the entitlement model and how the SDK integrates it, see the license keys feature page.

The field-by-field anatomy is the part most license-key guides skip, and it is where the security of the model actually lives. If there are aspects of the signing or verification flow you want to dig into further, send us your feedback and we'll extend this post.

FAQ

What is an Ed25519 lease?

It is a small JSON document — covering the customer, product, expiry, activation limit, and features — signed by an Ed25519 private key held on Keylight servers. The app verifies the signature locally using the matching public key.

Can the customer modify their own lease?

They can edit the file, but the signature will no longer match. The Keylight SDK rejects any lease whose signature does not verify against the embedded public key.

Why Ed25519 and not RSA?

Ed25519 produces smaller signatures (~88 bytes vs ~344 for RSA-2048), is faster to verify, and avoids the parameter-choice footguns RSA introduces. For desktop licensing where the app verifies the signature on every launch, the size and speed matter.

How License Keys Work for Desktop Apps

Nico — Sat, 27 Jun 2026 09:26:18 +0000

Originally published on the Keylight blog.

The "XXXXX-XXXXX-XXXXX" string you paste into a registration window looks simple, and the idea behind it is simple. But what makes a license key actually secure has changed completely over the last two decades. This post explains how license keys work for desktop apps today, and why the old way no longer holds up.

The old way: checksum keys

For a long time, a license key was a string that was valid if its characters satisfied some arithmetic rule. The app contained the rule. When a customer typed in a key, the app ran the check locally: do these digits sum to the right value, do these segments relate in the expected way? If yes, unlock.

This was cheap and worked offline, but it had a fatal flaw. The validity lived in a pattern, and patterns can be reverse-engineered. Once one person worked out the rule — or simply found one key that passed — that key, or a generator for it, ended up on the internet. The app had no way to tell a paying customer's key from a pirate's, because both satisfied the same rule.

Checksum keys are not a security mechanism anymore. They are a speed bump.

The modern way: signed keys

A modern license key does not encode validity in a pattern. It carries a cryptographic signature — proof that a server you control minted this specific key for this specific entitlement.

It works with a key pair. The server holds a secret private key and uses it to sign. The app ships with the matching public key and uses it to verify. The mathematics of the algorithm — Ed25519 is the standard choice — guarantees two things: only the holder of the private key can produce a signature the public key accepts, and the public key reveals nothing that helps forge one.

So you can embed the public key in every copy of your app, ship it to the whole world, and an attacker still cannot mint a working key. The validity no longer lives in a guessable pattern; it lives in a signature only your server can produce.

What is actually inside the key

A signed key is not just a random-looking string — it is a small structured document, an entitlement, with a signature attached. It typically carries who the license belongs to, which product and plan it covers, when it was issued, when it expires (if ever), and how many devices it may activate:

{
  "id": "lk_01hx9z4bqncktjvx6a2r3p8wy",
  "productId": "prod_myapp_pro",
  "plan": "pro",
  "activationLimit": 3,
  "issuedAt": "2026-05-15T09:12:00Z",
  "expiresAt": null,
  "revoked": false,
  "sig": "base64url(ed25519_signature)"
}

The signature covers every field above it. If anyone edits a single character — bumping activationLimit from 3 to 99, or flipping revoked to false after a refund — the signature no longer matches, and the app rejects the key. The customer holds the document, but they cannot change what it says.

How the app checks it

When your app has a key, validation is a local computation: parse the document, run the signature check with the embedded public key, then read the plain fields — is it expired, is it revoked, is it within its device limit. No server call. The app can do this on a plane.

That is the headline benefit of signed keys for desktop apps specifically. A web app can validate against its server on every request for free, because it is always online. A desktop app is not always online, and a license check that needs the network will fail for legitimate customers. Signed keys remove that dependency. For the full treatment of local verification, see software license keys explained.

Revocation is the one thing local verification cannot do alone — a key the app has never been told about cannot know it was refunded. So signed-key systems add a periodic online re-check: every few days, when the app has a connection, it reconfirms the key server-side and picks up any revocation. Everyday validation stays offline; only the occasional re-check needs the network.

What this means if you are building it

If you are adding licensing to a desktop app, the takeaway is: do not ship checksum keys. They will not protect your revenue. You want signed keys — which means a private key to manage, a signing service, an entitlement format, verification code in your app, and the periodic re-check logic.

That is a real amount of infrastructure, which is why licensing layers exist to provide it. However you build it, the model is the same: a signed document the customer cannot forge or edit, verified locally by your app. If there is an angle on license keys you would like covered in more depth, send us your feedback.

FAQ

What is a software license key?

A license key is a unique value a customer receives after paying, which the app checks to unlock paid functionality. Modern keys are cryptographically signed so the app can verify them without contacting a server.

Are old-style checksum license keys still secure?

No. A checksum key is valid if its characters satisfy a pattern, so one leaked working key can be shared endlessly. Signed keys solve this — only the server holding the private key can mint a valid one.

Can a license key work without an internet connection?

Yes, if it is signed. The app ships with a public key and verifies the signature locally, so no network call is needed to confirm the license is genuine.

How to ship and sell a paid desktop app outside the app stores (2026)

Nico — Sat, 27 Jun 2026 06:38:08 +0000

You built a desktop app — macOS, Windows, Linux, native or Tauri/Electron — and you want to sell it directly instead of handing 15–30% to Apple or Microsoft. Selling outside the stores means you keep the margin and own the customer relationship. It also means the plumbing the stores quietly handled is now yours: distribution, payments, licensing, updates, support.

Here's the whole path, in roughly the order you'll hit it — with the licensing part (the one most people underestimate) covered properly.

Why sell outside the app stores

Margin. You keep 85–100% instead of giving up the store's cut.
Control. Your own pricing, trials, upgrades, and refund policy — no review gatekeeping, no waiting on approval to ship a fix.
The relationship. You get the customer's email and can actually support and re-sell to them.

The tradeoff is that the things the store did invisibly — vouching for your binary, taking payment, enforcing the purchase — are now your job. This isn't a Mac thing. Windows devs sell direct constantly, Linux too, and a Tauri or Electron app ships to all three from one codebase. The work below applies across the board.

1. Distribution and updates

Before anyone pays, they have to trust and install the thing.

macOS: sign with a Developer ID certificate and notarize with Apple, or Gatekeeper will scare users off.
Windows: an Authenticode code-signing certificate, ideally EV to build SmartScreen reputation faster.
Linux: package as AppImage, .deb/.rpm, or Flatpak depending on your audience.

Then updates, because the store won't push them for you: Sparkle (macOS), Squirrel/electron-updater (Electron), the Tauri updater, or your own endpoint. Decide this early — retrofitting auto-update onto a shipped app is miserable.

2. Getting paid

Two real models:

Stripe (you're the merchant). Lower fees, full control, your brand on the receipt. The catch: sales tax and EU VAT are your responsibility (handle it yourself or bolt on a tax service).
Merchant of Record (Lemon Squeezy, Paddle, Polar). They become the seller of record and handle worldwide tax for you, for a higher cut. Less control, far less compliance headache.

Rule of thumb: pick an MoR if tax/compliance is the thing you least want to think about; pick Stripe if you want margin and control and will deal with tax separately.

3. Licensing and activation — the part people underestimate

Here's the trap: a payment is not protection. "They paid" and "this specific install is allowed to run" are two different facts, and the gap between them is where piracy and support tickets live. Licensing is the layer that closes it, and on the desktop it has to keep working with no network.

What a real licensing layer actually has to do:

Issue a key when someone buys.
Activate that key on a device (bind it, so one key isn't infinite installs).
Verify it on every launch — including offline, on a plane or behind a firewall.
Enforce device limits and gate features or tiers (entitlements).
Handle trials, expiry, refunds, and revocation without locking out honest customers.

The cross-platform tax

If you ship macOS and Windows and Linux — or native and Tauri and Electron — you need the same licensing logic everywhere. Re-implementing key validation per platform is exactly where subtle bugs and piracy creep in: a weaker check on one OS undermines all of them. One consistent verification path across every build is the goal.

Build vs. buy

Rolling your own means a signing server, key management, device fingerprinting, and an offline-verification scheme done correctly — which means never trusting a plain {"valid": true} from your server (a proxy forges that for free). The durable approach is a cryptographically signed lease: your server signs the license state with a private key, your app verifies it locally with the public key, no network required. (Here's how that works in detail.) Most indie devs underestimate this by a week or more.

The done-for-you option is what Keylight exists for: one control plane with finished SDKs for Swift, Rust, JavaScript/TypeScript, C#, and C++, so the same licensing behaves identically across native macOS/Windows/Linux, Tauri, and Electron. Offline Ed25519-signed leases verify on-device, entitlements ride inside the lease, and connecting Stripe mints keys on payment — no webhook code. Disclosure: I build it.

For the broader landscape — Keygen, Cryptolens, LicenseSpring, and the keys-as-a-feature options like Lemon Squeezy and Polar — there's an honest tool-by-tool comparison here; they're good at different things and the right pick depends on whether your bottleneck is control, payments, or time.

4. Piracy — the realistic stance

You will not stop a determined cracker, and chasing that goal usually means punishing paying customers. The achievable goal: make casual copying inconvenient, keep honest people honest, and never ship online-only checks that lock out legitimate users when their network drops. Offline-friendly licensing beats aggressive DRM on every axis that matters for an indie business.

5. Refunds, support, and self-service

The tickets you'll actually get: "I got a new laptop and can't activate," "I need to move my license," "I bought the wrong tier." A self-service portal — deactivate a device, move a seat, see your license — saves you from being a human license desk. Build a thin one or use a provider that includes it.

The order to do it in

Sign + notarize/package so people can install it.
Wire payments (Stripe or an MoR).
Add licensing + activation — keys, device limits, offline verification, entitlements.
Add auto-update.
Add a trial and a self-service portal.
Ship it.

The app was the hard part, and you already did it. The rest is plumbing — and licensing is the plumbing people get wrong, because paid and allowed to run offline on the right number of devices are different problems. Get distribution and payments handled, then make licensing boring: signed leases, device limits, entitlements, one SDK per stack. Then go sell it.

If you want the licensing layer handled across every desktop stack in one place, that's Keylight — there's a free tier to start.

How to add license keys to a SwiftUI macOS app (in under an hour)

Nico — Sat, 27 Jun 2026 06:38:05 +0000

You built a Mac app, you want to sell it outside the App Store, and now you need licensing: a key the customer enters, an activation that sticks, and feature gates that hold up offline. Here's how to do it in an afternoon without standing up a backend.

Note: this is cross-posted from the Keylight blog. I build Keylight, so this uses it as the worked example — the shape of the solution applies whatever SDK you choose.

The three things licensing actually has to do

Strip away the marketing and every licensing system does exactly three jobs:

Activate — turn a key the user pastes in into proof-of-purchase bound to this device.
Verify — on every launch, confirm that proof is still valid, including offline.
Gate — unlock features based on the tier/entitlements the license carries.

If you build this by hand you're writing a server, a crypto layer, and a state machine. The point of an SDK is to skip all three.

1. Add the SDK

Add the Swift package in Xcode (File ▸ Add Package Dependencies) pointing at the Keylight Swift SDK, then configure it once with your tenant key at app launch:

import Keylight

let keylight = Keylight(tenant: "your_tenant_key")

2. Activate a key

Give the user a text field and call activate. This is the one online step — it exchanges the key for a signed, device-bound lease that's stored locally:

do {
    try await keylight.activate(key: enteredKey)
    // lease stored — the app is now licensed on this device
} catch {
    // show the user why: invalid key, device limit reached, etc.
}

3. Verify on launch (offline-safe)

On every subsequent launch you don't hit the network. The SDK verifies the stored lease's Ed25519 signature locally and hands you a state:

switch keylight.checkOnLaunch() {
case .licensed(let lease):
    unlockApp(entitlements: lease.entitlements)
case .trial(let daysLeft):
    runTrial(daysLeft: daysLeft)
case .expired, .invalid:
    showActivationScreen()
}

No server call, so the app opens instantly and works on a plane. The lease carries a max-offline window; past it the SDK refreshes online once, which is also where a revoked or refunded license gets caught.

4. Gate features by entitlement

Because entitlements are signed inside the lease, feature gating is offline too. Don't scatter if licensed across your views — read entitlements once and drive your UI off them:

@Observable final class Licensing {
    var entitlements: Set<String> = []
    var isPro: Bool { entitlements.contains("pro") }
}

if licensing.isPro {
    ProExportButton()
} else {
    UpgradePrompt()
}

5. Get paid (the part people forget)

A license is only useful if buying one mints it. If you connect Stripe, a completed payment can mint the license automatically — no webhook code to write — so the customer's key works the moment they pay. That closes the loop: pay → key → activate → offline-verified Pro.

What you skipped by not building it yourself

A signing server, Ed25519 key management, lease parsing, device binding, a trial/expiry state machine, and Stripe webhook plumbing. That's the week-plus you just didn't spend.

Full docs and the free tier are at keylight.dev. If you're on Tauri or Electron instead of native Swift, the same SDK pattern exists in JS/Rust.