architecture

92 notes in this subject, read out of this brain and free to use. This is page 1 of 2.

Tauri governance framework established through Commons Conservancy

The Tauri Programme within the Commons Conservancy was established to commit to open source values and facilitate an open, transparent and efficient governance process throughout Tauri development.

Board Director and Domain Lead election schedule

Domain Lead elections are held in both spring and fall, and Board Director elections are held in the summer. Elections for these positions are run throughout the year, with instructions posted to the Tauri Blog leading up to each election.

Domain Lead role and responsibilities

Domain Leads are trusted contributors within the Tauri community with expertise in their Domain. They are responsible for setting direction, overseeing and supporting the activities within that Domain.

Tauri Working Group structure and components

The Tauri Working Group is the collective framework for governance and consists of four main components: Working Group Members (all individuals in the Working Group), the Tauri Board & Board Directors (central decision making body), Domains & Domain Leads (organizational units representing areas of interest), and Teams (small groups supporting specific areas).

Tauri Board responsibilities

The Tauri Board is the central decision making body for the Tauri Programme and is responsible for the overall health and stability of the Programme. The Board votes on major decisions within the Programme and issues raised by the Working Group.

Tauri core architecture: Rust backend with Node.js CLI

Tauri is a polyglot toolkit where the core is built with Rust and the CLI leverages Node.js, enabling developers to create applications for major desktop platforms using virtually any frontend framework.

Future backend language support

While Tauri currently uses Rust for the backend, the project plans to support other backends such as Go, Nim, Python, and C# in the future. This is possible because the API can be implemented in any language with C interop, and Tauri maintains official Rust bindings to the webview organization.

Defense in depth security approach

Tauri uses defense in depth techniques to minimize attack surface area. Developers can choose which API endpoints to ship, whether to include a localhost server, and Tauri randomizes functional handles at runtime. By default, Tauri ships binaries rather than ASAR files.

Rust as Tauri's binding and application layer

Rust was chosen as the binding and application layer for Tauri to provide creative flexibility and enable developers to build applications with any frontend framework of their choice.

Tauri's design goals

Tauri was built from the ground up to leverage new development parameters and the creative flexibility of the Rust language, enabling developers to build small, fast, robust, and secure native applications for major desktop and mobile platforms from a single codebase without needing to learn Rust.

CrabNebula Cloud features

CrabNebula Cloud supports multiple release channels and provides download buttons for application websites.

CrabNebula Cloud official Tauri distribution partner

CrabNebula is an official Tauri partner providing services and tooling for Tauri applications. CrabNebula Cloud is a platform for application distribution that seamlessly integrates with the Tauri updater.

CrabNebula Cloud CDN capabilities

The CrabNebula Cloud offers a Content Delivery Network (CDN) capable of shipping application installers and updates globally while being cost effective and exposing download metrics.

Setting up Tauri app with CrabNebula Cloud

To set up a Tauri app to use CrabNebula Cloud, sign in to the Cloud website using a GitHub account, create an organization and application, and install its CLI to create a release and upload the Tauri bundles. A GitHub Action is also provided to simplify using the CLI in GitHub workflows.

Tauri Android uses Android Studio project

Tauri uses an Android Studio project under the hood, so any official practice for building and publishing Android apps also applies to Tauri apps.

GUI apps on macOS and Linux do not inherit shell PATH

GUI applications on macOS and Linux do not inherit the `$PATH` environment variable from shell dotfiles such as `.bashrc`, `.bash_profile`, or `.zshrc`. Tauri provides the `fix-path-env-rs` crate to address this issue.

Tauri 2.0 frontend framework agnostic

Tauri supports any frontend framework, allowing developers to bring their existing web stack or start a new project without needing to change their frontend stack.

Tauri 2.0 supported platforms

Tauri can build applications for Linux, macOS, Windows, Android and iOS all from a single codebase.

Tauri 2.0 minimum app size with native web renderer

By using the OS's native web renderer, the size of a Tauri app can be as little as 600KB.

Organize capabilities into separate files by category

Capability files should be placed in the src-tauri/capabilities directory and organized by category. For example, filesystem-related capabilities in filesystem.json and dialog-related capabilities in dialog.json.

Create multiple windows programmatically in Rust

Windows can be created programmatically in Rust using tauri::WebviewWindowBuilder::new(app, label, webview_url) during the setup phase. Multiple windows are created by calling this builder multiple times with different labels and storing the results.

Apply different capabilities to different windows

Windows in a Tauri app can be assigned different capabilities for better security. The "windows" field in a capability file specifies which windows have access to that capability. This field accepts an array of window labels, allowing different feature sets per window.

Capability file windows field format

The "windows" field in a capability JSON file is an array of window label strings. For example: "windows": ["first"] applies the capability only to the window labeled "first", while "windows": ["first", "second"] applies it to both windows.

Make capabilities platform-specific

Capabilities can be restricted to specific platforms using the "platforms" field in a capability file. The field accepts an array of platform strings: "linux", "windows", "macos", "android", and "ios".

Available platforms for capability targeting

The platforms that can be targeted in capability files are: linux, windows, macos, android, and ios.

Multi-window support on Android and iOS

Tauri supports multiple windows on Android and iOS. On Android, multi-window uses Activity Embedding to display two activities side by side on large screens. On iOS, multi-window uses the UIScene API, allowing iPad users to open multiple instances of the app in separate windows.

Multi-window behavior on phones

On phones, the system usually does not lay out two windows side by side. On Android, creating another window launches a separate activity that is pushed onto the activity back stack, so Back returns to the previous activity instead of closing a split. On iOS (especially iPhone), opening or creating another window often replaces the current UI with the new scene's content rather than keeping both visible at once.

Multi-window minimum requirements

Multi-window requires Android 12L (API 32)+ and iOS 13+. You can use the app.supportsMultipleWindows API to check availability at runtime.

Android multi-window Activity Embedding setup dependencies

To use Activity Embedding for multi-window on Android, add the following dependencies to build.gradle.kts: androidx.window:window:1.5.0 and androidx.startup:startup-runtime:1.2.0.

Android multi-window Activity creation

For each additional window type on Android, create a Kotlin class that extends TauriActivity. Example: class DetailActivity: TauriActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) } }

Android AndroidManifest.xml setup for Activity Embedding

To enable activity embedding on Android, add the tools namespace (xmlns:tools="http://schemas.android.com/tools") to the manifest element. Add an android:property element with android:name="android.window.PROPERTY_ACTIVITY_EMBEDDING_SPLITS_ENABLED" and android:value="true" inside the application element. Register all activities with android:exported="true". Register the split initializer using an InitializationProvider with meta-data pointing to the SplitInitializer.

Android SplitInitializer class

The SplitInitializer class implements Initializer<RuleController> and loads split pair rules at app startup. In the create method, return RuleController.getInstance(context).apply { setRules(RuleController.parseRules(context, R.xml.main_split_config)) }. The dependencies method returns an empty list.

Android split pair rule configuration attributes

Android split pair rules are defined in XML with the following attributes: splitRatio (how the screen is divided, e.g. 0.33 gives the primary activity one-third), splitLayoutDirection (typically 'locale'), splitMinWidthDp (minimum screen width to activate the split, e.g. 840dp targets tablets), splitMaxAspectRatioInPortrait (set to 'alwaysAllow' to enable split in portrait mode), finishPrimaryWithSecondary (set to 'never'), finishSecondaryWithPrimary (set to 'never'), clearTop (typically 'false'). The SplitPairFilter element specifies primaryActivityName and secondaryActivityName to determine which activity pair triggers the split.

iOS multi-window UIScene configuration

On iOS, multi-window uses the UIScene API. Create an Info.ios.plist file in src-tauri directory with UIApplicationSceneManifest containing UIApplicationSupportsMultipleScenes set to true and UISceneConfigurations as an empty dict.

iOS multi-window SceneRequested event handling

When a user requests a new window on iPad (for example by long-pressing the app icon), Tauri emits a RunEvent::SceneRequested event. Handle this event in the run function to create a new window using WebviewWindowBuilder. Use dynamic labels like 'main-1', 'main-2', etc., and ensure the capabilities file includes a wildcard pattern to cover them (e.g., 'windows': ['main', 'main-*']).

Multi-window creation from JavaScript

To create windows from JavaScript, use the WebviewWindow constructor from @tauri-apps/api/webviewWindow. Pass a window label, options object (including url), and platform-specific options like activityName for Android. Listen to 'tauri://created' and 'tauri://error' events.

Multi-window creation from Rust

To create windows from Rust, use WebviewWindowBuilder.new() with a manager, window label, and URL. On Android, chain .activity_name() to specify the Activity class. On iOS, use .scene_identifier_option() for scene relationships. Call .build()? to create the window.

Android window creation options

When creating windows on Android using WebviewWindowBuilder or WebviewWindow, you can specify: activityName (the name of the Android Activity class to create for this window) and createdByActivityName (the name of the Activity that is creating this window, which determines which activity stack the new activity belongs to, important for split rules to work correctly, automatically inherited from the manager if not set).

iOS window creation options

When creating windows on iOS using WebviewWindowBuilder or WebviewWindow, you can specify: requestedBySceneIdentifier (sets the identifier of the UIScene that is requesting the creation of this new scene, establishing a relationship between the two scenes, by default the system uses the foreground scene, automatically inherited from the manager if not set).

Window instance platform-specific identifier APIs

Once a window is created, you can retrieve its platform-specific identifier. In JavaScript, use await window.activityName() for Android and await window.sceneIdentifier() for iOS. In Rust, use window.activity_name()? for Android (with #[cfg(target_os = "android")]) and window.scene_identifier()? for iOS (with #[cfg(target_os = "ios")]).

Frontend router recommendation for multi-window

When using a frontend router with multi-window, use a browser-history based router (e.g., createBrowserRouter in React Router) instead of a hash router so each window can navigate to a distinct URL path.

Node.js sidecar example: command-line argument processing

Example Node.js sidecar that processes command-line arguments and writes to stdout: ```js const command = process.argv[2]; switch (command) { case 'hello': const message = process.argv[3]; console.log(`Hello ${message}!`); break; default: console.error(`unknown command ${command}`); process.exit(1); } ``` This pattern reads commands from argv and outputs results via console.log.

JavaScript example: executing sidecar with shell plugin

Execute a sidecar from JavaScript using the shell plugin Command API: ```js import { Command } from '@tauri-apps/plugin-shell'; const message = 'Tauri'; const command = Command.sidecar('binaries/my-sidecar', ['hello', message]); const output = await command.execute(); console.log(output.stdout); ``` This example passes 'hello' and a message argument to the sidecar and logs the stdout output.

Rust example: executing sidecar from Tauri command

Execute a sidecar from Rust and expose via Tauri command: ```rust use tauri_plugin_shell::ShellExt; #[tauri::command] async fn hello(app: tauri::AppHandle, cmd: String, message: String) -> String { let sidecar_command = app .shell() .sidecar("my-sidecar") .unwrap() .arg(cmd) .arg(message); let output = sidecar_command.output().await.unwrap(); String::from_utf8(output.stdout).unwrap() } ``` Register in invoke_handler and call from frontend with: `invoke('hello', { cmd: 'hello', message })`

Node.js sidecar packaging with pkg tool

Node.js applications can be packaged as self-contained binaries using the pkg tool for use as Tauri sidecars. The pkg tool compiles JavaScript or TypeScript into a binary application. Alternative approaches include embedding the Node runtime and bundled JavaScript as resources within the Tauri application, though this results in readable JavaScript files and typically a larger runtime than a pkg-packaged application.

Sidecar binary naming convention with target triple

Sidecar binaries must follow the naming pattern: my-sidecar-<target-triple> on Linux and macOS (no extension) and my-sidecar-<target-triple>.exe on Windows. The target triple can be determined using 'rustc --print host-tuple' (available in Rust 1.84.0+) or by parsing 'rustc -vV' output for older versions. Binaries should be placed in src-tauri/binaries/ directory.

Sidecar inter-process communication options

Sidecars can communicate with Tauri applications through multiple methods: command line arguments with stdout output (suitable for short-lived processes), localhost servers, stdin/stdout, or local sockets. Each method has different advantages, drawbacks, and security considerations. For long-lived applications, alternatives to command-line argument communication should be considered.

Shell plugin requirement for sidecars

Executing sidecars requires the shell plugin to be installed and initialized. The plugin must be set up and configured before sidecar execution will work.

Register splashscreen and main windows in tauri.conf.json

Windows are registered in the tauri.conf.json configuration file under the "windows" array. For a splashscreen pattern, create a window with label "main" that has "visible": false, and a window with label "splashscreen" that has "url": "/splashscreen" to display content during startup.

Splashscreen is a hidden window shown during app startup

A splashscreen in Tauri is implemented as a separate window that displays content while the app performs heavy setup tasks. It is created as a new window with a specific label, shown during initialization, and closed once setup is complete.

Use tokio::time::sleep in async backend tasks, not std::thread::sleep

In Tauri backend code, use tokio::time::sleep instead of std::thread::sleep when performing async operations. Using std::thread::sleep in async functions blocks the entire thread, freezing all tasks scheduled on that thread since Tauri runs tasks cooperatively in a concurrent environment, not in parallel.

Use app.get_webview_window() to access windows by label

Windows registered in tauri.conf.json can be accessed in Rust code using app.get_webview_window("label") where "label" matches the window label defined in the configuration. This returns an Option containing the window handle.

Close windows with window.close().unwrap()

A Tauri window can be closed by calling the close() method on the window handle, for example: splash_window.close().unwrap()

Show hidden windows with window.show().unwrap()

A Tauri window that was created with "visible": false can be made visible by calling the show() method on the window handle, for example: main_window.show().unwrap()

Tauri commands can be invoked from frontend to backend with invoke()

Frontend TypeScript/JavaScript code can call Tauri commands using the invoke() function to trigger backend Rust functions and pass data between the frontend and backend.

Use Mutex to manage shared state in Tauri backend

Tauri applications can use tauri::Builder::default().manage() to register state managed by Tauri. State that needs to be modified should be wrapped in a std::sync::Mutex to provide thread-safe write access.

Tauri setup hook runs before windows are created

The setup hook in tauri::Builder runs before the main event loop starts, which means no windows are yet created. Heavy initialization tasks should be spawned as non-blocking tasks within the setup hook so windows can be created and displayed while those tasks execute.

Use tauri::async_runtime::spawn for non-blocking background tasks

In Tauri's setup hook or other lifecycle points, use tauri::async_runtime::spawn to execute async tasks without blocking window creation and the main event loop. This allows windows to be created and displayed while background setup tasks run concurrently.

Window drag region attribute

The `data-tauri-drag-region` HTML attribute makes an element draggable to move the window. This attribute only works on the element to which it is directly applied; child elements need the attribute individually to be draggable. This preserves functionality of interactive elements like buttons and inputs.

Disable window decorations for custom titlebar

Set the `decorations` property to `false` in the windows array of tauri.conf.json to disable the default window decorations and create a custom titlebar.

Give your agent this brain