Is Keylight only for macOS apps?

No. Keylight ships three SDKs today — Swift, Rust, and JavaScript/TypeScript — so macOS, Tauri, Electron, Node, and web apps share the same licensing layer. Swift is the most mature; a public REST API for stacks without a dedicated SDK is next.

Will Keylight have a REST API?

Yes. The backend that powers the SDKs already runs as a hosted API. The plan is to expose it as a stable, public, language-agnostic REST surface so any stack can issue and verify licenses.

Can I manage licenses for several apps in one place?

That is the goal: one dashboard for every license you issue, across apps and stacks, instead of a separate tool per platform.

The future of Keylight: one licensing layer for every stack

Keylight started Apple-first, and the Swift SDK is still the most mature path — a Swift SDK, offline Ed25519 leases, Stripe wired in. But it isn’t Apple-only anymore: Rust and JavaScript/TypeScript SDKs ship today too. Here’s how it got here, and where it’s going.

Apple first, on purpose

Every licensing tool that tries to be everything for everyone ends up generic. Keylight went the other way: pick one platform, go deep, be the best licensing layer a Mac developer can drop in. That’s the Swift SDK — a state machine you call on launch, offline verification that works on a plane, payments that mint a license with no webhook code.

Going deep on Apple first wasn’t a limit. It was the plan. You earn the right to go wide by being undeniably good at something narrow.

Then more than Apple — now

That move already started. Keylight ships native SDKs for Rust and JavaScript/TypeScript today, alongside Swift — so a Tauri or Electron build, a Node service, or a web app issues and verifies licenses the same way a Mac app does. All three share the offline model: every app ships the public key, and verifying a signed lease is something any language can do.

What’s next is a public REST API. The backend that powers the SDKs already runs as a hosted API — the work is exposing it as a stable, language-agnostic surface. That covers the long tail: a Windows app, a Linux daemon, anything without a dedicated SDK yet can call it directly. SDKs lead where the demand is; the API catches everything else.

One dashboard, not one tool per stack

Here’s the part that matters if you ship more than one app.

Right now, a developer with a Mac app, a Windows tool, and a web product is probably running three different licensing setups — three dashboards, three sources of truth, three places a refund has to be handled. That’s the tax for using a platform-specific tool per platform.

Keylight’s bet is one control plane. Every license you issue — every app, every stack — in one dashboard. One place for activations, revocations, seats, and metrics. The licensing layer for your whole catalog, not one corner of it.

What doesn’t change

Going wide doesn’t mean going soft. The model stays exactly what it is: signed leases the app verifies offline, you keep your own Stripe and your own customers, no merchant-of-record skim, no complexity you didn’t ask for. More stacks, same simple core.

Where it actually is today

To be straight about it: not all of it is shipped. Three SDKs are real right now — Swift (the most mature), Rust, and JavaScript/TypeScript. The public REST API and more languages are next — not done.

If you’re shipping a Mac, Swift, Tauri, Electron, Node, or web app, you can use Keylight today — start free. On a stack without an SDK yet? The REST API is coming, and it’s worth following along.

One licensing layer, every stack, one dashboard. Apple first. Not Apple-only.