The future of Keylight: one licensing layer for every stack

Keylight started Apple-first. For most of its first year the Swift SDK was the whole story: a state machine you call on launch, offline verification that works on a plane, a payment that mints a license with no webhook code. That was the plan, and it worked.

It is not the whole story anymore. Here is how it got here, what shipped, and where it goes next. Updated September 2026. If you want to see what this post promised before any of it shipped, the June version is kept as written.

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.

Going deep on Apple first was not a limit. You earn the right to go wide by being undeniably good at something narrow. The offline model, the signed lease, the free tier, the customer portal, the refund that actually revokes: all of it was built and hardened on one platform before it was asked to work on five.

Then every stack, and that part is done

Today Keylight ships SDKs for Swift, Rust, JavaScript, C++, and C#, and a plain API for everything else. That covers a Mac app, a Windows desktop tool, a Tauri or Electron build, a Unity game, an Unreal or JUCE project, a Node service, and a Go or Python backend with no SDK at all. The C# SDK still carries an Alpha badge, and the site says so wherever it is mentioned.

The part I care most about is that they are not five products. Every SDK checks the same signed lease the same way, tested against one shared set of conformance vectors, so a license that passes on a Mac passes in a Unity build. The trial length and free tier live in the dashboard and every SDK reads them at launch. A customer who upgrades in the portal sees the new tier in the app without a restart, in every language.

The API is the long tail. Two HTTPS calls, a token minted with one command, and a stack that will never get a first-party SDK can license an app in an afternoon. Online-first by design, honest about it, and the right trade for a server or a CLI.

And the whole thing is scriptable. A command-line tool covers products, licenses, customers, and devices, so a release script or an AI agent can do what the dashboard does.

One dashboard, not one tool per stack

This is the part that matters if you ship more than one app.

A developer with a Mac app, a Windows tool, and a web product used to run three licensing setups: three dashboards, three sources of truth, three places a refund has to be handled. That was the tax for using a platform-specific tool per platform.

Keylight’s bet was one control plane. That bet is now the product. Every license you issue, every app, every stack, in one dashboard. One place for activations, revocations, seats, and the numbers after the payment: installs, active devices, versions, platforms, and free-to-paid conversion. Free users included, without handing out a single key.

What does not change

Going wide did not mean going soft. The model stays exactly what it was: signed leases the app verifies offline, your own payment tool, your own customers, no merchant-of-record skim, no complexity you did not ask for. Seven payment providers plug in today. Keylight still never sits between you and your buyer.

Where it goes next

The next stretch is about the people who build with AI. The CLI and the API already let an agent do everything the dashboard does. The next step is making that the default path: install one thing, and licensing is set up the moment your app has a paying customer, before you have shipped. No promises on dates. It ships when it works, like everything else here.

If you sell an app, in any language, you can use Keylight today. Start free, or read the story for your stack: Unity, C++, .NET, Rust, Electron and Node, or no SDK at all.

It started as the best way to license a Mac app. It became the simplest way to license any app. That was the plan all along.