FAQ

A value set in the Property- or Field-Inspector is not assigned at runtime.

If a field or property is assigned through reflection or the Unity Inspector, it may end up with a different name after obfuscation. This causes issues because Unity expects the original name due to its serialization process within the Editor.

To ensure compatibility, attach the DoNotRename attribute to the field or property.

This is primarily relevant when you've enabled obfuscation for serializable or Unity public fields.

An Event-Method is not being called.

Unity events can sometimes fail to trigger if the obfuscation process changes the name of the event listener method. This happens because Unity expects the original method name due to its internal serialization.

Here are two ways to prevent obfuscation from breaking your events:

  1. Inspector-Assigned Event Listeners:
  • Compatibility Component: If you assign event listeners through the Unity Inspector, activate the "Unity Event Methods - Compatibility" component. It automatically detects these methods and excludes them from obfuscation.
  • DoNotRename Attribute: Alternatively, you can manually attach the DoNotRename attribute to the listener methods.
  1. Code-Based Event Listeners:

The most reliable approach is to add event listeners directly in your source code. This way, the methods can still be obfuscated without breaking event functionality.

// Example: Add event listener via code.
public class ExampleClass : MonoBehaviour
{
    UnityEvent m_MyEvent;

    void Start()
    {
        if (m_MyEvent == null)
            m_MyEvent = new UnityEvent();

        m_MyEvent.AddListener(Ping);
    }

    void Update()
    {
        if (Input.anyKeyDown && m_MyEvent != null)
        {
            m_MyEvent.Invoke();
        }
    }

    void Ping()
    {
        Debug.Log("Ping");
    }
}

A UI-Method is not being called.

UI methods and UI event listeners work the same way as other Unity event listeners. For information on how to prevent obfuscation from breaking these events, please refer to the section titled An Event-Method is not being called above.

An Animation-Method is not being called.

Animation events and trigger methods can be invoked in several ways: through the model itself, an animation file, or the animation controller. Unfortunately, these methods are always name-based, so direct obfuscation is not possible since they are always called via reflection.

Here are two ways to prevent obfuscation from breaking these events:

  1. Compatibility Component: Activate the "Unity Animation Methods - Compatibility" component. It automatically detects animation methods and excludes them from obfuscation.
  2. DoNotRename Attribute: Alternatively, you can manually attach the DoNotRename attribute to the animation methods.

My saved data cannot be loaded.

Saved data often stores field or property names as text. JSON is a common example.

// Example: Simple JSON file.
{"name":"John", "age":30, "car":null}

In this example, the saved keys are name, age, and car. If those field names are changed during obfuscation, the save system may not find them anymore.

To prevent this, keep the names stable with DoNotObfuscateClass, DoNotRename, or namespace skipping.

My network data is not read or written correctly.

Network data has the same problem as saved data when names are sent as text. Keep DTOs, request classes, response classes, and protocol fields stable with DoNotObfuscateClass, DoNotRename, or namespace skipping.

My networking package breaks after obfuscation.

Networking packages may use RPC method names, message names, or data field names. If those names change, the client and server may no longer agree.

To fix this:

  1. Enable the matching package setting in the Compatibility tab, if one exists.
  2. Keep network DTOs and RPC methods stable with DoNotRename, DoNotObfuscateClass, or namespace skipping.
  3. If both client and server are obfuscated, use the same mapping workflow for both builds.

I have a StackTrace and want to know the original class and method names.

Enable mapping generation in Project Settings -> GuardingPearSoftware -> Obfuscator -> Optional -> Renaming. Build the game and keep the mapping file for that exact build version.

Then open Window -> GuardingPearSoftware -> Obfuscator -> ErrorStack, load the mapping file, paste the stack trace, and click Deobfuscate. See the Error Stack Window page for the full workflow.

I want my Coroutines to be obfuscated, what can I do?

Unity can start coroutines by method name. If that method name is changed, Unity cannot find it anymore.

// 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");

In this example, StartCoroutine("Fade") depends on the text name Fade.

Use the IEnumerator overload instead:

// 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());

Unity IAP Purchase Issues on Android After Obfuscation

Issue Description

When using Unity IAP with obfuscation, the InitiatePurchase method may fail silently when using custom payloads.

Understanding Payloads

The payload parameter in InitiatePurchase(string productId, string payload) is typically the root cause:

  • It's a developer-defined string passed to the store during purchase.
  • Required for Google Play and Amazon stores.
  • Used for transaction verification and custom data tracking.

Example Payload Format

{
  "userId": "user_12345",
  "sessionId": "session_67890",
  "timestamp": "2025-03-18T01:23:45Z",
  "customData": "anything_you_want_here"
}

Solution

Skip payload classes from obfuscation:

[DoNotObfuscateClass] // Add this attribute
public class PurchasePayload
{
    public string userId;
    public string transactionId;
    public long timestamp;
    public string customData;
}

Does Obfuscator Pro officially support Windows and macOS Standalone builds with IL2CPP?

Yes. Obfuscator Pro supports every platform Unity itself supports, including Windows and macOS Standalone builds with the IL2CPP scripting backend.

Are there any known issues with Mac App Store submission, code signing, validation, entitlements, or sandboxing after obfuscation?

So far, none. There are no known issues with Mac App Store submission, code signing, validation, entitlements, or sandboxing for builds processed by the Obfuscator.

If you do run into something specific to your project setup, please send us your build settings and the obfuscation log so we can take a look.

Are there any known issues with Steam / Steamworks SDK integration?

So far, none. Builds with the Steamworks SDK integrate with the Obfuscator without any known compatibility issues.

If you use a custom Steam wrapper that relies heavily on reflection or name-based lookups, you may want to apply DoNotRename or DoNotObfuscateClass to the affected types just to be safe.

Which protection features are unavailable or limited when using IL2CPP?

The main feature that is not available on IL2CPP is Method Control Flow. The transformation it applies produces C# IL that IL2CPP's C++ translator cannot interpret correctly, which would lead to build or runtime errors. This limitation is by design.

Everything else – lexical renaming (classes, methods, fields, properties, events, parameters, namespaces), string obfuscation, random code generation, and ILDasm suppression – is fully supported on IL2CPP.

Note

A small number of additional security features (e.g. Control Flow and Sign Assembly) are Mono-only by design. See the Security settings page for the complete platform support matrix.

What settings or exclusion rules do you recommend to avoid breaking Unity serialization?

We recommend an iterative approach:

  1. Start with the default settings. They are tuned to be safe for the majority of Unity projects.
  2. Build and test your project end-to-end (Editor build, target platform build, gameplay, save/load, networking, etc.).
  3. Enable one additional feature at a time and test again after each change.
  4. If something breaks, exclude the affected types or fields using:
    • [DoNotRename] on individual fields, properties, or methods.
    • [DoNotObfuscateClass] on the entire class.
    • The Skip following Namespaces list in the Obfuscation tab for whole namespaces.

This way, you always know exactly which feature caused an issue and can apply the smallest possible exclusion rather than disabling protection wholesale. Code that relies on reflection, the Unity Inspector, or name-based serialization is the most common source of issues.

Should we exclude JSON DTO / server protocol classes from obfuscation if their field/property names must remain stable?

Yes. Any class whose field or property names must remain stable for server communication (or for any external system that reads the names) should be excluded from obfuscation. You can do this at any granularity:

  • Whole namespaces: Add the namespace prefix to Skip following Namespaces in the Obfuscation tab.
  • Single classes: Apply [DoNotObfuscateClass] (skips renaming for the class and all of its members) or [DoNotRename] (skips renaming the class itself only).
  • Individual fields or properties: Apply [DoNotRename] to just the members that need to keep their original names.
// Example: keep DTO field names stable for server communication.
[DoNotObfuscateClass]
public class LoginRequest
{
    public string userId;
    public string token;
    public long timestamp;
}

Are there any known issues with Unity Addressables or string-based asset/resource keys?

Addressables are fully supported. The Obfuscator detects and updates the script references inside built addressable bundles automatically, so they continue to load correctly after the rest of your code has been renamed. See the Addressable settings for the configuration options (default and custom build paths).

Note

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

For string-based Resources.Load calls or other path-based asset lookups, the asset path itself is unaffected by obfuscation (paths are data, not identifiers). The class types you cast to, however, are affected – if you load a MonoBehaviour or ScriptableObject by path and serialize it through Unity's normal serialization, follow the same recommendations as for Inspector-assigned data.

Does the asset provide mapping/de-obfuscation support for crash logs from Windows/macOS IL2CPP builds?

Yes. Enable the renaming mapping in the Optional → Renaming settings tab to generate a JSON mapping file that records the relationship between original and obfuscated names. Each build produces its own mapping file – store it alongside the build artifacts so you can match crash reports to the exact version that produced them.

You then have two options for using the mapping:

  1. Built-in deobfuscator: Open Window → GuardingPearSoftware → Obfuscator → ErrorStack, load the mapping file, paste the obfuscated stack trace, and click Deobfuscate. See the Error Stack Window page for the full workflow.
  2. External tooling: Many users feed the mapping file into their existing crash reporting service (for example, Sentry) so that incoming stack traces are deobfuscated automatically inside their error dashboard.