Keylight vs LicenseKit — hosted licensing vs a client SDK

LicenseKit and Keylight are both Swift-native, and that’s where people assume they overlap. They don’t, really. LicenseKit is a pure client SDK — Apple-only — that reads a license from a source you provide. Keylight is that source plus the SDK, and it ships beyond Apple too: Swift, Rust, and JavaScript. One is a library. The other is the whole layer, across more than one platform.

What LicenseKit gets right

LicenseKit is genuinely Apple-native and mature. It covers the full Apple matrix today — iOS, macOS, tvOS, watchOS, visionOS — which is broader Apple-platform reach than Keylight leads on right now. It’s flexible about where a license comes from: define it in source code, read it from a CSV or encrypted file, fetch it from your own REST API, or wire it straight to Gumroad. It ships a SwiftUI license-manager view you can drop into the app or an Xcode preview.

If you want a self-contained SDK with no hosted dependency, and you already have a place licenses live — a Gumroad product, your own backend — LicenseKit slots in without adding a service to your stack.

Where Keylight is different

LicenseKit verifies. It doesn’t issue, and it doesn’t run a backend for you. Where the licenses come from, how a payment turns into one, how many devices a key is allowed, what the live activation count is — that’s yours to build and host.

Keylight is that half — and then some. A payment mints the license automatically — with Stripe that’s first-class (Keylight catches the webhook, you write nothing), and other payment providers connect by webhook too. Device activations are tracked server-side and enforced, so a key that’s maxed out is maxed out, not just counted on the client. There’s a dashboard for keys, customers, and revocations. And the SDKs cover Swift, Rust, and JavaScript — so the same licensing service backs a macOS app, a Tauri app, and an Electron app with no extra backend. The Swift SDK reads an Ed25519 lease with feature flags signed in, verified offline on launch:

let licensing = Keylight(publicKey: "...")
try await licensing.activate(key: userEnteredKey)

await licensing.checkOnLaunch()
if licensing.state == .licensed { enablePaidFeatures() }

The trade is plain. LicenseKit asks you to bring the backend. Keylight is the backend.

When LicenseKit is the better pick

Be honest about it. If you want a pure Swift SDK with no hosted service in the loop — licenses defined in source or a file, or served from infrastructure you already run — LicenseKit is the cleaner fit. If Gumroad is already your store, its built-in Gumroad path is less to wire than a webhook. And if you need watchOS or visionOS licensing today, LicenseKit covers those where Keylight is focused on macOS and iOS.

LicenseKit is Apple-only by design; that’s its focus. Where Keylight goes further: Rust (Tauri, CLI), JavaScript (Electron, Node), and macOS/iOS — all from the same licensing backend, without adding another service. If you’re building across those stacks, that’s a real difference.

Where Keylight fits

Don’t want to run a licensing backend at all? That’s Keylight. Issuance, payment-to-license minting, activation tracking, revocation, and finished SDKs for Swift, Rust, and JavaScript — one service, no glue. You hold a public key and verify offline; Keylight does the rest.

A library still needs a backend behind it. Keylight is both, so there’s nothing behind it to build.

Plans start at $19/month, with a free tier. Connect your payment provider, drop in the SDK, ship.