architecture

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

Tauri project directory layout

The standard directory structure is: package.json and index.html at root, src/ containing main.js at root level, and src-tauri/ containing Cargo.toml, Cargo.lock, build.rs, tauri.conf.json, src/ (with main.rs and lib.rs), icons/ (with icon.png, icon.icns, icon.ico), and capabilities/ (with default.json).

icons/ directory purpose

The icons/ directory is the default output directory for the `tauri icon` CLI command. It typically contains icon.png, icon.icns, and icon.ico files, and is referenced in tauri.conf.json under bundle > icon for the application's icons.

lib.rs as primary Rust entry point

The src/lib.rs file contains the main Rust code and the mobile entry point (marked with `#[cfg_attr(mobile, tauri::mobile_entry_point)]`). The reason to avoid writing directly in main.rs is because the app is compiled to a library in mobile builds and loaded through the platform frameworks.

main.rs for desktop entry point

The src/main.rs file is the main entry point for desktop builds. It should run `app_lib::run()` in main to use the same entry point as mobile. The file should not be modified; instead, modify lib.rs. The `app_lib` corresponds to `[lib.name]` in Cargo.toml.

Tauri 2.0: API modules moved to plugins

The `api` module was removed in Tauri 2.0. Individual API modules are now available as separate Tauri plugins. `tauri::api::dialog` moved to `tauri-plugin-dialog`. `tauri::api::file` removed, use Rust `std::fs` instead. `tauri::api::http` moved to `tauri-plugin-http`. `tauri::api::ip` rewritten and moved to `tauri::ipc`. `tauri::api::path` moved to `tauri::Manager::path`. `tauri::api::process::Command` and `tauri::api::shell` moved to `tauri-plugin-shell`. `tauri::api::version` removed, use the semver crate instead.

Tauri 2.0: Rust crate API changes

`App::clipboard_manager` and `AppHandle::clipboard_manager` removed, use `tauri-plugin-clipboard` instead. `App::get_cli_matches` removed, use `tauri-plugin-cli` instead. `App::global_shortcut_manager` and `AppHandle::global_shortcut_manager` removed, use `tauri-plugin-global-shortcut` instead. `Manager::fs_scope` removed, access via `tauri_plugin_fs::FsExt`. `updater` module removed, use `tauri-plugin-updater` instead. `SystemTray`, `SystemTrayHandle`, `SystemTrayMenu` and related APIs removed, renamed to `TrayIcon` APIs.

Tauri 2.0: Window API changes

On the Rust side, `Window` was renamed to `WebviewWindow`. `WindowBuilder` renamed to `WebviewWindowBuilder`. `WindowUrl` renamed to `WebviewUrl`. `Manager::get_window` renamed to `get_webview_window`. The window's `parent_window` API renamed to `parent_raw`. On the JavaScript side, `WebviewWindow` is now exported from `@tauri-apps/api/webviewWindow` instead of `@tauri-apps/api/window`. The `onMenuClicked` function was removed.

Tauri 2.0: Removed JavaScript API modules

`@tauri-apps/api/cli` removed, use `@tauri-apps/plugin-cli`. `@tauri-apps/api/clipboard` removed, use `@tauri-apps/plugin-clipboard-manager`. `@tauri-apps/api/dialog` removed, use `@tauri-apps/plugin-dialog`. `@tauri-apps/api/fs` removed, use `@tauri-apps/plugin-fs`. `@tauri-apps/api/global-shortcut` removed, use `@tauri-apps/plugin-global-shortcut`. `@tauri-apps/api/http` removed, use `@tauri-apps/plugin-http`. `@tauri-apps/api/os` removed, use `@tauri-apps/plugin-os`. `@tauri-apps/api/notification` removed, use `@tauri-apps/plugin-notification`. `@tauri-apps/api/process` removed, use `@tauri-apps/plugin-process`. `@tauri-apps/api/shell` removed, use `@tauri-apps/plugin-shell`. `@tauri-apps/api/updater` removed, use `@tauri-apps/plugin-updater`.

Tauri 2.0 plugin system enhancements

In Tauri 2.0, many of the Tauri APIs have been shifted to use the Tauri plugin system. This allows the code to be more modular and maintainable, while also making the plugin system more powerful for developers to build their own plugins.

Tauri 2.0 Swift and Kotlin bindings for plugins

Tauri 2.0 enables plugin developers to write platform-specific code in Swift and Kotlin to integrate more closely with the systems they're developing for. Previously, Tauri offered a bridge between Rust and JavaScript code since version 1.0.

Tauri 1.1.0 new fs.exists API

Tauri 1.1.0 adds an exists API in the fs module.

api::Command::encoding method for stdout/stderr encoding

Tauri 1.1.0 adds the api::Command::encoding method to set the stdout/stderr encoding.

HasRawDisplayHandle implementation for App and AppHandle

Tauri 1.1.0 implements raw_window_handle::HasRawDisplayHandle for App and AppHandle.

Shell API Command::execute optimization in 1.7.0

The Shell API's Command::execute method has been optimized in 1.7.0 to use IPC only once instead of streaming data, improving performance when executing verbose shell scripts.

Native mobile functionality for Tauri plugins

Starting with Tauri 2.0.0-alpha.4, Tauri plugins can access iOS via Swift and Android APIs via Kotlin or Java code. This simplifies usage of platform interfaces such as camera or geolocation. To bootstrap iOS and Android projects on an existing plugin, run tauri plugin ios add and tauri plugin android add. New plugins automatically include all configuration needed to write native mobile code.

Rust API surface refactor in Tauri 2.0 RC

Tauri 2.0 RC reduced publicly exposed components meant for internal use. Publicly exposed structures are now either non-exhaustive, use builder patterns or constructors, or have an 'extend' field for future additions. This prevents unnecessary breaking changes and allows security fixes without breaking stable interfaces. Changes are documented in pull request #10158.

Tauri architecture: frontend and backend communication

In a Tauri application, the frontend is written in web technologies (HTML, JavaScript, CSS) and runs inside the operating system WebView. The frontend communicates with the application core, which is written mostly in Rust, through an IPC (inter-process communication) bridge. The frontend can also integrate Swift or Kotlin for backend logic when needed.

Plugin system and mobile plugin support

Tauri 2.0 includes an advanced plugin system that moved previous core functionality into official plugins. The plugin system supports mobile plugins on iOS and Android. On iOS, plugins are created by implementing a subclass of Plugin. On Android, plugins can use @Command annotations. Native code written in Swift or Kotlin can be exposed to the Tauri frontend using Annotations (@Command on Android), by implementing a Subclass (YourPluginClass: Plugin) on iOS, or by invoking Swift or Kotlin code from a Rust-based Tauri command. Plugins do not depend on other plugins with few exceptions.

Official plugin versioning strategy

Official plugins follow the major version of Tauri to make compatibility visible at a glance. Each plugin has a documented stability level. Plugin APIs can break in minor versions but changes are kept to a minimum, especially for stable plugins. Plugin versions can be pinned to patch updates only for absolute stable interfaces. Security updates are backported and advisories are announced on GitHub.

Mobile development support and templates

Tauri 2.0 provides development with emulators or real devices. The onboarding experience bootstraps mobile development templates for iOS and Android. Not all official plugins are supported on mobile; some are by design not a good fit for mobile and some are not yet implemented for mobile.

Deep link support via RunEvent

Tauri 2.0 added tauri::RunEvent::Opened on macOS and iOS for deep link support.

Asset provider initialization hook

Tauri 2.0 added tauri::Assets::setup method that lets you run initialization code for your custom asset provider.

egui library uses OpenGL context via glutin

egui is a GUI library written in Rust that leverages an OpenGL context via glutin for rendering.

Give your agent this brain