Skip to main content
LiquidLauncher is built using the Tauri framework, combining a Rust backend with a Svelte frontend to create a fast, secure, and lightweight Minecraft launcher.

​
Technology Stack

LiquidLauncher uses a modern technology stack designed for performance and cross-platform compatibility:
  • Backend: Rust with Tauri framework
  • Frontend: Svelte with Vite
  • Communication: Tauri IPC (Inter-Process Communication)
  • Build System: Cargo (Rust) and npm/bun (JavaScript)

​
Tauri Architecture

Tauri provides a hybrid architecture that separates concerns between system-level operations and user interface:

​
Module Organization

The codebase is organized into clear, functional modules:

​
Backend Modules (src-tauri/src/)

​
main.rs

Application entry point that initializes:
  • Logging system (file and console output)
  • Application directories
  • Tauri GUI framework
Relevant code from src-tauri/src/main.rs:64-110:
pub fn main() -> Result<()> {
    // Setup logging with file rotation
    let logs = LAUNCHER_DIRECTORY.data_dir().join("logs");
    utils::clean_directory(&logs, 7)?;
    let file_appender = tracing_appender::rolling::daily(logs, "launcher.log");
    
    // Initialize directories
    mkdir!(LAUNCHER_DIRECTORY.data_dir());
    mkdir!(LAUNCHER_DIRECTORY.config_dir());
    
    // Start GUI
    gui_main();
    Ok(())
}

​
app/

Handles GUI integration and application state:
  • gui/ - Tauri command handlers and window management
  • client_api.rs - LiquidBounce API client
  • options.rs - User settings and configuration
  • webview.rs - WebView utilities

​
minecraft/

Core launcher functionality:
  • launcher/ - Launch process and game setup
  • version.rs - Version manifest parsing
  • auth.rs - Minecraft authentication
  • prelauncher.rs - Pre-launch setup (mods, assets)
  • java/ - Java runtime management

​
auth/

Authentication systems for Minecraft accounts (Microsoft, offline)

​
utils/

Shared utilities:
  • download.rs - File downloading with progress
  • checksum.rs - SHA1 verification
  • extract.rs - Archive extraction
  • maven.rs - Maven artifact resolution
  • sys.rs - System information detection

​
Frontend Structure (src/)

​
App.svelte

Root component that bootstraps the application

​
lib/Window.svelte

Main window component managing application state:
  • Options loading and storage
  • API client setup
  • System checks
  • Update handling
  • Screen routing (Login → Main)

​
lib/main/

Main launcher screens:
  • MainScreen.svelte - Primary interface
  • LaunchArea.svelte - Launch button and controls
  • VersionSelect.svelte - Version picker
  • settings/ - Settings panels
  • log/ - Client log viewer
  • news/ - News feed
  • statusbar/ - Progress indicators

​
lib/login/

Authentication interface:
  • LoginScreen.svelte - Login view
  • loginmodal/ - Login modal components

​
lib/settings/

Reusable settings components (sliders, selectors, inputs)

​
lib/common/

Shared UI components (buttons, tooltips, title bar)

​
Communication Flow

The frontend and backend communicate through Tauri’s IPC system:
1
Frontend Invokes Command
2
User interaction triggers a Tauri command invocation:
3
import { invoke } from "@tauri-apps/api/core";

const options = await invoke("get_options");
4
Tauri Routes to Handler
5
Tauri deserializes parameters and routes to the Rust command handler:
6
#[tauri::command]
pub async fn get_options() -> Result<Options, String> {
    // Handler implementation
}
7
Backend Processes Request
8
Rust code executes system operations, file I/O, network requests, etc.
9
Backend Emits Events
10
For async updates, the backend emits events to the frontend:
11
window.emit("progress-update", &progress_update)?;
12
Frontend Listens for Events
13
Svelte components subscribe to events:
14
import { listen } from "@tauri-apps/api/event";

listen("progress-update", (event) => {
    console.log("Progress:", event.payload);
});

​
Application Lifecycle

1
1. Initialization
2
  • Application starts from main.rs:64
  • Logging system configured
  • Directories created
  • GUI launched via gui_main()
    • 3
    2. Frontend Bootstrap
    4
  • Window.svelte mounts
  • Options loaded from disk
  • API client configured
  • System compatibility checked
  • Update check performed
    • 5
    3. Authentication
    6
  • If no account: Show LoginScreen
  • User logs in (Microsoft or offline)
  • Account stored in options
    • 7
    4. Main Interface
    8
  • MainScreen displays
  • Branches and builds fetched from API
  • User selects version and configures settings
    • 9
    5. Launch Process
    10
  • run_client command invoked (src-tauri/src/app/gui/commands/client.rs:260)
  • Version manifest downloaded
  • Assets, libraries, and mods downloaded
  • Java runtime prepared
  • Game process spawned
  • Logs streamed to UI
    • 11
    6. Post-Launch
    12
  • Launcher hidden (optional)
  • Game output monitored
  • Process termination handled
  • Launcher restored on exit

    • ​
    Directory Structure

    LiquidLauncher/
├── src-tauri/              # Rust backend
│   ├── src/
│   │   ├── main.rs         # Entry point
│   │   ├── app/            # Application layer
│   │   ├── minecraft/      # Minecraft logic
│   │   ├── auth/           # Authentication
│   │   └── utils/          # Utilities
│   ├── Cargo.toml          # Rust dependencies
│   └── tauri.conf.json     # Tauri configuration
├── src/                    # Svelte frontend
│   ├── App.svelte          # Root component
│   └── lib/                # Component library
│       ├── Window.svelte   # Main window
│       ├── main/           # Main screens
│       ├── login/          # Login screens
│       ├── settings/       # Settings components
│       └── common/         # Shared components
├── package.json            # JS dependencies
└── vite.config.js          # Vite configuration

    ​
    Key Design Principles

    Separation of Concerns: The Rust backend handles all system operations, file I/O, and network requests, while the Svelte frontend focuses purely on UI and user interaction.
    Type Safety: Tauri’s command system ensures type-safe communication between frontend and backend through serialization/deserialization.
    Async-First: Both frontend (JavaScript promises) and backend (Tokio async) are designed around asynchronous operations for responsive UI.
    Error Handling: Rust’s Result type propagates errors through the stack, converted to JavaScript exceptions at the boundary.

    ​
    Next Steps

    Backend Architecture

    Deep dive into Rust modules and Tauri commands

    Frontend Architecture

    Explore Svelte components and state management

    Launcher Core

    Understand the game launch process

    Build docs developers (and LLMs) love

    Get started for freeTalk to us