Desktop client

Installation

The desktop client is a native application available for Windows, macOS (Apple Silicon) and Linux. The Windows, macOS and Linux installers also bundle the uversion CLI and make it accessible. Download it from /downloads.

Windows

Download uVersion_x.y.z_x64-setup.exe (signed NSIS installer, ~25 MB). When run, the installer:

• Installs the client into %LOCALAPPDATA%\uVersion (per-user, no admin required)
• Adds the install folder to the user PATH (the uversion.exe CLI is bundled there)
• Creates a Start menu shortcut
• Enables auto-update via the Tauri updater

macOS (Apple Silicon)

Download uVersion_x.y.z_macos-arm64.app.zip (~32 MB, signed with a Developer ID and Apple-notarized). Double-click to unzip, then drag uVersion.app into /Applications. On first launch, Gatekeeper automatically validates the notarization, with no warning.

The uversion CLI is bundled inside the app. On first launch, the client automatically creates a symbolic link to ~/.local/bin/uversion and adds ~/.local/bin to your PATH via ~/.zprofile: no manual action required. Open a new terminal and uversion is available.

Note: only Apple Silicon (M1/M2/M3/M4) is supported. No Intel binary.

Linux

Two formats for x86_64:

• AppImage (uVersion_x.y.z_amd64.AppImage, ~76 MB): portable, bundles every dependency (libwebkit2gtk, libgtk, libsoup, etc.). Runs on any Linux distro with no system installation:

  chmod +x uVersion_x.y.z_amd64.AppImage
  ./uVersion_x.y.z_amd64.AppImage

• .deb package (uVersion_x.y.z_amd64.deb, ~5 MB): for Ubuntu / Debian / derivatives. apt resolves the system dependencies:

  sudo apt install ./uVersion_x.y.z_amd64.deb

  The app installs into /usr/bin/uVersion.

Note: the uversion CLI is bundled inside the Linux packages. On first launch, the client copies the binary to ~/.local/bin/uversion and adds ~/.local/bin to your PATH via ~/.profile (no manual action required).

First launch

On first launch, the client shows the login page. Enter:

• Server address: your studio's address (e.g. https://uversion.mygamestudio.com)
• Username and password

Once connected, the client remembers your session securely. The uversion CLI and the editor plugins (Unreal, Rider) automatically reuse the same credentials: you never re-enter your password anywhere else.

Workspace

A workspace is a local folder linked to a server repository. The client can manage several workspaces at once, shown in the tab bar at the top. Each workspace stores its metadata in .uversion/ at the root of the local folder:

• .uversion/config.toml: owner, repo_id, server URL, workspace UUID
• .uversion/checkouts_<workspace_id>.json: locks that YOU hold in this workspace
• .uversion/changelists_<workspace_id>.json: local changelists
• .uversion/.last_sync: last synced revision (for incremental syncs)

Files tab

Tree view of the workspace files with their status. Available filters:

• Search: search by substring in the path (case-insensitive)
• Status filters: Synced, Modified, Local only, Server only, Locked, Deleted

The view stays smooth even on projects with tens of thousands of files.

Multi-select + actions

Select several files (click + shift, or tick the checkboxes) then:

• Checkout: acquires the locks (idempotent; re-checking-out an already locked file is a no-op)
• Sync: re-downloads the selected files (useful if a file is corrupted locally)
• Revert: releases the lock, restores the server version

Pending tab

Files currently checked out, locked by you OR by another user. Two sections:

• Your locks: you can checkin, revert, or release them individually
• Other users' locks: you see who holds the lock + a Request release button that creates a request card in the Production board (a request badge)

Admins also see a Force unlock button on third-party locks, which releases the lock without the holder's consent. Every force unlock is audited.

History tab

Paginated list of the repository's commits, with author, date, message, and changed files. Clicking a commit opens the detail: the full list of the commit's files with their revisions.

A Get all button on each commit downloads a local copy of every file at that revision (useful to recover a stable state).

Production

The Production area (a dedicated entry in the sidebar) gathers project tracking, per repository. It replaced the old Activity and Requests tabs of the Workspace: the Workspace now focuses on files (Files, Pending, History).

My tasks

The list of cards assigned to you, aggregated across every repository you have access to.

Board

Kanban board per repository, with configurable columns (To Do, In Progress, Review, Done by default). Each card carries a priority (low / normal / high / urgent), labels, assignees, a due date, comments, links to assets or commits, and a cover image.

📷 Screenshot · production-request-cards

Request-type cards (badge) in the Review column.

Activity

Unified dashboard:

• 24h KPIs: commits, active submitters, active locks
• Activity calendar: commits per day over several months (heatmap)
• Recent Checkins and Most Modified Directories
• Commit History: paginated commits with filters by user and by path

Watchlist

Watch paths (glob patterns) to be notified of check-ins that touch them. Each entry states the watched path and the tracked events.

Games

The Games area lists the internal playtest builds published for the project. Each build shows its version, its configuration (DebugGame / Development / Shipping), its platform (Win64 / Mac / Linux), its size and its release notes, with a platform-aware download button.

This is the entry point for playtesters: an account with the playtester role sees only this page (neither Workspace nor Production), and only accesses the builds of the projects opened to it.

Local changelists

📷 Screenshot · client-changelists

Checked-out files split across two local changelists (for example 'default' and 'review').

Group your checked-out files into several independent commits. Changelists are local to your workspace (never sent to the server). Useful to:

• Separate a critical fix from work in progress
• Prepare several submissions in parallel without mixing everything up
• Keep a "default" changelist for WIP and a "review" one for what goes into a checkin

Settings

Global client preferences (saved in %APPDATA%/uversion/uVersion/config/config.toml):

Option	Description
Default server URL	Pre-filled on the login page
Username	Pre-filled on the login page
Theme	System / Light / Dark
Show hidden files	Show files starting with . in the Files tab
Auto-sync interval	Off / 5 min / 15 min / 30 min: triggers an automatic incremental sync
Parallel uploads	Concurrency ceiling (1-32, default 16)
Default repos path	Folder proposed by default when cloning

Unreal panel

📷 Screenshot · client-unreal-panel

The Unreal panel with its action buttons: Open Editor, Compile, Package Game and its config choice, Publish Build, Stop.

When the client detects an Unreal project in the workspace (a .uproject file is present), a dedicated panel appears. It drives the engine directly from the client: open the editor, compile, package, without going through an IDE. Most actions only concern C++ projects (a pure Blueprint project does not need to compile).

Engine path

The Unreal version is auto-detected from the .uproject's EngineAssociation (Windows registry, LauncherInstalled.dat, or source build). You can override it manually if detection fails. This path is required for every action below.

Open Editor

Launches the Unreal editor (UnrealEditor) on the workspace project. The button is idempotent: the editor can take several tens of seconds to show its window (especially on macOS / Linux), so a second click during that time does not open a second instance. The button shows "Opening…" while the editor starts. For a C++ project never compiled locally, opening the editor first triggers a project files generation then a compilation (see Automatic actions).

Compile

📷 Screenshot · client-compile-console

The embedded console showing the Unreal Build Tool compilation output in real time.

Compiles the project (Unreal Build Tool). The output shows in real time in an embedded console. A C++ project must be compiled for the editor to open it and to reflect code changes.

Generate Project Files

Regenerates the IDE project files (Visual Studio, Rider). Useful after adding or removing source files, or after a clone. Found in the panel's "…" (more actions) menu.

Package Game

Packages the game via RunUAT BuildCookRun and archives the result into Packages/{config}/ at the workspace root. Three configurations to choose from:

Config	Usage
DebugGame	Debug build (full symbols, not optimized).
Development	Development build (default): optimized but with the dev tools.
Shipping	Distribution build: optimized, without the dev tools.

The Packages/ folder is ignored by default (.uversionignore): the packaged builds are not versioned, they are distributed via Publish Build.

Publish Build

Publishes a packaged build as an internal playtest version. It becomes downloadable by your team from the client's Games page (playtester role or build access granted). The client scans Packages/{config}/, uploads the files (deduplicated server-side) then registers the manifest.

Open project folder

Opens the workspace folder in the system file explorer (Windows Explorer, Finder, or xdg-open on Linux).

Stop

Cleanly stops all builds in progress: compilation and packaging. The button reports how many builds were stopped (an auto compile launched in the background can be counted in).

Automatic actions

Beyond the buttons, the client triggers some Unreal actions on its own, so that a C++ project always stays up to date and compilable:

• Before a check-in: if code files changed, the project is compiled first. If the compilation fails, the check-in is blocked (you do not submit code that does not compile).
• After a sync: if the sync downloaded code, the client regenerates the project files then recompiles.
• On the first launch after a clone (C++ project): project files generation then compilation, before you can open the editor.

These automatic builds serialize on the engine lock (Unreal Build Tool -WaitMutex): they do not refuse each other, they chain up. The Stop button interrupts them too.