Skip to content

Migrate to Tick UI

This guide helps teams coming from Unity's UGUI, UI Toolkit, or another immediate-mode library. It maps your previous mental model to the Tick UI model, and flags the patterns that translate cleanly and the ones that need a rethink.

This guide is breadth-first. Read the Introduction to immediate-mode GUI first if the model is new.

From UGUI

UGUI builds a hierarchy of GameObjects, each with components like RectTransform, Image, Text, and Button. State lives in the hierarchy; the application mutates it.

What translates cleanly:

  • Rect-based layout. UGUI's anchor-and-pivot model maps to Tick UI's edge and inset helpers. InsetTopRight and Anchor: top right are the same intent.
  • Hit-testing regions. Button and Textbox work the same way conceptually.
  • Z-ordering. UGUI's sibling order maps to Tick UI's per-panel layer order.

What does not translate:

  • Prefabs. Tick UI has no widget tree, so there are no prefab variants. Reuse is by extracting C# methods.
  • The Hierarchy and Inspector workflow. Editor tooling does not show Tick UI screens. The Gallery sample replaces visual preview.
  • The Canvas and Anchors model. Tick UI uses the rect stack and reference resolutions. For the model, refer to Coordinate spaces.
  • Data binding. UGUI updated bound values automatically. Interlude UI reads your data each frame instead. For the pattern, refer to State.

Suggested migration path. Replace one screen at a time. Start with screens that have minimal designer involvement (debug overlays, internal tools). The HUD and main-menu screens land last because they tend to involve multiple stakeholders.

From UI Toolkit

UI Toolkit builds a VisualElement tree from UXML or C#, styles it with USS, and binds data via IBinding and friends.

What translates cleanly:

  • Declarative composition. Tick UI's top-down DoUI reads similarly to a USS-styled UXML tree.
  • The layout-and-style split, in spirit. Tick UI splits layout (the rect stack) from style (the colour and shape draw calls); UI Toolkit splits more aggressively but the mental shape is similar.

What does not translate:

  • USS. Tick UI has no stylesheet language. Style is C# code in the same place as the layout.
  • The visual tree. Same as UGUI: there is no tree.
  • Bindings. Read your data each frame. For the pattern, refer to State.
  • The Editor previewer. UXML preview does not apply; rely on the Gallery sample and runtime preview.

The mental shift is smaller than UGUI's, but the ergonomic shift is larger because you write more imperative code.

From Dear ImGui (the C++ library)

The closest fit. Most patterns map directly:

Dear ImGui Tick UI
ImGui::Button("Save") ui.Button("save")
ImGui::PushID(i) / PopID() ui.PushID(i) / ui.PopID()
ImGui::BeginChild("settings") ui.BeginPanel("settings", rect)
Channels (SplitChannels) Layered draws via the planned PushLayer (refer to Drawer and batching)

Differences:

  • Layout. Dear ImGui places widgets at the cursor. Tick UI pushes rects on a stack. The rect-stack model is more composable, and takes a few screens of code to internalise.
  • Styling. Dear ImGui uses style stack pushes for colour and spacing. Tick UI passes colour and spacing as direct arguments to draw calls.

General migration pitfalls

Per-frame allocations. : Patterns that worked in retained-mode UI (build a list, hand it to a layout system) become per-frame GC pressure when they run from DoUI. Audit allocations early.

Where widget state lives. : In retained-mode UI, the widget tree owns its own state. In Tick UI, your application owns it and reads it each frame. Refer to State for the patterns.

Editor-only tooling expectations. : The Hierarchy and Scene views do not show Tick UI screens. The Gallery sample, the TICK_DEBUGGER overlay, and runtime preview replace those workflows.

Additional resources