Changelog

Releases

1.0.0

• The first stable Loom GUI release supports Unity 6000.3.0f1 or newer with URP 17.3.0 or newer: Windows x86-64 using Direct3D 11 or Direct3D 12, and macOS Apple Silicon using Metal.
• Added an importable Getting Started sample with a small C# bridge and a guided path from project setup to a running Solid UI.
• Generated TypeScript actions consistently return promises, and the bundled UI starter includes typed mock actions that can update state without Unity.
• Standard HTML inputs and textareas now receive platform-resolved text on Windows and macOS, including shifted, alternate-layout, accented, and committed Unicode characters. Editing keys continue to behave normally.
• Added standard browser Gamepad API support for Unity Input System controllers. Pages can use navigator.getGamepads() and connection events while Unity gameplay observes the same devices. This release reports the standard layout without vibration.
• Added controller menu navigation through NavigationProvider and NavigationScope. Semantic HTML controls are discovered automatically; directional geometry, explicit neighbors, scope stacking, focus restoration, reactive disabled-control handoff, submit/back bindings, and editable-control behavior work without per-button wrappers or customer polling code.
• Configured Loom projects now stop a player build when the UI source, generated bridge files, built index.html, URP renderer feature, target architecture, or graphics API would produce a player without a working UI.
• The Unity package now includes the supported precompiled native plug-ins and matching bridge and Vite tooling. Customer projects do not need the Loom source repository, Rust, or a native compiler.
• Consolidated the Unity Editor commands under Tools > Loom and updated setup, Doctor, native plug-in, and version-mismatch messages with direct recovery steps.
• Added package links to the complete online documentation, changelog, license, and support@snack.onl.
• UI development and player builds require Node.js 22 or 24 LTS with npm 10 or 11. Initial UI setup downloads third-party dependencies from the public npm registry; Loom’s matching packages are bundled with the Unity package.

0.15

• Fixed text inputs and other editable controls sometimes losing focus immediately after being clicked in the embedded UI.
• Added optional keyboard focus navigation through LoomRuntime.KeyboardMode. The default Gameplay mode keeps Tab available to the game without moving DOM focus; Navigation enables normal Tab and Shift+Tab traversal through eligible controls. Keyboard events remain available to Unity in both modes, so games can switch their action map and Loom’s keyboard mode together.
• A Tab key used to open a menu no longer also advances focus into that menu. UI code can request the transition through an ordinary bridge action while Unity remains the authority for keyboard ownership.

0.14

• Unity textures can now appear directly in your Loom UI. Inventory icons, character portraits, texture previews, live minimaps, and camera feeds can come from Texture2D, Sprite, or RenderTexture bridge state. Render the generated LoomImageSource with the new LoomImage Solid component instead of exporting the image to a file or serving it over HTTP.
• Static textures work even when they are non-readable or packed into a Sprite atlas. Live RenderTextures update automatically when their pixels or size change, so a minimap or camera feed does not need repeated bridge assignments. Live sources support Metal, Direct3D 11, and Direct3D 12.
• Browser-only mock scenarios can now fill generated image fields with normal image URLs through createMockImageSource(url). The external Editor browser shows a placeholder for Unity-owned images while the embedded UI renders the real image.
• You can keep a standalone npm run dev server open for mock-mode while entering Play mode. Loom starts its own server on a free loopback port and leaves the standalone process alone.
• Mouse-wheel and trackpad scrolling now moves by the expected distance and preserves smooth fractional input, horizontal scrolling, and Windows Input System scroll ranges.

0.13

• The Unity package identifier is now onl.snack.loom, matching Snack’s registered namespace. Release tarballs are signed so Unity Package Manager can verify their author and contents.
• Fixed generated bridge registration under Unity 6.7.
• Fixed the Loom rendering plugin failing to load on current macOS releases.

Migrate from v0.12 to v0.13.

0.12

• Loom now composites the UI through a URP renderer feature after the final game camera. The UI and loading cover no longer depend on a generated uGUI canvas.
• Loom now presents UI updates in the same Unity frame as the state changes that caused them. When the UI does not change, Loom reuses the last GPU surface instead of repainting it.
• Rendering is GPU-only on Metal, Direct3D 11, and Direct3D 12. Unsupported graphics APIs now fail with a clear rendering error instead of falling back to a CPU pixel upload.
• During a resize, Loom waits for a surface at the new size instead of sampling a stale or stretched UI frame. The loading cover stays visible while the new surface is prepared when the cover is enabled.
• Tools > Loom > Setup UI in Current Scene now installs LoomRendererFeature on every renderer used by the project’s URP quality assets. It rejects quality levels that do not use URP.

Migrate from v0.11 to v0.12.

0.11

• Fixed UI animation stalling in Windows D3D12 projects at high or uncapped frame rates, where the UI could appear to update only after mouse or keyboard input.

0.10

• Fixed Windows players becoming unresponsive after Alt+Tab or minimize/restore while the game continued running in the background.
• D3D12 presentation now keeps synchronization entirely on the GPU. If the next UI frame is still in flight, Loom retains the last completed frame instead of stalling Unity or the UI renderer. Zero-copy rendering is preserved, with no CPU readback or upload fallback.
• Reduced Windows UI presentation overhead by removing a full GPU drain from every UI paint.
• Fixed Vite dev-server color codes appearing as square characters in the Unity Console.

0.9

• Added support for Unity 6.3 through 6.7.
• Fast Enter Play Mode now works reliably when Domain Reload and Scene Reload are both disabled. Retained Loom views start each Play session with fresh rendering, loading, input, and viewport state instead of carrying state over from the previous session.
• Delayed bridge actions and queued work from a stopped Play session can no longer publish into, resolve through, or shut down a newer session.
• Loom now tears down and restores bridge registration cleanly across script recompilation and Unity code reloads.
• Failed or partial runtime initialization is rolled back completely so a subsequent initialization can start normally.

0.8

• Fixed UI freezing on the pre-resize frame after a window resize. Affects both D3D11 and D3D12.
• The UI bridge now recovers across Play -> Stop -> Play without restarting the Vite dev server; pending actions are rejected and the stream reconnects with a state snapshot.

0.7

• Fixed nested state built through object initializers before being attached to the bridge publishing at wrong, unrooted paths. Assigning nested state to a not-yet-attached parent now defers, and everything syncs when the graph is attached to a live bridge property.

0.6

• Fixed snapshot arrays of state objects (e.g. SlotState[] properties) failing to sync.

0.5

• CSS background-clip: text is now supported: fill heading text with a gradient or image.
• Inline SVG fill / stroke now resolve currentColor and var() custom properties, so icons follow your CSS theme colors.

0.4

• CSS backdrop-filter is now supported, blur and other frosted-glass effects on the content behind an element.

0.3

• Fixed player builds getting stuck on the splash screen: the UI could fail to connect to the game in a built player. Editor play mode was unaffected.

0.2

The first public release. Compared to the internal 0.1, authoring a bridge is dramatically simpler.

Migrate from v0.1.x to v0.2.x.

Scene setup

• A single Loom UI component does all the wiring and runtime setup. Drop it into your startup scene (or run Tools > Loom > Setup UI in Current Scene). No hand-written bootstrap, no LoomRuntime.Initialize() / Shutdown() calls.
• Loom constructs and hosts your [Bridge] class (which now inherits LoomBridgeBase). Reach it from gameplay code through the generated UIBridge.Instance.

State

• State is now plain { get; set; } properties and assigning one pushes to the UI.
• ReactiveList<T> / ReactiveMap<K,V> for collections that change often: mutate in place and each insert/remove/element change pushes granularly. Snapshot List<T> / T[] / Dictionary<K,V> also work (reassign to sync).
• Bridge removes the state prefix: bridge.boot.progress instead of bridge.state.boot.progress.
• Built-in loom.* state on every bridge: active scene name, viewport size, device pixel ratio, and connection status, with no declaration. Read it as bridge.loom.*.

Actions

• Actions now support any number of parameters instead of just 0 and 1.
• Bridge removes the action prefix: bridge.goToMainMenu() instead of bridge.actions.goToMainMenu().
• Actions now work on nested state: bridge.boot.setProgress(v).

The UI surface

• The bridge mirrors your C# class 1:1; state, actions, and nested objects live directly on it: bridge.currentScreen, bridge.startGame(), bridge.boot.progress. There is no .state / .actions split.
• Membership is mostly by convention: a public property is state, a public Event<T> is an event. Actions are explicit, tag the method [BridgeAction].
• long / ulong values cross to TypeScript as bigint.

Debugging

• Your UI’s console output (console.log / console.warn / console.error, plus uncaught errors) now appears in the Unity console, prefixed [Browser], so you can see UI logs and errors without opening browser DevTools.
• View and drive the live UI from a separate browser while developing in the Editor, handy for inspecting state and clicking through screens in real DevTools.

Shipping

• Shipped games open no local network port, the UI now talks to your game in-process. (The external-browser debugging above is an Editor-only convenience and is never exposed in a build.)

0.1

Internal pre-release.

Upgrading

See all migration guides.

Versioning policy

• Patch (1.1.0 -> 1.1.1). Bug fixes only. No breaking changes.
• Minor (1.1.x -> 1.2.0). New features. Source-compatible, no breaking changes.
• Major (1.x -> 2.0). Major new features. Breaking source changes, needs migration.

Pre-1.0 versions don’t respect semantic versioning. We use strict versioning starting from 1.0.