Hey folks,

Quick background on why this exists - It was that`RectTransform`, anchors and Layout Groups never felt **intuitive** to me. The simplest intentions turned into a puzzle every time:

* how do I make an element take **50% of its parent's width**?
* how do I keep something at a **fixed aspect ratio**?
* how do I let one element **soak up the leftover space** next to a fixed one?
* how do I just put a few things **in a row with a gap** between them?

To answer those you reach for a pile of separate pieces - anchors and pivots, `HorizontalLayoutGroup`, `VerticalLayoutGroup`, `GridLayoutGroup`, `LayoutElement`, `ContentSizeFitter`, `AspectRatioFitter` \- and you memorize which combination produces which behaviour. I didn't want to **juggle ten components just to say "a row, evenly spaced"**. I like uGUI and I've got projects on it, so leaving it wasn't the plan - I just wanted to state the intent directly and have the layout follow.

# How it works

To put an element under the layout engine you add **one component**, and each of those questions becomes a single setting on it: 50% width is **Percentage**, a fixed ratio is **Aspect**, "take the leftover space" is **Fill**, size-to-content is **Hug**, and "a row with a gap" is a **Row** layout with a **Gap** value.

So you pick a **sizing unit** per element (`Pixels`, `Hug`, `Fill`, `Percentage`, `Aspect`) and a **layout type** (`row`, `column`, `grid`, `absolute`, `custom`) - and that's the whole model. No stacking LayoutGroups, no anchor math, no fitter combos to remember. Virtualized **ListView / GridView / ScrollView** ship as their own components built on top of that same base. Because sizing is expressed relatively it also reflows cleanly across resolutions - a side benefit, not the reason I built it. It runs alongside your existing uGUI, so there's **no migration and no new UI system to learn**.

# Under the hood

I built the solver as a standalone, **engine-agnostic core** rather than wiring it into uGUI - I wanted to solve layout once, so moving to UI Toolkit later wouldn't mean redoing it. A thin **adapter** maps the result onto `RectTransform`, and keeping the core decoupled means I can test the layout logic in isolation.

I didn't invent the algorithm - the shape follows the **Subform** layout model and **Morphorm**, its Rust cousin: a two-pass tree walk, not a constraint solver. A **bottom-up pass** computes `Hug`/intrinsic sizes from content upward, then a **top-down pass** hands each parent's leftover space to its `Fill`/`Percentage` children and sets positions. Each node carries a unit per axis, which is why "50% of the parent" is one property instead of a component stack.

Because that core is a flat array of blittable structs, the whole pass runs through **Burst** \- single-threaded, but measurably faster and **zero-GC** (numbers below).

**Where it's at:** uGUI is what's shipping. The same core also runs in a proof-of-concept for **IMGUI and UI Toolkit** \- it works, but it's not production-ready, more a someday direction than a promise.

# A few numbers

*(Apple Silicon, in the Editor; timing only the layout pass, not GameObject instantiation.)*

The **headless core** is quick and allocation-free - it solves a \~1,000-node tree in **0.12 ms** (and \~2,400 nodes in **0.29 ms**), near-linear, **zero GC**. Turning **Burst off** and running the same solve on the managed fallback is **\~6x slower**, so the compiled core is doing real work.

Through the **uGUI adapter** (which also writes every `RectTransform`), here's a forced full re-layout vs the exact same hierarchy built from Unity's own Layout Groups:

|Same hierarchy, full rebuild|AutoLayout|Native uGUI|
|:-|:-|:-|
|Nested rows, \~840 nodes|5.7 ms|13.6 ms|
|Deeply nested, \~1,000 nodes (9 levels)|7.4 ms|22.5 ms|
|Grid, \~840 cells|5.6 ms|5.6 ms|

So \~**2x faster** than nested Layout Groups, widening to \~**3x** once you nest deeply (where uGUI's rebuilds cascade), and a **tie** with `GridLayoutGroup` \- Unity's one lean fixed-cell component, which is fair given AutoLayout's grid also does tracks, spanning and auto-flow.

**Caveats:** forced full rebuild on both sides, one machine; AutoLayout also has incremental rebuilds these tests don't use, and numbers vary by hierarchy.

# Try it

**WebGL demo (go break it):** [https://autolayoutpro.com/demo](https://autolayoutpro.com/demo) \- it doesn't show off everything yet, it's a work in progress I'll keep expanding. It's built entirely in code with the `FluentUI` API, and I'll put the demo project on GitHub as a worked example.

More info / screenshots: [https://autolayoutpro.com](https://autolayoutpro.com) *(on the Unity Asset Store as "AutoLayout PRO for uGUI").*

# 🎁 Launch giveaway - 5 copies

To enter, **just leave a comment**. I'll draw 5 winners at random with redditraffler this weekend and post the results back in this thread; winners get a code via DM. **Closes Saturday, August 15th, 12:00 PM GMT.**

# A few things I'd genuinely like to discuss

* Are you **staying on uGUI or moving to UI Toolkit**, and what's driving that for you?
* What's your **worst uGUI layout headache** right now - anchors, juggling LayoutGroups/fitters, nested groups, something else?
* If you poke the demo, **what's your first impression, and what breaks?**
* Is there any 

Thanks, and good luck!

[Giveaway] AutoLayout PRO - uGUI layout is tedious, so I built a layout engine to fix it without leaving uGUI (comment to enter)