Compatibility - Settings

The third of the four settings tabs helps the Obfuscator work with Unity features and common third-party packages. Many Unity systems use names as text. For example, a button in the Inspector may store the method name it should call. If that name is changed, Unity may not find it anymore. Compatibility settings help keep those name-based links working.

Common - Settings

Most common compatibility components are always on. They protect the basic parts that Unity, .NET, and the Obfuscator itself need in order to build and run correctly.

Figure 1 - Default components to ensure compatibility with the Obfuscator.

Animation - Settings

Animations can call methods by name. These method names are stored as text inside animation-related files. This component searches model files (including .fbx, .dae, .3ds, .dxf, .obj, and .skp), animation files (.anim), and animation controllers (.controller). Found methods are kept unchanged so animation events can still call them.

These methods can also be manually excluded using the DoNotRenameAttribute.

Figure 2 - Simplify the Obfuscator's compatibility with animation methods.

You'll find the following settings:

  • Search model files: Search imported model files for animation events.
  • Search animation clip files: Search .anim files for animation events.
  • Search animator controller files: Search .controller files for animation events.

Keep these settings enabled if your project uses animation events. If a specific animation event still breaks, add DoNotRename to the called method.

Event - Settings

UnityEvents assigned through the Unity Inspector often store the target method name as text. This is common for UI buttons and other Inspector callbacks. This component searches scenes and prefabs, finds those methods, and keeps their names unchanged.

These methods can also be manually excluded using the DoNotRenameAttribute.

Figure 3 - Simplify the Obfuscator's compatibility with UnityEvents.

You'll find the following settings:

  • Search in scenes: Search build scenes for Inspector-assigned UnityEvents.
  • Search in prefabs: Search prefabs for Inspector-assigned UnityEvents.

Keep both settings enabled if you assign UI buttons, events, or callbacks in the Unity Inspector. If a scene is open but not listed in Build Settings, the Obfuscator may warn that it was skipped.

Reflection - Settings

Reflection means code looks up a class, field, property, or method by name. Unity and many packages use this. One common example is starting a coroutine by name.

// Example: Coroutine that fades the alpha of a material.
IEnumerator Fade()
{
    Color c = renderer.material.color;
    for (float alpha = 1f; alpha >= 0; alpha -= 0.1f)
    {
        c.a = alpha;
        renderer.material.color = c;
        yield return new WaitForSeconds(.1f);
    }
}

// Example: Call the Coroutine via name.
StartCoroutine("Fade");

When Unity invokes a coroutine by its method name, such as Fade, it has to find a method with that exact name. If the Fade method is renamed, Unity can no longer find it.

This compatibility component helps protect names that are used as strings. The original names are kept where needed, so Unity can still find them after obfuscation.

To avoid the coroutine name problem, use the StartCoroutine overload that takes an IEnumerator parameter:

// Example: Coroutine that fades the alpha of a material.
IEnumerator Fade()
{
    Color c = renderer.material.color;
    for (float alpha = 1f; alpha >= 0; alpha -= 0.1f)
    {
        c.a = alpha;
        renderer.material.color = c;
        yield return new WaitForSeconds(.1f);
    }
}

// Example: Call the Coroutine via IEnumerator.
StartCoroutine(Fade());

Classes and their members can also be manually excluded using the DoNotRenameAttribute.

Figure 4 - Manage the obfuscation of classes and members called via Reflection.

Addressable - Settings

The Addressable-Package is used to load assets from local or remote locations. Addressable bundles can contain references to scripts. After obfuscation, those script names may be different. This setting updates addressable bundles so those references still point to the correct scripts.

Figure 5 - Manage the obfuscation of Addressables.

You'll find the following settings:

  • Default Path: The default build location for local addressable bundles for the current build target.
  • Custom Paths: Add any custom addressable build folders here, especially remote build folders. You can use {BUILD_TARGET} as a placeholder for the current build target.
  • Use Custom Magic Header: Only needed if you use Addressable Shield and changed its default magic header.
  • Magic (hex): The 4-byte magic header in hex format. Examples like A4 AC EF 29, A4ACEF29, or 0xA4,0xAC,0xEF,0x29 are accepted.

Addressable Shield

Addressable Shield encrypts addressable bundles. If you use it, the Obfuscator has to detect the encrypted bundles, decrypt them, update the script references, and encrypt them again.

If you did not change the Addressable Shield magic header, leave Use Custom Magic Header disabled. If you did change it, enable the setting and enter the same 4-byte value in Magic (hex).

Note

At the moment only the JSON catalog version is supported. Binary catalog support will be added in the future.

Third-Party Package - Settings

The Compatibility tab also includes settings for common third-party packages. These settings usually skip names that the package expects to stay stable.

Use these settings when your project includes the matching package:

  • Google - Compatibility: Helps with Google SDKs that use name-based calls or serialized data.
  • PlayFab - Compatibility: Helps PlayFab SDK code keep the names it needs.
  • Photon - Compatibility: Helps Photon networking code, including Fusion or Quantum projects, where network messages and callbacks may depend on names.
  • Meta - Compatibility: Helps Meta, Facebook, and Oculus SDK assemblies.
  • JSON - Compatibility: Helps JSON serializers like System.Text.Json and Newtonsoft.Json keep field and property names that are read or written as JSON keys.
  • Unity IAP - Compatibility: Helps Unity In-App Purchasing, including purchase payload data.
  • DOTween - Compatibility: Helps DOTween callbacks and name-based tween behavior.
  • PlayMaker - Compatibility: Helps PlayMaker actions and events that are stored as data.
  • PixelCrushers - Compatibility: Helps PixelCrushers assets such as Dialogue System and Quest Machine.
  • Chartboost - Compatibility: Helps Chartboost SDK integration.
  • Realms - Compatibility: Helps MongoDB Realm model classes and data binding.

If a package is not listed, start with the default settings and test. If the package stores class, method, field, or property names as text, exclude those parts with DoNotRename, DoNotObfuscateClass, or namespace skipping.