How Device Activations Work

When a license key is “valid for 3 devices,” something has to count those devices — recognise them, track them, and refuse the fourth. That something is a device activation system. This post explains how it works, and the small details that decide whether it feels fair or infuriating.

What an activation actually is

A license key answers “is this customer entitled to the app?” Device activation answers a sharper question: “is this machine one of the machines that customer is allowed to run it on?”

An activation is the event that registers a specific device against a key. When your app runs on a computer for the first time, it activates: it sends the key and a device identifier to the licensing server, the server checks the device count against the key’s limit, and it either admits the device or refuses it.

Three things make the system work: an activation limit (a number on the license — how many devices it allows), a device identity (a way to recognise each machine), and an activation record (server-side state listing which devices have activated which key).

Recognising a device: fingerprinting

To count devices, the system has to tell them apart and recognise a returning one. It does that with a device fingerprint: a stable identifier derived from the machine itself.

A good fingerprint has two properties. It is stable — the same across reboots, app updates, and OS minor versions, so a customer is never silently re-activated. And it is non-invasive — derived from ordinary hardware and install characteristics, then hashed before it leaves the device, so the server stores an opaque token rather than a description of anyone’s computer.

The fingerprint’s only job is equality. The server does not care what the device is; it only needs to know whether this is a device already on the key or a new one.

The activate flow, step by step

Here is what happens on activation:

1. The customer’s app has a key (entered manually, or delivered straight after checkout).
2. The app computes the device fingerprint and sends it with the key to the server.
3. The server looks up the key. If the fingerprint is already activated, it just confirms — no new slot is used.
4. If the fingerprint is new, the server compares the current device count to the activation limit. Under the limit: it records the device, increments the count, returns success. At the limit: it refuses and returns a clear reason.
5. The app updates its license state.

Step 3 is the detail that separates a fair system from a maddening one. Activation must be idempotent per device: relaunching the app, or reinstalling it on a machine that already activated, must re-confirm without consuming a new slot. The count moves only when a genuinely new device appears. Get this wrong and customers burn through their device limit just by using the app normally.

In the SDK, the whole flow is one call:

await licensing.activate(key: enteredKey)

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

Deactivation: the part that keeps it honest

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

Deactivation fixes it. The customer removes a device from their key, ideally themselves through a customer portal that lists their devices with a remove button. Removing one decrements the count and frees a slot. No ticket, no waiting.

This is also why the limit should be generous. Activation exists to stop a key being shared across an organisation, not to police a customer who owns three Macs. Three to five devices for a personal license, plus easy self-service deactivation, is invisible to honest customers and still meaningful against sharing.

Activation is online; validation is offline

One subtlety worth understanding: activation and license validation have different network needs.

Validating the license — confirming the signature and entitlements — is done locally, which is what lets the app launch offline. Activation is inherently online: the first time a device uses a key, it must reach the server to register and have the global count checked. You cannot enforce a device count from a machine that has never spoken to the server.

So the pattern is: a device activates online once; from then on the app validates the signed license offline on every launch and only revalidates online periodically. Activation is a one-time online step per device; everyday licensing stays offline. The app activation system guide covers the full model.

If there is an activation edge case you would like us to dig into, send us your feedback.