cargo-mobile2 for Rust iOS and Android Development

cargo-mobile2's Tauri-specific scope

cargo-mobile2 addresses the gap between Cargo's normal Rust workflows and the native project structures required by iOS and Android. Its documented responsibilities include generating Xcode and Android Studio project files, creating boilerplate, building applications, running them on connected devices, and opening generated projects in native IDEs. This makes it relevant to Rust developers who want a Cargo-centered mobile workflow rather than assembling every native wrapper and toolchain invocation by hand.

The support boundary is unusually important. The fork was created as a base for mobile support in Tauri, and the README says the maintainers can provide maintenance only for that use case. Problems encountered through Tauri should be reported in Tauri's issue tracker even when the suspected cause lies in cargo-mobile2. Direct use outside Tauri is explicitly outside the offered support scope.

That does not make every non-Tauri workflow technically unusable. The repository still contains templates for Bevy, Dioxus, egui, wgpu, winit, and wry. However, template availability is not the same as a maintenance commitment. An engineer evaluating one of those templates should read the scripts and generated native projects directly, because the README provides no promise that non-Tauri failures will be investigated or fixed.

Cargo subcommands and generated native projects

Based on `Cargo.toml`, the crate builds three Cargo subcommand binaries when the default `cli` feature is enabled: `cargo-mobile`, `cargo-apple`, and `cargo-android`. The default feature set also includes `native-tls`, while the binary definitions require `cli`. The package uses Rust 2021 and declares a minimum Rust version of `1.76`.

The operational flow begins with `cargo mobile init`, which prompts for information and a template pack. The selected template supplies project boilerplate. The documented packs range from minimal `winit` and `wry` applications to examples based on Bevy, Dioxus, egui, and `wgpu-rs`. The README specifically identifies the `wry` pack as suitable for generating a project that runs on desktop and mobile.

After generation, the ordinary `cargo run` command remains available for desktop execution. Mobile execution is exposed through `cargo apple run` for a connected iOS device and `cargo android run` for a connected Android device. The Apple and Android plugins also provide `open` commands for Xcode and Android Studio. Running `cargo mobile`, `cargo apple`, or `cargo android` without a further subcommand displays help, which is the documented route to more commands rather than a separately documented manual page.

The actual boundary between Cargo and native tooling is project-specific. The README says generated files provide the Xcode and Android Studio projects, while platform tools, templates, and platform subcommands handle the rest. It does not document every generated path or build pipeline stage, so engineers should inspect the output created by the chosen template rather than assume it follows a universal directory layout.

Installing cargo-mobile2 and creating the first project

The README installs cargo-mobile2 directly from its Git repository:

cargo install --git https://github.com/tauri-apps/cargo-mobile2

This command builds the project from the default branch because the README does not specify a tag or release argument. The README warns that the build may take some time. It states that macOS, Linux, and Windows are supported for the tool itself, but iOS targets require macOS. Xcode and the Android SDK/NDK are also required.

Create a project directory, enter it, and initialize the generated files with:

cargo mobile init

The command should present prompts and a template-pack selection. Choose the template that matches the Rust framework you intend to use. For a Tauri application, the README points to Tauri's mobile prerequisites and development documentation rather than treating cargo-mobile2 as a complete standalone Tauri guide.

A generated project can still use the normal desktop command:

cargo run

For connected mobile devices, the documented commands are:

cargo apple run
cargo android run

The first command targets a connected iOS device and is relevant only on macOS with the required Apple tooling. The second builds, installs, and runs on a connected Android device while following device logs. To open the generated native projects instead, use:

cargo apple open
cargo android open

The first opens Xcode, and the second opens Android Studio. These commands depend on the native tools already being installed.

Android logging behavior and device constraints

`cargo android run` combines several operations in one command: it builds the application, installs it, launches it, and follows logs emitted by the app. By default, warning and error messages are visible. The `-v` and `-vv` options increase verbosity, and the documentation states that they also make build and installation logging more detailed.

For finer control, Android device logging accepts a level through `--filter` or `-f`. An example value documented by the README is `debug`:

This selects the Android device logging level and overrides the default set by `-v` or `-vv`. Projects using the `android_logger` crate need one additional mapping consideration: Rust `trace` messages are converted to Android `verbose` log messages.

This logging behavior has a practical limit. It is specific to the Android run path and does not imply equivalent filtering controls for iOS. The README does not document device selection flags, deployment profiles, signing behavior, simulator handling, or automatic SDK installation. It also says Xcode and the Android SDK/NDK must be installed, while noting that better automation and diagnostics may come later. Consequently, the commands reduce project generation and repeated tool invocation, but they do not remove native mobile setup.

Platform boundaries and maintenance limits

The tool can run on macOS, Linux, and Windows, but target availability is narrower than host support. Android can be targeted from any of those supported operating systems. iOS cannot be targeted from platforms other than macOS. Even on Linux or Windows, installing cargo-mobile2 does not remove the need for Xcode when an iOS build is required elsewhere in the toolchain.

The repository is not archived, and its last push was on 2026-10-07. That is recent activity, but the project's own support policy is more limiting than its repository status. The README states that limited resources restrict maintenance to Tauri's mobile use case. Contributions are welcomed, including template packs, and contributors can contact maintainers through the `#contributing` channel in the Tauri Discord.

Upgrade work has two separate paths. `cargo mobile update` updates the installed tooling. Updating that CLI does not by itself describe application dependency upgrades, native toolchain changes, or generated project migration. The README does not document rollback or automatic regeneration of existing native files.

The package metadata declares `Apache-2.0 OR MIT`, and the repository includes `LICENSE-APACHE` and `LICENSE-MIT`. That is a permissive dual-license declaration, but choosing between the licenses and complying with its conditions remains a project-level legal decision. This review does not interpret the license terms.

cargo-mobile2 versus upstream cargo-mobile and manual setup

cargo-mobile2 is a fork of the original cargo-mobile project. The meaningful difference stated by the README is its operational role: Tauri consumes cargo-mobile2 as a library dependency instead of using the upstream CLI directly. This fork exists to support Tauri's mobile requirements, with maintenance intentionally concentrated on that context. A Tauri integration issue belongs in Tauri's tracker.

The other possible approach is to manage Xcode and Android Studio project structure directly. That avoids depending on cargo-mobile2's template and Cargo subcommands, but it also means taking responsibility for native boilerplate and repeated build, install, and run operations. The README does not claim cargo-mobile2 eliminates all toolchain configuration. Xcode and the Android SDK/NDK remain prerequisites, and unsupported or undocumented cases still require native-project inspection.

The choice therefore turns on framework scope. For Tauri, cargo-mobile2 has a direct architectural reason to exist and a clear issue-reporting route. For an independent Bevy, Dioxus, egui, wgpu, winit, or wry project, the templates are convenient starting points but sit outside the stated support commitment.

Editorial conclusion

Adopt cargo-mobile2 when building Tauri applications with Rust and when accepting its narrow support boundary. Do not choose it for an unrelated Rust mobile framework without first confirming that the generated Xcode and Android Studio projects satisfy your requirements. The first concrete check is whether the selected template pack, required SDK and NDK installations, and `cargo mobile init` output fit the intended application architecture.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. tauri-apps/cargo-mobile2 on GitHub