RosettaUI: a development menu for Unity that you build from code

The menu is a C# expression, not a prefab tree

RosettaUI is described as a code-based UI library for development menus for Unity, and the whole idea sits in the word based. Instead of assembling a canvas in the editor and wiring references by hand, you describe the interface as a tree of elements in C# and the package builds it for you at runtime.

The example in the README is a complete one rather than a fragment. A MonoBehaviour holds a few fields, finds a RosettaUIRoot component in its Start method and calls root.Build(CreateElement()), and the element itself is a nested expression:

    Element CreateElement()
    {
        return UI.Window(nameof(ExampleSimple),
            UI.Page(
                UI.Field(() => stringValue),
                UI.Slider(() => floatValue),
                UI.Row(
                    UI.Field(() => intValue),
                    UI.Button("+", () => intValue++),
                    UI.Button("-", () => intValue--)
                ),
                UI.Field(() => colorValue)
            )
        );
    }

The API is small and deliberate. UI.Window takes a title, UI.Page groups content, UI.Field takes a lambda that reads a field, UI.Slider does the same for a float, UI.Button takes a label and an action, and UI.Row arranges widgets side by side.

The lambdas are the interesting part of that surface. A field is bound to a closure rather than to a serialised reference, and that is what makes the interface editable while the game is running and what makes the undo and redo feature possible at all. The buttons in the example mutate the captured fields directly, with an increment inside the lambda.

For a developer tool, this is a real difference from the prefab approach. The menu becomes source code that a colleague can read, diff and reuse, and the same expression that describes a control also describes how it is edited. Nothing in the README is a screenshot of an inspector; the interface is a value you return from a function.

Undo and redo, and a runtime editor for curves

The features list is short, and two of the items are the reason to look at this package rather than build a menu yourself.

Undo and redo support is marked as runtime only, and the tips section says users can register custom undo and redo actions, with a scene called ExampleUndo to try it in. In a runtime development menu, undo is not decoration. A slider that changes a value needs to be revertible, otherwise a session of tuning leaves your configuration in a state nobody intended, and a menu that cannot undo is a menu you will be afraid to touch.

The second feature is an inspector-like visual editor for Gradient and AnimationCurve at runtime. That is the item that separates this from a generic widget toolkit, because both of those are engine types with their own inspectors, and rebuilding a curve editor inside a generic UI library is a substantial piece of work that most projects end up not doing at all.

The third is Inspector-compatible copy and paste, which means values copied out of a RosettaUI field can be pasted into the ordinary Unity Inspector, and the other way round. For a development menu that is meant to mirror inspector semantics, that removes a whole category of friction for anyone used to working in the editor.

So the package is not really a widget library. It is a way to build a development interface that behaves like the editor you already know, from code, at runtime, and the two headline features are the two things the ordinary inspector gives you for free and a runtime menu usually does not.

Installing through a scoped npm registry, and the version 2 change

Distribution uses the Unity scoped registry feature, so the install has two parts. First you register the registry in the editor, through Edit, then ProjectSettings, then Package Manager, then Scoped Registries, entering a name, the npm registry URL and the scope you want to claim:

"name": "fuqunaga",
"url": "https://registry.npmjs.com",
"scopes": [ "ga.fuquna" ]

Then in the Package Manager window you select MyRegistries, then fuqunaga, then RosettaUI, and click Install. The package identifier used in the manifest and in the release tags is ga.fuquna.rosettaui, with a separate ga.fuquna.rosettaui.uitoolkit package for the version 1 line.

The version 2 migration is the part to read before upgrading anything. The README asks you to remove the RosettaUI.UIToolkit package from the Package Manager, because in version 2 that package is included in the RosettaUI package. Anyone who installed both would otherwise end up with two copies of the same UI code in a project.

There is a behavioural change in the same release that is easier to miss. If you use Keyboard.current.onTextInput, be aware that it now also fires during UI operations, and the README suggests considering KeyControl, for example Keyboard.current[Key.A].wasPressedThisFrame, as an alternative. That is the kind of change which does not throw an error, it just means your shortcut fires twice or fires in the wrong context.

The package also recommends the Input System, with a pointer to the official installation documentation, and describes it as optional, which is slightly at odds with the recommendation. The README also points at the project wiki for the full documentation and says the examples are available in the repository, with a recommendation to download and try them.

Input is suppressed while the menu has focus, and the escape hatch

The tips section describes a behaviour that is easy to miss and expensive to debug. During UI operations, input to the application is suppressed by replacing the keyboard, pointer and mouse devices with dummies, and the example shows the pattern a game would use:

// false while RosettaUI focused
if ( Keyboard.current[Key.A].wasPressedThisFrame )
{
    // do something
}

The check is on the specific key rather than on the device as a whole, which is the recommended pattern, and the warning that follows is the part to hold on to: the Keyboard.current.onTextInput event will still be called even though the rest of the input is suppressed.

For the legacy input system, the README points at RosettaUIRoot.IsFocused():

if ( !RosettaUIRoot.IsFocused() && Input.GetKeyDown(KeyCode.A) )
{
    // do something
}

The mechanism explains why the version 2 change to onTextInput matters so much. The package is already taking over the keyboard device, so an event that fires on text input can no longer be assumed to mean the user typed into the game, and the fix suggested in the migration notes is to stop listening to the device-wide event and listen to a specific key instead.

For a development menu this behaviour is what you want. Your game does not need to move the character while you are typing a value into a text field, and the price of that is one call to check focus in your own input code, which is exactly the pattern the README shows. The trade is that every project that owns an input handler has to remember to add the check, and the README does not say the check is enforced for you.

Platform support is a Windows story, and IL2CPP is out

The environment table is short and worth reading in full, because it sets the boundary of the package.

Windows is supported. Mac is maybe, not tested. Linux is maybe, not tested. IL2CPP is not supported.

The IL2CPP exclusion is the one that matters most for a shipping project, because IL2CPP is the scripting backend used for iOS and for console builds and for many mobile release configurations, and a package that cannot run under it cannot ship to those platforms. A development menu is at its most useful on a device, and a device build is often an IL2CPP build, so the two facts collide in exactly the place you would want the tool.

The untested Mac and Linux entries are a milder concern, since the package is mostly C# with UI Toolkit rendering underneath, but untested is untested and the README is honest about it rather than claiming a cross platform story it has not verified.

The rest of the repository layout is what you would expect for a Unity package. There is an Assets directory, a Packages directory, ProjectSettings, a RosettaUI.sln.DotSettings file, a release-please-config.json with a .release-please-manifest.json, so releases are cut by release-please rather than by hand, a .idea directory and a .github directory.

The licence is MIT, with the file at the repository root, which for a package that ships as compiled assets alongside your game is about as simple as it gets. The related libraries section points at PrefsGUI, the author's own package for accessing persistent preference values through a JSON file, which is a reasonable companion for a development menu that writes settings, and the last push to the repository was on 2026-05-07, with the newest release tag from the same day.

Editorial conclusion

Adopt RosettaUI if you build Unity tools or debug menus and want the interface to be code you can version, review and extend rather than prefabs that drift, especially if you also need a runtime editor for gradients or animation curves. Do not adopt it if you need IL2CPP support, because the environment table lists it as not supported, and do not expect macOS or Linux to be a tested configuration since both are marked as maybe and not tested. Verify first that your project uses the new Input System, since the package recommends it and the legacy path is only covered through RosettaUIRoot.IsFocused(), and that you follow the version 1 to version 2 migration, because the UIToolkit package is now included in the main package and the keyboard onTextInput event now fires during UI operations.

Frequently asked questions

Official sources

1. fuqunaga/RosettaUI on GitHub
2. Issues
3. License: MIT
4. README
5. Releases