uLayout: a flexbox-style layout system for Unity uGUI

The gap between uGUI layout groups and CSS

uLayout is described as a simple UI layout system designed as a drop-in replacement for Unity's VerticalLayoutGroup and HorizontalLayoutGroup, implementing a core subset of the flexbox spec from CSS.

The starting point is worth understanding, because Unity's built-in groups are not bad, they are just limited. A VerticalLayoutGroup arranges children in a column with a fixed spacing and a padding, and it has no notion of children competing for space, of wrapping, of a child refusing to shrink below a minimum, or of a row where one item should take twice as much room as the next. Every project that needs those things ends up with nested groups and a lot of hand-tuned sizes, or with a layout script of its own.

Two properties define the approach. First, it operates purely on RectTransforms, which means full compatibility with native uGUI components like Image and RectMask2D. Nothing in the design requires a special renderer or a special graphic. Second, it is a drop-in replacement rather than a parallel system, so an existing hierarchy can be converted without rewriting the scene.

The primary language is C#, the licence is MIT, and the package is published to the Unity Package Manager under the name com.pokeblokdude.ulayout, with a version of 1.8.0 in package.json.

The update model is the interesting part

The performance claim in the README is specific about the mechanism. The system only triggers an update when resize events occur, and only the Layout objects which had a child resize are updated.

That is a different contract from Unity's own layout groups, which mark a hierarchy dirty when something changes and rebuild it. Here, a container whose children did not resize is not touched at all, so a screen with fifty panels where one of them changed does not cost fifty layout passes.

The number the author gives is that the demo scene costs around 0.9 ms in a standalone build on his machine, a Core Ultra 7 265KF, with most of that being TMP_Text updates rather than layout work. That is an author-reported figure on one machine, and it is worth reading for what it says rather than as a benchmark: the layout itself is not the expensive part, the text is.

That reading connects directly to the text support section, where the README says resizing text is fairly expensive and that you generally want to avoid resizing text as much as possible at runtime. The layout system is cheap enough that you can leave it alone, but the text measurement inside it is not.

Installing from a git URL or a unitypackage

The Installation section offers the two usual routes for a Unity package.

The first is the Unity Package Manager by git URL:

https://github.com/pokeblokdude/uLayout.git

The second is importing directly into the project with a .unitypackage file, available in the Releases tab of the repository.

The package manifest is small and tells you the rest. Its identity and its one dependency are:

  "name": "com.pokeblokdude.ulayout",
  "displayName": "uLayout",
  "version": "1.8.0",
  "description": "A simple UI layout library for uGUI.",
  "dependencies": {
    "com.unity.ugui": "0.0.1"
  },
  "homepage": "https://github.com/pokeblokdude/uLayout",
  "bugs": {

The single dependency is com.unity.ugui, which is the package that carries Unity's own UI components. So uLayout does not fork uGUI, it sits on top of it.

The manifest also declares the sample, which is where the quickest understanding comes from:

  "samples": [
    {
      "displayName": "Layout Demo",
      "description": "Contains a *very* basic demo of what is possible using uLayout",
      "path": "Samples/LayoutDemo"
    }
  ]

One thing the manifest does not declare is tests. The scripts block contains a single test entry that echoes an error message about no test being specified, which is the placeholder Unity generates for a new package. The repository has a CHANGELOG.md and an Editor and Runtime folder split, but no test suite.

Sizing modes, and the difference between Layout and LayoutItem

Adding the components is a menu action. uLayout components can be quickly added to your scene via GameObject, then UI (Canvas), then Layout, or from the scene view right-click menu.

The core concept is the sizing mode, and every layout element chooses one of three for each axis. FitContent fits the rect tightly around its contents, taking into account padding and internal spacing. Fixed means the rect size is not controlled by uLayout and the pre-defined RectTransform size is used. Grow means the rect grows to fill its parent container, and if the parent is a Layout it uses padding and distributes the grow child size along the primary axis.

That third mode is the one that has no equivalent in Unity's built-in groups, and it is where the flexbox model starts to matter.

There are two components, and the difference matters. LayoutItem is for an object that is not a container: it can ignore layouts and use grow sizing. Layout inherits from LayoutItem and adds the container features. The README also says that FitContent only affects derived classes, so a bare LayoutItem cannot use that mode itself.

The reasoning behind the split is that a child that should ignore the layout entirely should not have to carry the container's configuration, and a project with a mixed hierarchy ends up with both components anyway.

The flexbox properties it actually implements

The Layout component is where the CSS resemblance is strongest, and the README lists the properties in full.

Direction takes four values: Row positions children left to right, Column positions them top to bottom, RowReverse goes right to left and ColumnReverse bottom to top. Justify Content aligns children along the primary axis with Start, Center, End and SpaceBetween. Align Content does the same across the cross axis with Start, Center and End. Align Items places children within their own lines on the cross axis, again with Start, Center and End.

Then the spacing and wrapping controls. Inner Spacing sets the gap between children on the primary axis, and does nothing when Justification is set to SpaceBetween, which distributes the space itself. Wrap decides whether overflowing children go onto a new line, and Line Height is the amount of space between lines when Wrap is true, otherwise it does nothing. Ignore Child Scale says whether the child's RectTransform scale is taken into account when calculating fit size and layout.

The LayoutItem properties are the ones that make it feel like flexbox. Min Width and Min Height are the size an element shrinks to under FitContent or Grow, Max Width and Max Height are the size it grows to, and Flex Width and Flex Height are the relative weights. The README gives the arithmetic: two elements with flexWidth of 1 each get 50 percent of the available space, while 2 and 1 gives 66.6 and 33.3. Margins add a buffer along each edge between an element and its neighbours.

For anyone who has used CSS this will feel familiar, and for anyone who has not, the README points at a flexbox guide as background reading.

Text support is the expensive part

uLayout also supports TextMeshPro TMP_Text objects, using the LayoutText component. This also derives from LayoutItem and offers the same sizing options, which allows text objects to resize depending on contents and font size.

That capability is the reason the performance note earlier matters. The README is direct about it: resizing text is fairly expensive, so you generally want to avoid resizing text as much as possible at runtime.

The practical consequence is a design constraint rather than a bug. A layout that fits its content tightly has to measure its text every time something changes, and text measurement is the expensive part of the operation. If your UI has a text element whose size changes on a timer or on every frame, you are paying the measurement cost every time even though the layout pass itself is cheap.

So the sensible pattern is to let the text size itself once, at startup or on a content change, and leave the layout to react. The LayoutText component derives from ILayoutSelfController, which is the interface Unity uses for elements that tell their own layout how big they need to be, rather than having a parent group ask them.

The examples in the repository are organized around this. There is a Samples/LayoutDemo folder, and the README refers to the sample scene at Examples/LayoutDemo.unity for further explanation and examples.

A young package with an unusually strict contribution policy

The release history shows a package that is being worked on steadily. The recent versions are v1.8.0 from 2026-10-19, v1.7.2 from 2026-09-25 and v1.7.1 from 2026-08-07, and the repository's last push was on 2026-10-19, the same day as the 1.8.0 tag.

A version in the 1.x range with patch releases every few weeks is a project with an active user base rather than an experiment, and the layout of the repository backs that up, with an Editor directory, a Runtime directory, a Samples directory and the .meta files that Unity requires for a package.

The Contributing section is where this project differs from most, and anyone planning to send a pull request needs to read it. Contributions are welcome and greatly appreciated, and the author says he will do his best to review in a timely manner. Then two rules. First, please do not go through and alter existing code style and/or syntax, because it makes changes needlessly difficult to parse and the author says he will simply change it back. Second, please do not submit pull requests with AI-generated code, and the author adds that if he suspects you are using AI, or you do not understand the code you are submitting, he will not take the request seriously.

That is an unusual condition to find in an open source project, and it is stated plainly enough that there is no ambiguity about it. The MIT licence grants the usual rights to use, modify and redistribute the code, so the policy is about how changes arrive rather than about what you may do with the result afterwards.

Editorial conclusion

uLayout fits a Unity project whose UI has grown past what the built-in layout groups can express, especially if the team already thinks in flexbox from web work and wants padding, grow weights, wrapping and per-child margins without writing layout code. It is the wrong choice for a small HUD or a menu with a handful of panels, since the built-in groups cover that case, and it is the wrong choice if you need the full flexbox spec, because the README is explicit that this is a core subset. Verify first which Unity versions your project targets against the uGUI dependency declared in package.json, how your text is set up, since LayoutText relies on TMP_Text, and read the contribution policy before you plan to send a pull request.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pokeblokdude/uLayout on GitHub
4. README
5. Releases