Adding software licensing to a Unity application involves more than generating a license key. A production licensing system needs to determine whether a license is valid, associate licenses with the appropriate installations, and enforce the features or usage limits associated with each license.

Because Unity uses C# as its scripting language, you can use a .NET based licensing SDK to add licensing functionality to a Unity project. There are, however, some Unity specific considerations around platform compatibility and dependencies.

What Does Software Licensing Code for Unity Need to Do?

The exact implementation depends on how your Unity application is distributed and how customers are expected to use it. A typical Unity licensing implementation needs to handle several responsibilities.

‍

License Activation and Verification

The application needs to communicate with the licensing system and determine whether a license is valid. This can include checking the license status, expiration date, and other properties relevant to your application.

If you are new to software licensing, our guide on how software licensing works explains the main components involved in a licensing system.

‍

Machine or Installation Binding

If licenses should only work on a limited number of installations, the application can provide a machine code when activating the license. This allows the licensing system to keep track of which environments are using a license.

For Unity applications running across different platforms, the way an installation is identified can require additional consideration. The appropriate identifier depends on the target platform and how the application is deployed.

‍

Entitlement Enforcement

A valid license does not necessarily mean that every feature should be available. Your Unity application can use information from the license to determine which features, editions, or usage limits apply to the customer.

For example, a game or interactive application could use licensing to unlock additional functionality, content, or premium features.

‍

Handling Connectivity Requirements

Some Unity applications can always communicate with the licensing service, while others need to continue operating when connectivity is unavailable. The appropriate licensing architecture depends on the deployment environment and the platforms you support.

‍

Using a Unity Licensing SDK

Since Unity uses C# as its scripting interface, a .NET based licensing SDK can be integrated into a Unity project.

Devolens provides a cross platform version of its .NET client library specifically for environments such as Unity. The library can be referenced from the Unity project as Cryptolens.Licensing.CrossPlatform.dll.

For a typical project, the library is added to the Unity Assets folder and the licensing logic is then included in the relevant C# scripts.

Unity versions can differ in how they handle dependencies, so it is important to check the .NET and Newtonsoft.Json versions used by your Unity project when integrating the SDK.

Implement License Verification in Unity

A basic Unity implementation can activate a license and then create a license object from the response. The Unity specific version of the SDK recommends this approach because signature verification can otherwise behave differently across some supported platforms.

using Cryptolens.Licensing;

public class LicenseManager
{
   private const string Auth = "YOUR_ACCESS_TOKEN";
   private const string RsaPubKey = "YOUR_RSA_PUBLIC_KEY";

   public bool VerifyLicense()
   {
       var result = Key.Activate(
           token: Auth,
           productId: 1234,
           key: "AAAAA-BBBBB-CCCCC-DDDDD",
           machineCode: "YOUR_MACHINE_CODE"
       );

       var license = LicenseKey.FromResponse(RsaPubKey, result);

       if (license == null)
       {
           return false;
       }

       return true;
   }
}

The exact product ID, license key, access token, and RSA public key are specific to your Devolens account. The access token used by the application should have only the permissions required for the operations it needs.

The license object can then be used by your application when enforcing licensing rules.

For a more general overview of the implementation process, see our guide to implementing a software licensing system.

Enforce Features and Entitlements

License verification is only one part of the implementation. Your Unity application also needs to decide what a customer can do after a license has been verified.

For example, you may have different editions of a Unity application where some functionality is only available to customers with a particular entitlement. The application can inspect the relevant license information and enable or disable functionality accordingly.

This can be useful for commercial Unity assets, plugins, games, visualization software, and other applications where different customers receive different functionality.

The same principle can be used for trials, subscriptions, usage limits, and other licensing models. Devolens provides capability guides covering these different licensing approaches.

‍

Choosing a Machine Code for Unity Applications

Machine binding can be useful when a license should only be used on a specific machine or a limited number of installations.

The appropriate machine identification method depends on the platform on which your Unity application runs. Some of the standard machine code methods require permissions that may not be available on every platform.

For example, the Devolens documentation notes that Helpers.GetMachineCode() and IsOnRightMachine() require root access on Linux. For Unity applications using IL2CPP, Helpers.GetMacAddress() can be a better alternative because other machine identification methods may not work as expected.

The important consideration is to choose an identifier that remains sufficiently stable for the environment in which the application is deployed. A desktop application and a mobile or platform specific Unity application may therefore require different approaches.

‍

Handling Licensing in Production

A development implementation can often be reduced to a single activation call. Production Unity applications need to consider what happens when the licensing service cannot be reached, when a license expires, or when customers operate in restricted environments.

For applications that require continued operation without an internet connection, Devolens supports offline licensing using signed license data. A license can be retrieved while connected and subsequently validated locally without contacting the licensing service.

The Unity SDK also supports loading locally stored license data while verifying its signature with the application's RSA public key. This allows the application to validate the license without requiring a connection to the licensing service every time it starts.

For more demanding offline deployments, such as restricted or air gapped customer environments, a license server can provide a centralized licensing endpoint inside the customer's network. Devolens License Server explains this architecture in more detail.

‍

Unity Version and Dependency Considerations

Unity projects can use different runtime and API compatibility configurations, which can affect how external .NET libraries behave.

The Devolens cross platform library has a dependency on Newtonsoft.Json. Newer Unity versions include Newtonsoft.Json as an internal package, while older versions may require the dependency to be included separately.

The .NET compatibility level can also matter. If a built Unity project returns a null response from Key.Activate, the Devolens documentation recommends checking the API Compatibility Level under the Unity Player settings and using the appropriate .NET Framework binaries.

For this reason, it is important to test licensing in an actual build of the Unity application rather than only in the Unity Editor. The target platform and build configuration should be included in licensing tests before distributing the application.

‍

A Practical Approach to Unity Software Licensing

For most Unity applications, the implementation can be kept relatively small:

1. Define what the license controls, such as access, features, installations, or usage.
2. Create the corresponding products and licenses in the licensing system.
3. Add the appropriate cross platform .NET SDK to the Unity project.
4. Activate the license when appropriate and verify the returned license information.
5. Enforce the relevant entitlements in the Unity application.
6. Choose a machine or installation identifier that works with your target platforms.
7. Decide how the application should behave when connectivity is unavailable.
8. Test the licensing flow in actual builds for each supported platform.

The important part is not the number of lines of licensing code. It is making sure that the licensing behavior matches how the Unity application is actually distributed and operated.

‍

Conclusion

Implementing software licensing in Unity can be handled using a .NET based licensing SDK, allowing the application to activate and verify licenses without requiring you to build the entire licensing infrastructure yourself.

The main additional consideration compared with a standard .NET application is platform compatibility. Unity projects can target different platforms and runtimes, so machine identification, .NET compatibility, dependencies, and offline behavior should all be tested in the environments where the application will actually run.

For simple applications, this may only require activation and entitlement checks. More complex Unity products can build on the same foundation with machine locking, trials, subscriptions, usage based licensing, or offline deployments.