# Backends and versions

> How one API runs on Minecraft 1.7.10 to 26.3 - per-version backends, how the library picks one at startup, and what that means for your mod.

URL: https://xichil.dev/docs/xis-mvui/v1/concepts/backends/ · Updated: 2026-11-06 · Applies to: Fabric, Quilt, Legacy Fabric, Forge, NeoForge, MC 1.7.10 - 26.3

Your mod compiles against one API. The library's jars contain a **backend** per GUI era of Minecraft, and at
startup the library picks the one for the running game. You never call a backend.

## How it works

1. **One jar per loader family.** Each release jar bundles the runtime, the API and every backend for its loader
   and version range.
2. **Detection.** When the game starts, the library detects the loader and the Minecraft version.
3. **Selection.** Exactly one backend covers each supported version, and the library logs which one it picked:

   ```text
   [Xi's Multiversion UI Lib] UI backend <backend> for <loader> <version>
   ```

4. **Drawing.** When a player opens a menu, the backend maps each widget to that version's own vanilla widget:
   a `Toggle` becomes the version's option button, a `Slider` its slider, and so on. That's why menus look native
   on every version, and why the API describes widgets rather than drawing.

Where a version has no vanilla equivalent, the backend draws one that looks like it: `Checkbox` uses vanilla's
check box from 1.16 and an equivalent drawing before that, and `MultiLineInput` uses vanilla's multi-line edit
box from 1.19.3 and an equivalent box before that.

## No popups

Every backend can draw a list of entries, so composite widgets are built from entries. A `Dropdown` opens a
picker *screen*, and a `ColorPicker` opens an editor *screen*. There are no floating popups on any version.

## When there is no backend

The library never makes the game fail to start. With no backend for the running game, `register` still works,
the menus are recorded, and nothing is shown. That happens:

| Situation | Log |
| --- | --- |
| a loader and version combination outside the supported range | `No UI backend for …` |
| a Minecraft version newer than the library knows | `Minecraft version unknown: …` |
| a dedicated server | nothing: servers never select a backend |
| `-Dxis_mvui.disable=true` | `Disabled by -Dxis_mvui.disable=true: …` |
| unit tests with only the API jar | nothing: there is no runtime at all |

## What this means for your mod

- **Compile once.** Your menu code is the same source and the same bytecode for every version.
- **New Minecraft versions** are the library's job: a new version needs a library release, not changes to your
  menu.
- **Backend classes in the API** (`UiBackend`, `BackendRegistry`, `BackendDescriptor`, `UiPlatform`,
  `EntryVisitor`, `MenuWorkers`, `TextAreaModel`, `ForcedFailure`) are the contract between the API and the
  library's own backends. Mods don't need them.
- **Public methods on widgets** such as `Toggle.set` or `Slider.setPosition` exist so backends and tests can drive
  widgets. Your mod normally only uses the builders.

## Next steps

- [Build one mod for every loader](https://xichil.dev/docs/xis-mvui/v1/guides/multiversion-mod/index.md): the same idea applied to your own mod.
- [Failure isolation](https://xichil.dev/docs/xis-mvui/v1/concepts/failure-isolation/index.md): what happens when a backend fails.