Development workflow

Once your screen is running, you can edit it in the Game view or work on it in a browser. Use the Game view to try the UI with your game, a browser preview to work without Unity, or a browser connected to Play to inspect live game data.

The steps below use the project from Build your first screen.

Normal Editor loop

Enter Play in your Loom scene, then open UI/src/App.tsx or UI/src/styles.css in your code editor. Save a change to the button text or its styles. Loom’s Vite server updates the UI in the Game view while Play keeps running, so you can adjust the screen and immediately try it in the game.

When you need to change the C# bridge, stop Play first. Edit Assets/Scripts/UIBridge.cs, save it, and wait for Unity to compile. Loom regenerates the declarations in UI/generated/ for you. Update the UI and UI/src/bridge.ts mocks to match, then enter Play again.

For example, adding a bridge property gives the UI another value to read. Removing or renaming one also means updating the places that read it. Run npm run typecheck from UI/ to find those mismatches before trying the screen.

Working with coding agents or a terminal

To work on the screen without running the game, open a terminal in UI/ and start Vite:

npm run dev

Open the URL printed in the terminal. This preview uses the initial values and mock actions in UI/src/bridge.ts. In the click-counter example, pressing the button runs the mock action and updates the browser’s count.

You can leave this terminal running when you return to Unity. During Play, Loom starts a separate Vite server on an available local port. Both servers pick up edits to the same UI files. A coding agent can run the same command when it needs a browser preview of your work.

Connect the browser to Unity

Sometimes you need to see what the UI does with the game running. Enter Play, then open Tools > Loom > Doctor or Tools > Loom > Status Window. Open the live browser URL shown there.

This URL connects the browser to the current Unity session. Click the counter button there and the count changes in both the browser and the Game view: they read the same game state. Use the current URL from Unity when starting a new session; the ordinary terminal URL continues to use mocks.

For inspecting the UI inside the Game view, follow Debugging with DevTools.

When to restart the dev server

Edits to components and styles appear as you save them. After changing Vite configuration, environment variables, or dependency versions, restart the server so it picks up the new configuration.

For the server managed by Unity, use Tools > Loom > Restart Dev Server. For a server you started in a terminal, press Ctrl+C, then run npm run dev again. If a browser still has the old screen open, reload it.

When to restart Unity

After upgrading Loom, fully quit and reopen the Unity Editor before testing Play. This lets Unity load the new version of the package’s native plugin. See Sync UI Dependencies for keeping the UI packages aligned with the Unity package during an upgrade.

Browser-only UI work

As your UI grows, you’ll want to preview states that take several steps to reach in the game. Set the initial values in UI/src/bridge.ts to open a menu or display a particular set of data, then add mock actions for the controls you need to try. Reload the browser preview to start from those values again.

Follow Mock mode for more ways to set up these previews, and use the bootBridge reference to look up its options. Return to Play to check that the screen works with the actual game actions and input.

Player builds

When you’re ready to try the UI in a standalone game, follow Player builds. The player uses the built UI files, so changes made through the development server need a new build before they appear there.