mobile targets

32 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

File associations on Android and iOS supported

Tauri supports file associations on Android and iOS, allowing an app to be registered as a handler for specific file types. When a user opens a file that matches declared associations, the operating system launches the app and delivers the file URL.

Android file associations use intent filters

On Android, file associations are implemented using intent filters that the Tauri build system generates automatically from configuration.

iOS file associations use CFBundleDocumentTypes

On iOS, file associations use CFBundleDocumentTypes and optionally UTExportedTypeDeclarations for custom file types.

File associations configuration schema

Each file association entry has the following fields: ext (list of file extensions without leading dot, required), mimeType (MIME type string, required on Android, inferred from extension if not specified), role (app's role: Editor, Viewer, Shell, QLGenerator, or None; defaults to Editor), rank (ranking among handlers: Default, Owner, Alternate, or None; defaults to Default), name (display name, defaults to first extension), exportedType (custom file type definition with identifier and conformsTo fields), and androidIntentActionFilters (Android intent actions: Send, SendMultiple, View; all three used by default).

Custom file type definition with exportedType

For non-standard file extensions, define an exportedType so Apple platforms can identify the file type. The identifier should be a reverse-DNS string unique to the app, and conformsTo lists parent types. Common conformsTo values include public.data, public.image, public.json, and public.plain-text.

RunEvent::Opened event for file handling

When a file is opened with the app, Tauri emits a RunEvent::Opened event containing the file URLs. This event is available on macOS, iOS, and Android.

Two cases for handling opened files

When handling opened files: (1) if the app is already running, the event is delivered at runtime; (2) if the app is launched by the file open, the event fires during startup, so URLs should be stored and made available to the frontend.

Rust example: manage opened file URLs

use std::sync::Mutex; use tauri::Manager; struct OpenedUrls(Mutex<Vec<tauri::Url>>); #[tauri::command] fn opened_urls(app: tauri::AppHandle) -> Vec<tauri::Url> { app.state::<OpenedUrls>().0.lock().unwrap().clone() } #[cfg_attr(mobile, tauri::mobile_entry_point)] pub fn run() { tauri::Builder::default() .manage(OpenedUrls(Mutex::new(vec![]))) .invoke_handler(tauri::generate_handler![opened_urls]) .build(tauri::generate_context!()) .expect("error while running tauri application") .run(|app, event| { #[cfg(any(target_os = "macos", target_os = "ios", target_os = "android"))] if let tauri::RunEvent::Opened { urls } = event { use tauri::Emitter; app.state::<OpenedUrls>() .0 .lock() .unwrap() .extend(urls.clone()); app.emit("opened", urls).unwrap(); } }); } This example shows how to store incoming file URLs in managed state, expose them via a command for frontend access at startup, and emit a Tauri event on RunEvent::Opened for runtime file opens.

JavaScript example: handle opened files

import { listen } from '@tauri-apps/api/event'; import { invoke } from '@tauri-apps/api/core'; // Cold start: URLs may already be in Rust state before the frontend loads const initialUrls = await invoke('opened_urls'); if (initialUrls.length > 0) { handleFiles(initialUrls); } // Warm: Rust emits the "opened" event when RunEvent::Opened fires await listen('opened', (event) => { handleFiles(event.payload); }); This example shows how the frontend retrieves stored URLs from the Rust backend via the opened_urls command for cold starts, and listens for the opened event for file opens that occur while the app is already running.

Mobile entry point macro annotation

In Tauri 2, the main Rust function must be annotated with #[cfg_attr(mobile, tauri::mobile_entry_point)] and renamed from main() to run() to support both desktop and mobile. This function goes in src-tauri/src/lib.rs which is shared between both target types.

Desktop wrapper calls shared mobile entry point

In Tauri 2, src-tauri/src/main.rs is recreated to call the shared library function: fn main() { app_lib::run(); }. This allows the desktop executable to use the same code prepared for mobile with the mobile_entry_point macro.

Mobile target requires shared library in Cargo.toml

To support mobile targets in Tauri 2, the Rust crate must produce a shared library alongside the desktop executable. Add a [lib] block to src-tauri/Cargo.toml with name = "app_lib" and crate-type = ["staticlib", "cdylib", "rlib"].

Built-in mobile development server network exposure change

In Tauri 2.0, the built-in mobile development server no longer exposes to the entire network. Instead, traffic is tunneled directly from the local computer to the device. For iOS devices running directly or from Xcode, this change is not automatically applied, so the development server uses a public network address by default. To avoid this, open Xcode to establish automatic connection between the macOS machine and the connected iOS device, then run 'tauri ios dev --force-ip-prompt' to select the iOS device's TUN address (ending with '::2').

TAURI_DEV_HOST environment variable for development server configuration

In Tauri 2.0, the TAURI_DEV_HOST environment variable should be checked instead of TAURI_ENV_PLATFORM to configure the development server. Previously, developers were recommended to check if TAURI_ENV_PLATFORM matched 'android' or 'ios', but now iOS devices can connect to localhost if not being used, so TAURI_DEV_HOST should be used for development server configuration.

Vite development server configuration for Tauri 2.0 mobile

For Tauri 2.0 mobile development with Vite, use the TAURI_DEV_HOST environment variable to configure the development server. Set the server host to the TAURI_DEV_HOST value or false if not set, configure the port to 1420 with strictPort enabled, and if TAURI_DEV_HOST is present, set up HMR with protocol 'ws', the TAURI_DEV_HOST as host, and port 1430. The 'internal-ip' npm package is no longer needed.

Tauri 2.0 alpha mobile support announcement

The first alpha version of Tauri 2.0 was published approximately 3 months before create-tauri-app version 3 (around December 2022) and brought initial mobile support for Android and iOS.

Mobile preparation: main.rs to lib.rs refactoring

For mobile support, move code from src-tauri/src/main.rs to src-tauri/src/lib.rs since the library is shared between desktop and mobile. Rename the main function to 'run' and annotate it with #[cfg_attr(mobile, tauri::mobile_entry_point)]. Recreate main.rs to call the shared run function from the library (app_lib::run()).

Mobile preparation: library output configuration

Tauri's mobile interface requires projects to output shared libraries. To adapt an existing desktop application for mobile, modify the crate to generate library files alongside the desktop executable. Add a library block to the Cargo manifest specifying the library name (e.g., 'app_lib') with crate types ['staticlib', 'cdylib', 'rlib'].

Mobile plugin development

Plugins can run native mobile code written in Kotlin (or Java) for Android and Swift for iOS. The default plugin template includes Android library project using Kotlin and a Swift package. Mobile plugin development is documented in the Mobile Plugin Development guide.

Tauri 2.0 is The Mobile Update

Tauri 2.0 is fundamentally The Mobile Update, adding support for iOS and Android in addition to the existing desktop support for Linux, macOS, and Windows.

Tauri v2 adds mobile support for Android and iOS

Tauri v2 introduces mobile support with Android and iOS targets. Developers can bring existing desktop implementations and port them to mobile with access to native APIs and the Tauri CLI developer experience.

v2 mobile native APIs support notifications, dialogs, NFC, barcode reading, biometric authentication, clipboard, and deep links

Tauri v2 provides default support for several mobile native APIs including notifications, dialogs, NFC, barcode reading, biometric authentication, clipboard, and deep link handling. More APIs are planned after the stable release.

Recreate mobile projects after updating Tauri 2.0.0-alpha.4

After updating dependencies, recreate mobile projects by running: rm -r src-tauri/gen, tauri android init, and tauri ios init to use new features.

Mobile as first class citizen expectation revised

Tauri 2.0 revised its messaging on mobile support. While the original promise was 'mobile as a first class citizen', the team clarified that the foundation for mobile could only be built by Tauri and requires community iteration to get right. Production-ready mobile applications can be developed with Tauri now, but not all desktop features and plugins are available on mobile yet.

Development server network exposure for mobile

Tauri 2.0 RC introduced changes allowing connection to a development server running on localhost when targeting Android and iOS, eliminating the need to expose the development server on the public network for most cases.

iOS device development server binding with Xcode

When running on a physical iOS device, the development server must be bound to a TUN address provided by the device. This connection is only possible when Xcode is opened and connected to the device. Developers can use 'tauri ios dev --force-ip-prompt' to select the iOS device's TUN address (which ends with ::2).

TAURI_DEV_HOST environment variable

The IP address the frontend must listen to in mobile development is provided by the TAURI_DEV_HOST environment variable. This replaces the need for the 'internal-ip' NPM package.

Tauri 2.0 Vite configuration migration for mobile

In Tauri 2.0 RC, the Vite development server configuration changed. Instead of detecting mobile and manually setting host and hmr, developers should use the TAURI_DEV_HOST environment variable directly. The host should be set to process.env.TAURI_DEV_HOST or false, and hmr should only be configured when host is available, using the same host value and port 1430.

Two primary mobile platforms supported by Tauri

Tauri supports iOS and Android as the two primary mobile platforms. The development model uses the operating system native languages (Swift and Kotlin) to build interfaces for the Rust code, allowing developers to write functionality in these native languages and expose it to Rust or the frontend via the plugin system.

Tauri mobile runs on connected device or emulator

Tauri mobile applications run on a connected device or start an emulator if available.

TLS support behind Cargo feature in Tauri 2.0.0-alpha.0

TLS support has been moved behind a Cargo feature in the 2.0.0-alpha.0 release pending resolution of OpenSSL cross-compilation issues on Windows.

Xcode 14 device execution limitation in Tauri 2.0.0-alpha.0

Running Tauri applications on a device is not supported when using Xcode 14 in the 2.0.0-alpha.0 release.

Give your agent this brain