CodeVetter · Repo Unpack · Feature catalog
tauri-apps/tauri
User-facing surface has three layers: the Rust API (Builder, windows, webviews, menus, tray, events, state, plugins, custom protocols), the JS API (invoke, Channel, events, window/webview/menu/tray/path/image modules), and the `cargo-tauri` CLI covering the whole project lifecycle (init, dev with hot-reload, build, bundle, icon, signer, plugin scaffolding, ACL permission/capability helpers, migrate, inspect, info). Bundling supports all major OS installer formats, and the repo ships example apps plus a WebDriver driver for automation.
- `tauri dev` runs the configured `build.beforeDevCommand` via `sh -c` (or `cmd /S /C` on Windows) in the frontend dir, then waits up to ~180s for the devUrl TCP port before starting the app.
- When `build.devUrl` is unset and `build.frontendDist` points at an existing directory, `tauri dev` starts a built-in static file dev server (default port 1430, env TAURI_CLI_PORT) and injects its URL into the merged config.
- `tauri dev` watches the src-tauri dir plus workspace dependency paths and `build.additionalWatchFolders` with a 1-second debounced notify watcher, rebuilding the app on Rust changes.
- `tauri build` runs beforeBuildCommand, compiles via the configured runner (default cargo), then computes bundler settings and calls `tauri_bundler::bundle_project` to emit installers per the `bundle` config.
- The CLI exposes project scaffolding (`init` writing src-tauri/tauri.conf.json, `plugin init/new`), icon generation (`icon`), updater key handling (`signer generate/sign`), v1→v2 `migrate`, environment diagnostics (`info`), and ACL helpers (`permission`, `capability`, `inspect`).
- Windowing features include multiwindow/multiwebview creation via `WebviewWindowBuilder::new(app, label, WebviewUrl)`, drag-drop events, `on_new_window` handlers, document-title hooks, and vibrancy effects — exercised by examples/api, examples/multiwindow and examples/multiwebview.
- Desktop menu and tray systems live in crates/tauri/src/menu and crates/tauri/src/tray (tray behind the `tray-icon` feature auto-enabled by trayIcon config), with global listeners via `Builder::on_menu_event`/`on_tray_icon_event`.
- The JS event API (`listen`, `emit`, `once`) targets EventTarget kinds Any/AnyLabel/App/Window/Webview/WebviewWindow and is implemented over plugin commands `plugin:event|listen`/`unlisten`/`emit`; built-in `tauri://` events (resize, move, close-requested, drag-drop, theme-changed, ...) are enumerated in TauriEvent.
- IPC offers `invoke()` for request/response commands, `Channel` for ordered streaming (messages carry an index, out-of-order messages are buffered client-side), and `Resource` handles wrapping the Rust `ResourceTable` closed via `plugin:resources|close`.
- The `asset:` custom protocol serves arbitrary filesystem files gated by the FsScope, with SafePathBuf validation, magic-byte mime sniffing, HEAD support and single/multi-range (206, multipart/byteranges) responses capped at 1000KiB per range.
- Apps can register custom URI scheme protocols (`UriSchemeProtocol` handler registered through the WebviewManager's `register_uri_scheme_protocol`) and use the Isolation security pattern, which encrypts IPC payloads through a sandboxed iframe.
- Mobile features: `tauri android`/`tauri ios` CLI subcommands (ios only compiled on macOS), `#[tauri::mobile_entry_point]` for lib entry, and Kotlin-side PluginManager bridged by the `android_binding!` macro.
- The `test` cargo feature exposes `tauri::test` with `mock_app()`/`mock_context()` and a MockRuntime so apps and internals can be unit-tested without a real OS webview.
- End-to-end WebDriver testing is a first-class feature: tauri-driver proxies native drivers and packages/api-e2e runs wdio specs against examples/api, with Android/iOS variants via appium.