How an App Activation System Works

A license key answers “is this customer entitled to the app?” An activation system answers a sharper question: “is this device one of the devices that customer is allowed to run it on?” Without activation, one purchased key works on unlimited machines and a single sale can supply an entire office. With activation done badly, legitimate customers get locked out of software they paid for. This guide explains how to get it right.

What an activation system does

An activation system binds a license to a bounded set of devices. It has three moving parts:

• An activation limit — a number carried by the license: how many devices this key may run on.
• A device identity — a way to recognise each machine, so the system can tell a new device from one already activated.
• An activation record — server-side state listing which devices have activated a key, so the count can be enforced.

When a customer installs the app and enters their key, the app activates on that device: it registers the device with the licensing server, the server checks the count against the limit, and either admits the device or refuses it. That single transaction is the heart of the system.

The goal is not to make sharing impossible — a determined attacker with one machine can always run one copy. The goal is to make a key behave like what it is: a license for a person and their handful of devices, not a key to the whole product.

Device fingerprinting

To count devices, the system must recognise them. It does that with a device fingerprint: a stable identifier derived from the machine itself.

A good fingerprint is stable — the same across reboots, app updates, and OS minor versions, so a customer is not silently re-activated every week — and non-invasive — derived from ordinary hardware and OS characteristics, not personal data. On macOS, identifiers tied to the hardware and the install give a dependable fingerprint without touching anything sensitive.

The fingerprint is hashed before it leaves the device, so the server stores an opaque identifier, not a description of the customer’s hardware. Its only job is equality: is this the same device as one already on the key, or a new one?

The hard cases are deliberate edge cases, not bugs. A customer who reinstalls their OS or replaces a drive may present a changed fingerprint and consume a second activation slot — which is why a generous limit and easy self-service deactivation matter more than a perfect fingerprint.

Activation limits and the activate flow

Each license carries an activationLimit. The number encodes the product tier: a personal license might allow 2–3 devices, a household or team license more, an enterprise license many or unlimited.

The activate flow runs like this:

1. The customer enters their key (or it is delivered directly after checkout).
2. The app computes the device fingerprint and sends it with the key to the licensing server.
3. The server looks up the key. If the fingerprint is already activated, it simply confirms — re-running the app on a known device never consumes a new slot.
4. If the fingerprint is new, the server compares the current activation count to activationLimit. Under the limit: it records the device, increments the count, returns success. At the limit: it rejects the activation and tells the app why.
5. The app updates its licensed state accordingly.

Step 3 is the detail that separates a fair system from an annoying one. Activation must be idempotent per device — a customer who reinstalls the app, or just relaunches it, must not burn an extra slot. The count only moves when a genuinely new device appears.

Deactivation: the part that makes it fair

An activation system without deactivation is a trap. Customers replace laptops, sell old machines, and reinstall operating systems. If activations only ever accumulate, every honest customer eventually hits the limit on hardware they no longer own, and your support inbox fills with unlock requests.

Deactivation fixes this. The customer removes a device from their key — ideally themselves, through a customer portal that lists their activated devices with a remove button next to each. Removing a device decrements the count and frees a slot for a new machine. No support ticket, no waiting on you.

This is also why the limit should be generous. The point of activation is to stop a key being shared across an organisation, not to nickel-and-dime a customer with two Macs and an old one in a drawer. A limit of three to five for a personal license, plus painless self-service deactivation, stops casual sharing while being effectively invisible to every honest buyer. A limit of one with no deactivation does the opposite: it barely slows a sharer and reliably angers real customers.

When a customer genuinely needs more devices, the activation limit doubles as an upgrade path — moving to a higher tier raises the limit. Enforcement and upsell are the same mechanism.

How activation fits with offline validation

Activation and offline license validation interact, and the interaction is worth being precise about.

The license itself is a signed lease the app verifies locally — that is what lets the app launch offline. Activation, by contrast, is an inherently online transaction: the first time a device uses a key, it must reach the server to register and have the count checked. You cannot enforce a global device count from a machine that has never talked to the server.

So the flow is: a device activates online once; thereafter the app validates the signed lease offline on every launch and only revalidates online periodically. Activation is a one-time online step per device; everyday validation stays offline. The activation count and limit stay on the server — it remains the single source of truth for how many devices a key is on, and you see that count in the Keylight dashboard.

Doing it with Keylight

Building activation yourself means a fingerprinting routine, an activation API, idempotency handling, the activation records, and a customer portal for deactivation. Keylight provides all of it.

Every Keylight license carries an activationLimit you set per product tier. The Swift SDK computes the device fingerprint and handles activation:

import KeylightSDK

// Activate a customer-entered key on this device
await licensing.activate(key: enteredKey)

switch licensing.state {
case .licensed:
    enablePaidFeatures()
case .invalid:
    // activationError carries the reason — e.g. activation limit reached
    showActivationError(licensing.activationError)
default:
    break
}

If a customer hits their limit, the server rejects the activation and the SDK surfaces it through activationError, so the app can prompt them to deactivate an old device or upgrade. Customers manage their own devices through Keylight’s customer portal — deactivating a machine frees a slot with no involvement from you.

The activation count and limit stay on the server, which is the single source of truth — you see how many of a key’s devices are in use from the Keylight dashboard. See desktop app licensing for how activation fits the wider model, and Pricing for plans — starting at $19/month with a free tier to test the whole flow.