Upon building, Unity will handle code-stripping and IL2CPP conversion. For clarity, here’s how code-stripping works: if Unity cannot detect in advance that a given member will be used in the final build, it will remove it before building. This greatly improves build sizes and ensures compliance with Ahead-of-Time (AOT) platforms like iOS.

Because Bolt 1 uses reflection to power its graphs, Unity cannot detect that any part of the codebase is in use, and is therefore likely to strip code that Bolt actually needs. In Bolt 1, we fixed this issue by creating AOT Stubs, which is basically a dummy C# script file (AotStubs.cs) that pretends to be using every method you use in your graphs.

In Bolt 2, because we will be generating the actual logic of your graphs, most of these stubs are no longer needed, because they’re part of the project’s codebase that Unity scans before stripping. The keyword here is most: unfortunately, two types of stubs are still needed:

• Custom logical / mathematical operators (e.g. +, *, !, etc)
• Custom conversion operators (implicit and explicit casting)

Those are used by Bolt’s ConversionUtility and OperatorUtility, which allow for operating and converting objects for which the type is only known at runtime. One example of that is the Generic Add unit, which takes two arbitrary objects as an input. Because we cannot infer the type of these objects during generation, we have to rely on late-bound reflected operators at runtime to process the equation.

This has two drawbacks:

• We have to generate AOT stubs for these operators to prevent code stripping
• Those conversions and operations are significantly slower than the rest of the Generated Runtime, because they still rely on (albeit optimized) reflection.

Our plan to address those drawbacks is to implement strong-typing features at the core of the Bolt graph language (see Reflected Operators, Schemas, Generic Type Support) so that the requested types can in fact be early evaluated. In the mean time however, in the spirit of minimizing breaking changes, strong-typing will be optional as ConversionUtility and OperatorUtility will remain available at runtime. Users eager to maximize the performance and minimize the memory allocation of their graphs will be advised to use the strong-typing features with a non-critical warning. Weak-typing is likely to be marked as deprecated and removed in a future Bolt version.