Mobile Maturity And Plugin Gaps

Tauri 2 mobile is real, but it is not a free mobile app strategy. Treat mobile as a platform-specific proof path.

What Tauri 2 Mobile Enables

Android and iOS app projects generated under the Tauri app.
Web frontend inside Android WebView or WKWebView.
Rust core code reused where it fits.
Mobile plugins with Kotlin/Java and Swift implementation paths.
Android AAB/APK and iOS build/distribution paths.

What You Must Verify

Area	Verification
Plugin support	Each official or custom plugin supports Android, iOS, both, or neither
Native code	Kotlin/Swift bridge exists for the mobile behavior
Permissions	Runtime permission prompts and denied paths work
Background work	Mobile lifecycle and store policy allow the behavior
Sidecars	Assume unsupported until proved for your target app shape
Updater	Verify platform-specific support and store-policy fit before relying on it
Signing	Android upload key or iOS signing identity exists
Device behavior	Emulator/simulator and at least one physical-device smoke when feasible

When To Choose Native Mobile Instead

Choose Android Kotlin Compose, SwiftUI, Expo/React Native, or Flutter when:

The app is mobile-first.
Background services, sensors, Bluetooth, SMS, widgets, push, or platform permissions are core product features.
The UI must feel fully native on low-end devices.
Store review and privacy declarations are product-critical from v1.
The required Tauri plugins have unclear or missing mobile support.

Mobile Smoke Checklist

Android/iOS prerequisites installed
mobile project initialized
static frontend builds for mobile
required plugins checked for platform support
permissions requested and denied paths tested
APK/AAB or iOS build produced
device/emulator launch recorded
release/signing state recorded
store-policy blockers listed

Practical Recommendation

Use Tauri mobile as a companion path for desktop-first apps. Do not use it as the default mobile-first stack until the exact plugin, device, signing, and policy path has been proved.