Rust api module removed in Tauri 2
The tauri::api module was removed entirely in Tauri 2. All API modules are now available as separate plugins.
process model & ipc
55 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
IPC module restructured in Tauri 2
In Tauri 2, the tauri::api::ip module was rewritten and moved to tauri::ipc. Review new APIs, especially tauri::ipc::Channel.
Path APIs moved to Manager in Tauri 2
In Tauri 2, functions from tauri::api::path and tauri::PathResolver moved to tauri::Manager::path.
Current binary and restart moved in Tauri 2
In Tauri 2, tauri::api::process::current_binary and tauri::api::process::restart moved to tauri::process.
Filesystem scope API moved in Tauri 2
In Tauri 2, Manager::fs_scope was removed. Access filesystem scope through tauri_plugin_fs::FsExt instead.
JavaScript API modules removed in Tauri 2
In Tauri 2, @tauri-apps/api no longer provides non-core modules. Only @tauri-apps/api/core (renamed from tauri), @tauri-apps/api/path, @tauri-apps/api/event, and @tauri-apps/api/webviewWindow are exported. All others moved to plugins.
JavaScript tauri module renamed to core
In Tauri 2, @tauri-apps/api/tauri was renamed to @tauri-apps/api/core.
Event system redesigned in Tauri 2
In Tauri 2, the event system was redesigned: emit() now emits to all event listeners; new emit_to() triggers events to a specific target; emit_filter() now filters based on EventTarget instead of event source; listen_global() renamed to listen_any() and listens to all events regardless of filters and targets.
Path Manager API example
In Tauri 2, use tauri::Manager::path instead of tauri::api::path. Example: app.path().home_dir() returns home directory, and app.path().resolve("path/to/file", BaseDirectory::Config) resolves a path.
Rust API module removals and migrations in Tauri v2
Major Rust API changes: `api` module removed entirely. `api::dialog` removed, use `tauri-plugin-dialog`. `api::file` removed, use Rust's `std::fs`. `api::http` removed, use `tauri-plugin-http`. `api::ip` rewritten and moved to `tauri::ipc` (particularly `tauri::ipc::Channel`). `api::path` functions and `tauri::PathResolved` moved to `tauri::Manager::path`. `api::process::Command`, `tauri::api::shell`, and `tauri::Manager::shell_scope` removed, use `tauri-plugin-shell`. `api::process::current_binary` and `tauri::api::process::restart` moved to `tauri::process`. `api::version` removed, use semver crate. `App::clipboard_manager` and `AppHandle::clipboard_manager` removed, use `tauri-plugin-clipboard`. `App::get_cli_matches` removed, use `tauri-plugin-cli`. `App::global_shortcut_manager` and `AppHandle::global_shortcut_manager` removed, use `tauri-plugin-global-shortcut`. `Manager::fs_scope` removed, accessible via `tauri_plugin_fs::FsExt`. `Plugin::PluginApi` now receives plugin configuration as second argument. `Plugin::setup_with_config` removed, use updated `tauri::Plugin::PluginApi`. `scope::ipc::RemoteDomainAccessScope::enable_tauri_api` and `enables_tauri_api` removed, enable core plugins individually via `add_plugin`. `updater` module removed, use `tauri-plugin-updater`. `Menu`, `MenuEvent`, `CustomMenuItem`, `Submenu`, `WindowMenuEvent`, `MenuItem` APIs removed. `SystemTray`, `SystemTrayHandle`, `SystemTrayMenu`, `SystemTrayMenuItemHandle`, `SystemTraySubmenu`, `MenuEntry`, `SystemTrayMenuItem` APIs removed.
JavaScript API module removals in Tauri v2
`@tauri-apps/api` package in v2 only exports `tauri`, `path`, and `event` modules. All other modules moved to plugins: `@tauri-apps/api/app` removed, use `@tauri-apps/plugin-app`. `@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-apps/api/window` removed, use `@tauri-apps/plugin-window`.
Menu API migration to MenuBuilder in Tauri v2
Use `tauri::menu::MenuBuilder` instead of `tauri::Menu`. The MenuBuilder constructor requires a Manager instance (App, AppHandle, or Window). Example: `let menu = MenuBuilder::new(app).copy().paste().separator().undo().redo().text("open-url", "Open URL").check("toggle", "Toggle").build()?;` Use `tauri::menu::PredefinedMenuItem` instead of `tauri::MenuItem`. Use `tauri::menu::MenuItemBuilder` instead of `tauri::CustomMenuItem`. Example: `let toggle = MenuItemBuilder::new("Toggle").accelerator("Ctrl+Shift+T").build(app);` Use `tauri::menu::SubmenuBuilder` instead of `tauri::Submenu`. MenuBuilder has dedicated methods for each predefined menu item, so you can call `.copy()` instead of `.item(&PredefinedMenuItem::copy(app, None))`. `tauri::Builder::menu` now takes a closure since the menu needs a Manager instance to be constructed.
Menu event handling migration in Tauri v2
`tauri::Builder::on_menu_event` has been removed. Use `tauri::App::on_menu_event` or `tauri::AppHandle::on_menu_event` instead. Menu items can be shared between menus, and menu events are tied to a menu item rather than a menu or window. To avoid all listeners triggering when a menu item is clicked, do not share menu items; use dedicated instances that can be moved into a closure passed to `tauri::Window/WindowBuilder::on_menu_event`. There are two ways to check if a menu item was selected: move the item into the event handler closure and compare IDs, or set a custom ID via the `with_id` constructor and use that string ID for comparison.
TrayIcon API migration from SystemTray in Tauri v2
SystemTray APIs renamed to TrayIcon for consistency. Use `tauri::tray::TrayIconBuilder::with_id("my-tray").build(app)?` instead of `tauri::SystemTray`. Use `tauri::menu::Menu` instead of `tauri::SystemTrayMenu`, `tauri::menu::Submenu` instead of `tauri::SystemTraySubmenu`, and `tauri::menu::PredefinedMenuItem` instead of `tauri::SystemTrayMenuItem`. `tauri::SystemTray::on_event` has been split into `tauri::tray::TrayIconBuilder::on_menu_event` and `tauri::tray::TrayIconBuilder::on_tray_event`. `TrayIconEvent::Click` contains button state with `MouseButton::Left`, `MouseButton::Right`, etc. and `MouseButtonState::Up`, `MouseButtonState::Down`.
Path API migration to Manager in Tauri v2
The Rust `tauri::api::path` module functions and `tauri::PathResolver` are moved to `tauri::Manager::path`. Use `app.path().home_dir().expect("failed to get home dir")` to get home directory. Use `app.path().resolve("path/to/something", BaseDirectory::Config)?` to resolve paths. Import `tauri::{path::BaseDirectory, Manager}` for these methods.
Removed Rust API modules in Tauri 2.0
Removed: 'api' module entirely; 'api::dialog' (use tauri-plugin-dialog); 'api::file' (use std::fs); 'api::http' (use tauri-plugin-http); 'api::version' (use semver crate); 'api::process::Command' and 'tauri::api::shell' (use tauri-plugin-shell); 'updater' module (use tauri-plugin-updater); 'api::ip' rewritten and moved to 'tauri::ipc' with new Channel API.
Moved Rust APIs in Tauri 2.0
Moved APIs: 'api::path' and 'PathResolved' moved to 'tauri::Manager::path'; 'api::process::current_binary' and 'api::process::restart' moved to 'tauri::process'; 'api::ip' rewritten and moved to 'tauri::ipc'.
JavaScript API: @tauri-apps/api module removals
The @tauri-apps/api package no longer provides non-core modules. Only 'tauri' (renamed to 'core'), 'path', 'event', and 'window' modules are exported from core. All other modules moved to plugins.
JavaScript API module renames in Tauri 2.0
Rename '@tauri-apps/api/tauri' to '@tauri-apps/api/core'. Rename '@tauri-apps/api/window' to '@tauri-apps/api/webviewWindow'.
Event system redesign in Tauri 2.0
The event system was redesigned: 'emit' broadcasts to all listeners; new 'emit_to' function targets specific event targets; 'emit_filter' now filters by EventTarget instead of windows; 'listen_global' renamed to 'listen_any' and waits for all events regardless of filters or targets.
Path API migration: Manager.path usage
Access path functions via Manager: use tauri::Manager; app.path().home_dir().expect("failed to get home dir"); app.path().resolve("path/to/something", BaseDirectory::Config)?;
Core module migration: JavaScript
Update JavaScript imports: import { invoke } from "@tauri-apps/api/tauri" becomes import { invoke } from "@tauri-apps/api/core"
Calling mobile commands from Rust using PluginHandle
Use the tauri::plugin::PluginHandle to call a mobile command from Rust. Call the run_mobile_plugin method with the command name as a string and serialize the payload, which returns a Result containing the deserialized response.
Tauri multi-process architecture overview
Tauri employs a multi-process architecture similar to Electron or modern web browsers. A single Core process manages one or more WebView processes. The Core process acts as the application's entry point and is the only component with full access to the operating system.
Benefits of multi-process architecture
Multi-process architecture makes better use of modern multi-core CPUs and creates safer applications. A crash in one component does not affect the whole system anymore since components are isolated on different processes. If a process gets into an invalid state, it can be easily restarted.
WebView process isolation and state management
The Core process manages global state such as settings or database connections. This allows easy synchronization of state between windows and protects business-sensitive data from exposure in the Frontend.
Tauri adopts multi-process architecture like Electron
Tauri uses a multi-process architecture similar to Electron and modern web browsers. This design separates different components into different processes to improve robustness and safety.
Core process is the single component with full OS access
Each Tauri application has a core process that serves as the application's entry point and is the only component with full access to the operating system.
Core process responsibilities
The core process is responsible for creating and managing application windows, system tray menus, and notifications. It also routes all inter-process communication (IPC) through itself, allowing it to intercept, filter, and manipulate IPC messages in a central location. Additionally, it manages global state such as configuration and database connections.
Tauri uses Rust for the core process
Tauri is implemented in Rust because the ownership concept guarantees memory safety while maintaining excellent performance.
Multi-process architecture prevents UI blocking
By separating components into different processes, long-running or computationally expensive operations cannot block the user interface. If one process becomes unresponsive or crashes, the entire application is not affected and that process can simply be restarted.
Core process manages state across windows
The core process manages global state to easily synchronize state between windows and protect business-sensitive data from external scrutiny at the frontend.
Tauri process model diagram
The Tauri process model consists of one core process (diamond-shaped) connected to one or more WebView processes through events and commands. The core process controls all WebView processes.
api::Command encoding method
Tauri 1.1.0 adds an api::Command::encoding method to set the stdout/stderr encoding for commands.
Command line arguments retained in process restart
Tauri 1.1.0 retains command line arguments in api::process::restart.
Shell API Command::execute optimization in 1.7.0
The shell's Command::execute API was optimized to use IPC only a single time instead of streaming data, which improves performance for verbose shell scripts.
v2 IPC uses custom protocols instead of string serialization
Tauri v2 revamps Inter-Process Communication (IPC) between Rust and JavaScript layers. The new IPC uses custom protocols that are more reminiscent in function and performance to how webviews handle regular HTTP-based communication, replacing the v1 approach that serialized all messages to strings and was slow to deliver responses.
v2 adds channel API for Rust to frontend communication
Tauri v2 includes a new channel API that allows quick sending of data from Rust to the frontend.
JavaScript parameter naming convention for Tauri commands with pipe notation
JavaScript calls to Tauri plugin commands use the format invoke('plugin:<plugin-name>|<command-name>', parameters) where the pipe separates the plugin name from the command name.
Example: JavaScript invocation of plugin command in Tauri 2
JavaScript code to call a Tauri plugin command: import { invoke } from '@tauri-apps/api/tauri'; invoke('plugin:example|ping', { value: 'Tauri' }).then(({ value }) => console.log('Response', value));
Plugin command definition in Rust
Commands in a Tauri plugin are defined using the `#[command]` macro. For example, a command named `write_custom_file` would be defined as: `#[command] pub(crate) async fn write_custom_file<R: Runtime>(user_input: String, app: AppHandle<R>) -> Result<String>`. Commands must be added to the COMMANDS array in build.rs and included in the invoke_handler using `tauri::generate_handler!` macro.
Frontend parameter naming convention for plugin commands
When calling plugin commands from the frontend via JavaScript/TypeScript, parameter names must be in camelCase. If the Rust function uses snake_case like `user_input`, the frontend call must use `userInput`.
Exposing plugin commands to frontend
Plugin commands must be included in the `invoke_handler` using `tauri::generate_handler!` macro to generate the IPC call handler for frontend requests. Additionally, commands should be exported from the frontend module for convenience, though this is not a security requirement since the command handler has already been generated.
Plugin command definition example - write_custom_file
Example of a plugin command that writes user input to a temporary folder with a custom header: ```rust #[command] pub(crate) async fn write_custom_file<R: Runtime>( user_input: String, app: AppHandle<R>, ) -> Result<String> { std::fs::write(app.path().temp_dir().unwrap(), user_input)?; Ok("success".to_string()) } ```
Plugin TauriPlugin builder setup
The `TauriPlugin` is created using `Builder::new("name")` and configured with `.invoke_handler(tauri::generate_handler![...])` to register command handlers, `.setup()` for initialization code that runs on app startup, and `.build()` to finalize. The setup function receives `app` and `api` parameters and can manage state using `app.manage()`.
Frontend TypeScript module for plugin commands
Plugin commands are exported from a frontend TypeScript module (e.g., `guest-js/index.ts`) using the `invoke` function from '@tauri-apps/api/core'. Example: ```ts export async function writeCustomFile(user_input: string): Promise<string> { return await invoke('plugin:test|write_custom_file', { userInput: user_input, }); } ```
Tauri application architecture with IPC
In a Tauri application, the frontend is written in a web frontend stack and runs inside the operating system WebView. It communicates with the application core written mostly in Rust through an IPC bridge. There is no requirement to write code in Rust, Swift, or Kotlin for most cases, as Tauri offers an extensive JavaScript API.
IPC rewrite in Tauri 2.0 with Raw Payloads support
Tauri 2.0 includes a rewrite of its IPC layer that supports Raw Requests. Previously, all IPC payloads were JSON serialized and deserialized, causing overhead for large data transfers. The new system supports raw bytes directly or custom serialization processes (e.g., bson, protobuf, avro). For directly reading files from the filesystem into the WebView, the convertFileSrc functionality is still recommended as it is likely faster when data processing on the Rust backend is not needed.
EventId type added in Tauri 2.0
Tauri 2.0 added `tauri::EventId` type.
IPC Channel type in Tauri 2.0
Tauri 2.0 added `tauri::ipc::Channel` type in Rust and equivalent JS `Channel` type to send data across the IPC.
Custom URI scheme protocol improvements in Tauri 2.0
Tauri 2.0 added `tauri::Builder::register_asynchronous_uri_scheme_protocol` to allow resolving custom URI scheme protocol requests asynchronously to prevent blocking the main thread. The custom protocol on Windows and Android now uses the `http` scheme instead of `https`. IPC implementation now uses custom protocols to enhance performance.
URI scheme protocol return type change in Tauri 2.0
Tauri 2.0 changed `tauri::Builder::register_uri_scheme_protocol` to return a `http::Response` instead of `Result<http::Response>`. To return an error response, manually create a response with status code >= 400.
Command macro moved to ipc module in Tauri 2.0
Tauri 2.0 moved the items from `tauri::command` module to the `tauri::ipc` module so the import name does not clash with the `tauri::command` macro.
Builder invoke system signature change in Tauri 2.0
Tauri 2.0 changed `tauri::Builder::invoke_system` to take references instead of owned values. Changed `tauri::Builder::invoke_system` and `tauri::Builder::on_page_load` hooks to take a `tauri::Webview` argument instead of a `tauri::Window`.
IPC payload serialization fix in Tauri 2.0
Tauri 2.0 fixed a bug where the `payload` field was being unpacked and flattened over IPC, which could break commands with arguments called `cmd`, `callback`, `error`, `options`, or `payload`. These no longer break the IPC.