uGUI or UI Toolkit? A Practical Unity 6.5 UI Selection Guide

Choosing a UI system in Unity is not a simple "new UI Toolkit versus old uGUI" decision. Unity gives us three major options:

• uGUI: GameObject- and Component-based runtime UI.
• UI Toolkit: UXML, USS, and C# for runtime and Editor UI.
• IMGUI: immediate-mode UI such as OnGUI.

Unity's 6.5 comparison still lists uGUI as the recommended general-purpose runtime UI, UI Toolkit as the runtime alternative, and UI Toolkit as the recommended Editor UI. That does not mean every runtime screen should use uGUI. A HUD, a 500-row inventory, a virtual joystick, a world-space panel, and an XR menu have different constraints.

This article uses two stages: first apply hard gates for version, render pipeline, input, XR, animation, and must-pass requirements; then compare only the surviving candidates using soft preferences and identical prototypes.

Version scope: rechecked September 9, 2026. The article targets Unity 6.5 and uses 6000.5.11f1, the latest 6.5 patch then listed in the Unity Download Archive. Unity 6.3 LTS is included where its world-space workflow differs. Input System is 1.20.0; XR Interaction Toolkit is 3.6.0. In production, pin ProjectVersion.txt and packages-lock.json and rerun the tests.

The short answer

A useful default is: gameplay-, GameObject-, and keyframe-heavy UI favors uGUI; data-, list-, and style-heavy UI favors UI Toolkit; Editor tooling favors UI Toolkit; IMGUI stays narrow. Hard gates override that default.

Apply hard gates before preferences

Record the Editor patch, packages, SRP, input route, build, and device before judging a result.

What each UI system is good at

uGUI: scene-oriented runtime UI

uGUI is built around Canvas, RectTransform, Image, TextMeshProUGUI, Button, Scenes, and Prefabs. It fits Inspector/Prefab/Animator/Timeline workflows and is a strong default for HUDs, reward popups, combat indicators, virtual sticks, and heavily animated menus. Its main risk is architectural: logic and update work can spread across Prefabs, MonoBehaviours, Layout components, and Canvases.

UI Toolkit: structure, style, and retained state

UI Toolkit uses UXML, USS, and C#. Its Flexbox-style layout is based on Yoga layout principles. It is attractive for inventories, filters, tables, settings, design systems, and repeated data; ListView is particularly useful for large reusable lists. UXML/USS are not identical to HTML/CSS: Panel Settings, events, atlases, supported properties, and runtime features remain Unity-specific and version-sensitive.

IMGUI: keep it narrow

private void OnGUI()
{
    GUILayout.Label($"Enemy Count: {_enemyCount}");
}

This is fine for a display-only diagnostic or small existing Editor tool. For product UI or a long-lived interactive Player tool, uGUI or UI Toolkit usually gives a safer input, styling, reuse, and accessibility path.

Runtime and Editor are different decisions

For runtime UI, uGUI and UI Toolkit are both candidates after the hard gates. Unity 6.5 still recommends uGUI overall, while UI Toolkit can fit data- and style-heavy screens better.

For Editor UI, start new Editor Windows and Custom Inspectors with UI Toolkit. A small stable IMGUI Editor tool does not need a rewrite. Editor IMGUI is also separate from Player OnGUI compatibility with the Input System.

Unity 6.3 and 6.5 use different world-space workflows

If you are on 6.3, do not search for a PanelRenderer from the 6.5 workflow. Use UIDocument.rootVisualElement and the 6.3 UI Document path.

VisualElementReference<T> is a 6.5 runtime feature for PanelRenderer; it is not a universal replacement for UQuery in Editor UI or legacy UIDocument setups.

Unity 6000.5.0f1 also added Animator/legacy Animation support for PanelRenderer content. That does not make UI Toolkit a general equivalent of uGUI's Animation Clip/Timeline workflow. If existing Timeline-authored UI is a hard requirement, favor uGUI unless a prototype proves the required path.

World-space UI Toolkit also does not integrate with 2D Sorting Layers. Use camera-relative z distance, sibling sortingOrder where applicable, and GameObject Layers plus camera culling. A design that depends on SpriteRenderer-style Sorting Layers needs a different plan.

World-space rendering is not XR controller input

A panel rendering in 3D space does not prove that a tracked VR controller can operate it.

Standard Input System tracked input

Input System 1.20 documents tracked UI input using InputSystemUIInputModule, tracked position/orientation actions, and TrackedDeviceRaycaster on a Canvas. That is the standard tracked uGUI route.

UI Toolkit is different: Input System 1.20 states that tracked-type XR input is not supported with UI Toolkit, and UI Toolkit does not support TrackedDeviceRaycaster because it performs its own raycasting.

InputSystemUIInputModule
  + trackedDevicePosition / trackedDeviceOrientation
  + TrackedDeviceRaycaster

Do not copy that Canvas route into UI Toolkit.

Panel Input Configuration

Unity 6.5 Panel Input Configuration handles Event Camera, Physics Layer, maximum distance, and EventSystem redirection, and can create helpers such as Panel Event Handler, Panel Raycaster, and World Document Raycaster.

Its screen-based pointer route converts screen position through an Event Camera into a world-space ray. By itself, it is not a tracked XR-controller solution. World Document Raycaster is also not the Input System's TrackedDeviceRaycaster.

XRI 3.6 dedicated UI Toolkit integration

This is what keeps UI Toolkit viable for VR. Pin XRI 3.6, import the World Space UI sample, follow that package's setup, and validate on hardware. Test Ray, Poke, both controllers, focus, colliders, modal behavior, and latency. If uGUI and UI Toolkit coexist, also test event routing and focus ownership.

The Unity 6.5 core manual and the XRI 3.6 sample can use different component arrangements. Follow the exact sample for the pinned package rather than mechanically replacing its components with names from newer core documentation.

Layout and information density

For a fixed combat HUD, uGUI anchors and RectTransforms are often enough, especially when the project already has Safe Area helpers, localization Prefabs, tween scripts, and animation assets.

For search, filters, multiple panes, reusable themes, text scaling, or hundreds of rows, prototype UI Toolkit first. ListView is built around reusable items; a naive uGUI list with hundreds of active GameObjects usually needs explicit pooling and careful layout design.

The real comparison is not "Flexbox versus RectTransform." It is the cost of the actual screen under realistic content.

Animation and shaders

If UI artists repeatedly tune Animator Controllers, Animation Clips, Timeline tracks, tween components, or UI particle assets, uGUI usually matches the production workflow better. UI Toolkit has USS transitions, class-driven state changes, and 6.5 PanelRenderer-specific animation, but that does not guarantee parity with an established uGUI pipeline.

Ask: who changes the animation, in which tool, and how often?

UI Shader Graph is URP-only

Unity 6.5 UI Shader Graph is a URP feature.

• URP: prototype with the real masks, stencil behavior, blending, world-space setup, and target GPUs.
• Built-in/HDRP: remove UI Shader Graph from the plan and validate another custom Material/Shader route.

Render Pipeline belongs in both the hard-gate table and every benchmark record.

Input

Virtual sticks, multi-touch gestures, EventSystem extensions, and Virtual Mouse generally push the decision toward uGUI. Input System 1.20's Virtual Mouse path is for uGUI rather than a general UI Toolkit/IMGUI cursor abstraction.

UI Toolkit also distinguishes pointer and navigation events. A pointer click raises ClickEvent; a gamepad submit uses navigation events. For a Button that should activate through either path, Button.clicked can be a better semantic hook than listening only for ClickEvent.

Prototype focus order, device switching, focus restoration after a modal, drag/scroll, IME, software keyboard, local multiplayer, and back/cancel routing.

Runtime IMGUI with the Input System

Input System 1.20 documents IMGUI as incompatible with the Input System package in the Player path. A display-only OnGUI overlay can still be useful, but an interactive Player debug menu should not silently assume Input System-only will work.

You can test Active Input Handling = Both, but then verify duplicate processing and performance. Long-lived interactive Player tools are usually better in uGUI or UI Toolkit. Editor IMGUI is a separate case.

Localization and accessibility

Do not choose from an English mockup alone. Where relevant, make maximum text length, RTL, fallback fonts, 200% text scaling, non-color-only states, keyboard operation, and platform assistive technology must-pass requirements.

Unity's Accessibility Hierarchy still needs deliberate names, roles, states, focus, and dynamic updates. Neither UI system makes accessibility automatic; validate on the target OS with the target assistive technology.

Performance: benchmark the update pattern, not the brand

Use the same device, data set, animation, render pipeline, and Graphics API.

For uGUI, Unity's optimization guidance emphasizes reducing expensive Canvas rebuilds, avoiding unnecessary layout work and raycast targets, and splitting Canvases by update behavior rather than arbitrary counts. Pool large repeated lists.

For UI Toolkit, test real ListView reuse, transforms, Dynamic Atlas, masks, transparency, and panel organization. Do not claim "more panels are always slower." Capture UI Toolkit-related Profiler data instead.

Predefine the metrics and aggregation: CPU time, GC allocations, draw calls, memory, first-open time, open spike, scroll p95/worst, and input response. A benchmark without a fixed measurement interval is not reproducible.

Mixing uGUI and UI Toolkit

Mixing is possible, but creates two focus systems, styling models, ordering rules, modal interactions, input-blocking concerns, and extra QA. Prefer screen/navigation boundaries: for example, "HUD is uGUI; inventory is UI Toolkit." Avoid alternating technologies inside one dialog.

Use a navigation service or presenter layer between systems rather than letting one hierarchy manipulate the other directly.

Keep game logic outside the View

A migration becomes expensive when the View owns inventory rules, purchases, networking, saves, analytics, and transitions. Put a small interface at the boundary:

public interface IInventoryView
{
    event Action<int> ItemSelected;
    void SetItems(IReadOnlyList<InventoryItemViewModel> items);
    void SetGold(int value);
}

A presenter can depend on this interface and game-side services. Migration is not free, but the blast radius is smaller when the View implementation changes.

A reproducible selection process

1. Freeze the test matrix

Record the exact Editor patch, package versions, SRP, Build Target, backend, Graphics API, device/OS, resolution, refresh rate, and thermal/power state. Different matrices are different tests.

2. Apply hard gates before soft preferences

Reject unavailable components, unsupported pipelines, unusable input routes, and failed product requirements first. Preserve evidence for rejected candidates. Only surviving candidates should be compared for team skill, authoring speed, layout, animation workflow, maintenance, and migration cost.

3. Resolve conflicts deterministically

1. Evaluate hard gates per candidate.
2. If the UI can split at a screen/navigation boundary, prototype that mixed design including focus, modal, ordering, input blocking, and transitions.
3. Otherwise compare uGUI and UI Toolkit on the same screen, build, data set, device, and input sequence.
4. Only candidates whose complete must-pass set is pass enter the final cost/performance comparison.

Pre-register the next action: unknown means retest; any fail means no-adopt; both candidates failing means revise-requirement; one passing candidate can be adopted; two passing candidates are compared against a predefined equivalence band. A tie requires a more discriminating fixture, then a pre-registered final tie-breaker such as migration cost. Do not invent a metric after seeing the result.

Prototype count is determined by coverage, not by a fixed number. Add fixtures for uncovered XR, RTL/text scaling/accessibility, mixed-stack focus/modal/back, shader/SRP, or mobile requirements. Every must-pass ID needs at least one procedure and one evidence artifact.

4. Keep candidate records and the ADR separate

A candidate record should be immutable and reproducible:

record-id: TR-UI-CMP-QUEST-UGUI-01
comparison-id: UI-CMP-QUEST-INVENTORY
candidate: ugui

environment:
  unity: 6000.5.11f1
  project-commit: <git-sha>
  build: {target: Android, backend: IL2CPP, sha256: <sha256>}
  rendering: {pipeline: URP, graphics-api: Vulkan}
  device: {model: Meta Quest 3, os: <version>, refresh-hz: 90}

fixture:
  dataset: {path: Tests/UI/inventory-500.json, sha256: <sha256>}
  input-sequence: "open -> scroll -> modal -> left/right ray -> poke"
  random-seed: 48151623

measurement:
  warm-up: 10
  trials: 30
  interval: "inventory-ready through end of scripted sequence"
  outlier-policy: "none; preserve all trials"
  aggregation: [median, p95, worst]

must-pass:
  - id: FUNC-FOCUS-001
    criterion: "Modal close restores previous focus"
    procedure: "Select item 3, open/close modal, continue navigation"
    expected: "Navigation resumes from item 3"
    actual: "30/30 restored focus"
    status: pass
    evidence: {path: Tests/UI/evidence/focus.mp4, sha256: <sha256>}

Each requirement needs criterion, procedure, expected, actual, pass|fail|unknown, and evidence. Any fail or unknown makes the candidate ineligible. Also preserve build configuration, package versions, fixture hashes, warm-up, measurement interval, trial count, aggregation, actual metric values/units, and whether each budget is an example or an approved threshold with its basis and approver.

The ADR is another file. It links all candidate record IDs/hashes and stores comparison scope, status, owner/date, alternatives, decision, rejection reasons, trade-offs, consequences, open issues, and revisit triggers:

adr-id: ADR-UI-QUEST-INVENTORY
comparison-id: UI-CMP-QUEST-INVENTORY
status: accepted
owner: UI Platform Lead

decision:
  action: adopt
  selected: ugui
  rationale: "All must-pass checks passed; uGUI won outside the predefined band"

revisit-triggers:
  - Unity/Input System/XRI upgrade
  - item count exceeds 1000
  - XR interaction requirements change

The test record answers what happened under a reproducible build. The ADR answers why this option won and when the decision must be reopened.

5. Let content authors test the workflow

Have UI designers or technical artists change copy, spacing, colors, and animation. Record merge conflicts, diff readability, what they can edit without programmer help, and time per representative change. Authoring cost is architecture cost.

Should an existing uGUI project migrate?

Ask whether migration cost can be recovered, not whether migration is technically possible. Benefits can include shared styling, better large-list workflows, flexible layouts, fewer Prefab conflicts, and shared runtime/Editor concepts. Costs include reimplementation, input, focus, animation, localization, analytics, plugins, and regression QA.

Migrate by screen boundary, preferably with an independent new screen. Avoid a broad rewrite when release is near, the current UI is stable, the alleged performance problem is unmeasured, a must-have path is unsupported, or mixed-stack QA is unfunded.

Final audit before adoption

Retest if any of these are true:

• the team chose from "uGUI is obsolete" or "UI Toolkit is automatically faster" without measurement;
• Unity 6.3 UIDocument and 6.5 PanelRenderer workflows are mixed;
• PanelRenderer animation is treated as general Timeline integration;
• UI Shader Graph is assumed outside URP;
• UI Toolkit XR uses standard tracked input or TrackedDeviceRaycaster;
• Panel Input Configuration alone is treated as the XR-controller solution;
• Runtime IMGUI input or mixed focus/modal behavior is untested;
• must-pass evidence, candidate records, thresholds, trial conditions, ADR, or revisit triggers are missing.

In practice: uGUI fits gameplay/keyframe-heavy UI; UI Toolkit fits list/layout/style/Editor-heavy UI; IMGUI fits narrow development UI. Production adoption should follow hard-gate success and reproducible target-device evidence.

References

• Unity Download Archive
• Unity 6.5: Comparison of UI systems in Unity
• Unity 6.3: Create a World Space UI
• Unity 6.5: Create a World Space UI
• Unity 6.5: Reference runtime visual elements in Inspector
• Unity 6.5: Panel Input Configuration
• Unity 6.5: UI Shader Graph
• Unity 6.5: Layout engine
• Unity 6000.5.0f1 release notes
• Unity 6000.5.11f1 release notes
• Unity 6.5: Input System package version
• Input System 1.20: Understand UI system compatibility
• Input System 1.20: Tracked input UI support
• Input System 1.20: Virtual Mouse UI cursor control
• Input System 1.20: Use IMGUI alongside the Input System
• Input System 1.20: Multiplayer UI input
• XRI 3.6: World Space UI sample
• Unity: Optimization tips for Unity UI
• Unity 6.5: ListView
• Unity 6.5: Optimizing UI Toolkit performance
• Unity 6.5: Transitioning from uGUI to UI Toolkit
• Unity 6.5: Accessibility module