Is Keylight only for macOS apps?

Today Keylight is deepest on Apple — the Swift SDK is the most finished path. A public REST API and SDKs for other stacks are next, so Windows, Linux, web, Tauri, and Electron apps can use the same licensing layer.

Will Keylight have a REST API?

Yes. The backend that powers the Swift SDK 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 licenses Apple apps. That’s what it does today, and it does it well — a Swift SDK, offline Ed25519 leases, Stripe wired in. But Apple is where Keylight starts, not where it stops. Here’s where it’s going, and why.

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 every stack

The next move is the obvious one: stop being Apple-only.

It starts with a public REST API. The backend that powers the Swift SDK already runs as a hosted API — the work is exposing it as a stable, language-agnostic surface anyone can call. One API, and a Windows app, a Linux daemon, a web app, a Tauri or Electron build can issue and verify licenses the same way a Mac app does. Offline verification comes along for free: every app already ships the public key, and verifying a signed lease is something any language can do.

After the API, SDKs — for the stacks that ask first. Tauri and Rust, Electron and TypeScript are the obvious next two. Not five SDKs on day one. The API first, then the SDK for wherever the demand shows up.

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: this isn’t all shipped. The Swift SDK is what’s real right now, and it’s the best place to start if you’re building for Apple. The REST API and the other stacks are next — not done.

If you’re shipping a Mac or Swift app, you can use Keylight today — start free. If you’re on another stack and you want the same thing, it’s coming, and it’s worth following along.

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