Announcing the PermitCore Unity SDK

The 8th official PermitCore SDK just shipped: Unity. It's a zero-dependency client for Unity 2021.2+ — no Newtonsoft.Json, no additional Unity Package Manager dependencies — and it closes most of the gap on SDK breadth we called out in our own LicenseSpring comparison a couple of days ago (we went from 6 SDKs to 8 in one week — Go landed first, Unity right behind it).

Why this one is architecturally different

Every other PermitCore SDK is built around its language's native HTTP client. Unity is different: game and app developers building for Desktop, Mobile, Console, and WebGL from the same codebase need an HTTP layer that works identically across all of them, and System.Net.Http.HttpClient doesn't — it simply doesn't function on WebGL builds (no raw socket access in the browser sandbox). So the Unity SDK uses UnityWebRequest, the one HTTP client Unity itself guarantees works everywhere.

To keep that engine dependency from spreading through the whole SDK, we split it in two: an IPermitCoreTransport interface is the only seam between the portable request/ response/crypto logic and the actual network call. Everything except two small files (UnityWebRequestTransport.cs and a tiny hardware-id helper beside it) is plain, portable C# with zero UnityEngine reference at all.

Why that split matters in practice

It's what let us build a real automated test suite for a Unity SDK without owning a Unity seat or license — a standalone dotnet test project links the exact same .cs files the shipped package uses and drives them directly. That test suite caught a genuine bug before it ever shipped:

// What we assumed (wrong): .NET's VerifyHash needs DER, like the OpenSSL-based SDKs.
// What's actually true: the original two-argument VerifyHash overload has always used
// the raw IEEE P1363 format by default — no conversion needed, same as the Go SDK.
ecdsa.VerifyHash(hash, signature); // signature is the raw 64-byte r||s

Every one of the shared cross-SDK cryptographic test vectors failed until that was fixed — exactly the kind of thing this shared test-vector suite exists to catch, in a Unity SDK the same way it already had for the other seven.

Quick start

using PermitCore;
using UnityEngine;

public class LicenseGate : MonoBehaviour
{
    private PermitCoreClient _client;

    async void Start()
    {
        _client = new PermitCoreClient("https://api.permitcore.dev");
        var result = await _client.ValidateAsync("PERMIT-XXXX-XXXX-XXXX-XXXX");

        if (!result.IsValid) { Debug.LogError("License invalid: " + result.Message); return; }
        if (result.HasFeature("pro")) EnableProFeatures();
    }
}

One honest limitation: WebGL and offline tokens

Online ValidateAsync/ActivateAsync work fine on WebGL via UnityWebRequest. The fully-offline signed-token verification path doesn't — WebGL's browser sandbox has no System.Security.Cryptography implementation at all. That's a platform constraint of WebGL itself, not something any SDK can route around, and we'd rather say so plainly than let a WebGL build silently fail on it.

A demo that needs zero scene setup

The Task Manager Pro demo for Unity is a single script using Unity's built-in OnGUI immediate-mode UI — attach it to an empty GameObject and press Play, no Canvas, no prefab, no Inspector wiring. Same feature set as the other 7 language demos: a real license gate, a Free-tier task cap that a pro feature flag lifts live, CSV export, an offline-mode banner backed by the SDK's own signed grace cache, and a developer console panel that exercises the offline-token flow end to end.

Try it

Full API reference and installation steps: /docs/sdks/unity. Not yet on a package registry — same as our Go SDK, install today via Package Manager → Install package from disk from the downloaded ZIP; a tagged git repo (installable directly via Unity's git-URL package support) is next, followed by an OpenUPM listing.