A licensing SDK for Swift apps

You’re shipping a Swift app and you need licensing. You could call a REST API on every launch and write the rest yourself, or you could add a Swift package that does the whole thing. That package is a Swift licensing SDK. Here’s what one actually has to do, and how to add it.

What a Swift licensing SDK does

A license key on its own is a string. The SDK is what turns it into behavior. A real one handles:

• Activation — a customer enters a key, the SDK binds it to the device.
• Verification — on every launch, the app confirms the license is valid, ideally offline.
• Device limits — a key is good for N machines, and the limit is enforced, not suggested.
• Trials and expiry — a countdown, a grace state, a renewal prompt.
• Feature gating — read which tier or features a license unlocks.

Do this by hand and it’s the same few hundred lines every paid app rewrites. The point of an SDK is to never write them.

How the Keylight Swift SDK works

Keylight’s SDK is a state machine. You activate a key once, then check on launch and switch on the result. That’s the integration:

import Keylight

let licensing = Keylight(publicKey: "pk_live_...")

// once, when the customer enters their key
try await licensing.activate(key: userEnteredKey)

// on every launch
await licensing.checkOnLaunch()

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

No license state to track, no expiry math, no endpoint to babysit. The SDK owns it.

Offline verification with Ed25519 leases

The launch check shouldn’t need the network. When a license activates, Keylight issues a lease signed with Ed25519. Your app ships with the public key and verifies the lease locally — so the app opens on a plane, behind a firewall, or in a studio with no internet. Feature flags are signed into the same lease, so you can gate a Pro tier offline without another call. The live device-activation count stays server-side, where it can actually be enforced.

Payments wired in

The SDK is only half the story — licenses have to come from somewhere. With Keylight, a Stripe payment mints the license automatically: Keylight catches the webhook and issues the key, you write no backend. Other processors connect by webhook too; Stripe is just the path that’s already built. That’s the difference between a licensing SDK and a licensing layer — the layer issues the keys the SDK reads.

Swift licensing SDK options

A few choices, honestly framed:

• Keylight — Swift-first, hosted, with the Swift state machine above and payment-to-license minting. No backend to run.
• LicenseKit — a Swift client SDK that reads licenses from a source you supply (a file, your API, or Gumroad). Covers all Apple platforms; you bring the backend. Compared here.
• LicenseSeat — cross-platform with a Swift SDK among many, Ed25519 offline, bring your own processor. Compared here.
• Keygen — a flexible, language-agnostic API you call from Swift directly and wire yourself. Compared here.

For a Swift-first app that wants the SDK and the backend in one, Keylight is the one built for exactly that. For the wider field, see the ranked list of macOS licensing platforms.

How to add it

It’s a Swift Package Manager dependency. Add the package, initialize with your public key, call activate(key:) when a customer enters a key, and checkOnLaunch() on startup. Connect your payment provider once and licenses mint themselves. The full walkthrough is in add license keys to a Swift macOS app.

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