Changelog

Releases

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.
• 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 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.