uGUI or UI Toolkit: which to build your game's UI in

The short answer

If that table settled it, stop reading and go build. The rest is for the projects where it did not.

What the two systems actually are

The difference is not cosmetic, it is architectural, and it explains every trade-off that follows.

• uGUI builds interface out of GameObjects. A button is an object in the scene with an Image, a Button and a Text component on it. You author it in the scene view, you see it while you place it, and everything you already know about prefabs, the Inspector and the Animator applies to it.
• UI Toolkit builds interface out of a retained visual tree, authored as UXML and styled with USS, which are close relatives of HTML and CSS. Elements are not GameObjects. You author in UI Builder rather than the scene, and you style with selectors that apply across the whole project instead of setting values object by object.

So uGUI feels like the rest of Unity, and UI Toolkit feels like the web. Which of those your team finds natural is a real input to the decision, not a soft one.

What Unity itself says

Worth checking directly, because it surprises people. In the Unity 6 manual's comparison of UI systems, for runtime UI, uGUI is the recommended system and UI Toolkit is listed as the alternative. For Editor tooling it is the other way round: UI Toolkit is recommended and IMGUI is the alternative.

The same page then splits it by use case, and that split is more useful than the headline:

And it lists the features each one does not have. UI Toolkit has no in-scene authoring, no serialized events, and no integration with Animation Clips and Timeline. uGUI has no data binding system, no textureless elements and no SVG support.

Where uGUI still wins

• In-scene authoring. You place interface in the scene, at the scale it will exist, next to the thing it belongs to. For world-space panels and for anyone who thinks visually, this is a genuinely large advantage.
• Animation Clips, the Animator and Timeline. If your interface has keyframed motion, cutscene-driven UI, or anything authored on a timeline, this is the system that supports it directly. This alone decides a lot of action games.
• Serialized events. Wiring a button to a method in the Inspector is how most Unity teams already work, and it keeps designers able to connect things without an engineer.
• Fifteen years of ecosystem. Every asset, every tutorial, every Stack Overflow answer, every contractor. When you hire someone for two weeks, uGUI is what they will already know.
• Everything else in your project already works this way. Prefabs, prefab variants, layers, sorting, physics raycasts, your existing tooling.

Where UI Toolkit wins

• Styling at scale. USS selectors mean a change to a colour, a corner radius or a type scale happens once and lands everywhere. In uGUI the equivalent is a theming system you have to build yourself, and most teams do not.
• Heavy, data-driven screens. Runtime data binding connects UI elements to game data without a wall of boilerplate, and virtualised lists handle thousands of rows without instantiating thousands of objects.
• Performance under element count. Unity 6 brought jobified mesh generation, parallelised text generation and much faster event dispatch. On a screen with hundreds of elements this is a real difference, and it is exactly where uGUI's canvas rebuilds hurt, as covered in why your Unity menus tank the frame rate.
• Custom shaders, materials, vector graphics and textureless elements. Backgrounds, gradients and shapes that cost you an atlas slot in uGUI cost you nothing here.
• It is where the development is. uGUI is stable and maintained; UI Toolkit is where new features land. Over a five-year live game that gap compounds.

The hybrid most teams land on

The two systems coexist in one project, and this is not a compromise, it is often the correct architecture. The split follows the strengths above almost exactly.

The cost of the hybrid is real and worth naming: two sets of components, two styling systems, two ways of doing states, and a design system that has to be expressed twice. Budget for that rather than discovering it. If your game is small, one system for everything is usually cheaper than the perfect split.

What changes for the designer

This is the part that rarely gets discussed, and it changes what a handoff has to contain. The design work is the same. The deliverable is not.

The practical consequence: on a UI Toolkit project the handoff should be a style sheet and a component spec, and on a uGUI project it should be annotated screens plus a prefab structure. Handing a Unity team the wrong one is how a design gets reinterpreted. The full package for each is in designing game UI for Unity.

Both systems will render your design. Only one of them will let your team change it in a year without opening every screen.

Migration: what it actually costs

Porting an existing uGUI interface to UI Toolkit is not a conversion, it is a rebuild with a reference. Nothing transfers automatically: no prefabs, no Animator states, no serialized event wiring, no scripts that touch RectTransforms.

1. The design survives. Layouts, hierarchy, spacing and art all carry over conceptually, which is the majority of the thinking.
2. The assets mostly survive. Sprites and atlases are used by both, and some backgrounds can be deleted entirely once USS can draw them.
3. The wiring does not. Every button hookup, every animation, every script that reaches into the hierarchy needs redoing.
4. Budget by screen count, not by ambition. A rough rule from projects I have seen: a straightforward screen is half a day to rebuild, a systems screen with lists and states is two to three days.
5. Do not migrate mid-production. The two moments that work are before UI production starts, and between major releases on a live game.

Five questions that decide it

1. 01

   Does your interface have keyframed animation?

   If cutscenes, Timeline or Animation Clips drive interface, uGUI is the direct path. Motion in UI Toolkit is done with transitions and code, which is fine for menu polish and awkward for authored sequences.

2. 02

   How many elements are on your busiest screen?

   Dozens, either works. Hundreds, or a list of thousands, UI Toolkit's virtualisation and batching pull ahead sharply.

3. 03

   Who maintains it, and for how long?

   A six-month project with contract engineers favours what they already know. A live game with years of content favours the system with styling at scale.

4. 04

   How much of the interface lives in the world?

   Both handle world space now, but if most of your UI is anchored to scene objects, uGUI's in-scene authoring is a workflow advantage every single day.

5. 05

   What does your team actually know?

   The most overlooked input. A team fluent in uGUI shipping in nine months will beat the same team learning a new system, no matter which one is technically better.