Switching to UI Toolkit

Unity UI Toolkit was introduced already a few years ago. But for a long time it was not a valid option for many projects. The missing support for a world canvas was the major deal-breaker for AR developers like me. And in general, it seemed to be still in beta and not fully functional for real use cases.

Finally, UI Toolkit is able to render UI in world space since Unity 6.2. Time for me to take a deep dive into the new technology and see if switching to it is worth it.

Differences between UI Toolkit and uGUI

These are the main differences which I noticed during my work. Unity provides a list of supported features by each system.

Modern layouting

The UI is built with UXML files. Additionally, styles are assigned with USS files. These files are similar to HTML and CSS files.

And also the layouting is very similar to modern web solutions. You can place multiple objects next to each other, define the direction and whether they shrink or expand. This makes it easy to adjust UIs to different screen sizes.

Data binding

All properties in UI elements can be controlled with data binding. Properties of a data type are assigned to properties of UI elements. These can be text, colors, textures, etc.

The UI automatically updates when the data changes at runtime. And also in the other direction, the data object is updated when the user interacts with the UI.

Data binding saves a lot of boiler plate code and it allows a better separation between designers and developers. Especially for asset store publishers it’s great to have a built-in solution. While there are some data binding plugins for uGUI, it’s usually not feasible to include them for customers.

Separation of game code and UI

The new UI system is completely separated from the other code. There are no MonoBehaviours in the UI. Single UI elements do not show up in the game hierarchy.

Probably you have used one or another hack in the past. And directly connected a game object to some UI element deep down in the hierarchy. I have made such hacks under time pressure and when the clean solution would have required a lot of code. This won’t happen anymore with UI Toolkit.

The good thing is: With data binding there is a very good solution for communicating between game objects and UI.

Only drawback: Investigating UI issues in play mode is a bit harder, because nothing appears in the hierarchy. The UI Toolkit debugger helps with debugging.

Vector graphics

Textures are very important in uGUI. E.g., a common approach for rounded shapes is having textures with that shapes. With common issues such as aliasing and improper resolutions. Of course, there are great solutions on the asset store.

UI Toolkit supports vector graphics out of the box. You can create vector graphics with C# code for custom controls. Define a path with lines, arcs or bezier curves and set how the stroke and fill should look like. The shapes rescale to any screen size without aliasing effects.

Ecosystem

There are thousands of plugins in the asset store, just for the uGUI system. Code extensions, helper scripts, sets of icons, full UI templates for common game setups – game development can be speed up a lot with the right plugins.

There are not so many assets for UI Toolkit yet. Also, there are less tutorials on the web as for uGUI. I assume this will change in the near future when the new system is more widely adopted.

Unfortunately, the Unity asset store does not provide a filter to distinguish between uGUI and UI Toolkit. This means, you have to check the descriptions to find suitable assets. In case you need a color picker – you don’t have to search any longer 🙂

Is switching to UI Toolkit useful?

I think the new UI Toolkit is great. There is a steep learning curve at the beginning, because it’s very different from the rest of Unity development. But after some initial struggles, I now appreciate the workflow.

For new projects I will usually use the UI Toolkit from now on. Unity currently supports both uGUI and UIToolkit . But in the future new features will only be added to the UI Toolkit.

For existing projects, I’ll keep the uGUI system. Converting from uGUI to UI Toolkit is a lot of work. Not only the visual elements have to be recreated, also the communication with the game objects need to be adapted. E.g. events are not serialized anymore in UI Toolkit – any gameobjects that are connected via events to the UI have to be changed.

It’s possible to use both UI systems in the same project. You can use UI Toolkit for new UI views, while keeping uGUI for existing views. This is a useful approach for long-term projects that consist of many individual UI views.