Plugins, Sidecars, And Mobile

Plugins and sidecars both extend a Tauri app beyond simple Rust commands, but they solve different problems.

Plugins

Use plugins when a native API deserves a reusable boundary with JavaScript API glue, Rust implementation, permission files, and platform-specific code.

Plugin anatomy commonly includes:

plugin/
  Cargo.toml
  src/lib.rs
  src/commands.rs
  guest-js/index.ts
  permissions/default.toml
  android/
  ios/

Official plugins should be the first choice for filesystem, shell, SQL, store, stronghold, global shortcut, notification, opener, HTTP, updater, and similar capabilities. Recheck current plugin platform support before using one on mobile.

Sidecars

Use sidecars when the app must ship and supervise another executable.

Sidecars require:

Area	Decision
Binary	What executable ships? Who builds it?
Target triples	Which OS/architecture variants exist?
Permissions	Is `shell:allow-execute` or `shell:allow-spawn` needed?
Args	Which values are fixed and which have validators?
Lifecycle	Who starts, monitors, restarts, and stops the process?
Logs	Where stdout/stderr go and how secrets are redacted
Updates	Whether sidecar and app update together
Security	Whether webview input can affect process execution

Mobile Plugin Bridge

Tauri mobile plugins can use native Kotlin/Java on Android and Swift on iOS. Generated mobile plugin templates split desktop and mobile paths.

Mobile-specific realities:

Android plugin commands can run on the main thread by default; move long work to background dispatchers to avoid ANRs.
iOS plugin code must follow Swift, permission, and App Store constraints.
Rust can be called from mobile plugin code through JNI on Android and C FFI on iOS, but this is not beginner-level glue.
Plugin support must be checked plugin by plugin.

Rule Of Thumb

Need	Default
App-specific native action	Rust command
Reusable native integration	Plugin
External executable	Sidecar
Mobile native API	Plugin with Kotlin/Swift bridge
Arbitrary shell command	Redesign the feature