# xbuild and the ambition to make native apps build like web apps > xbuild is a Rust build tool that cross compiles Rust projects and packages them for mobile and desktop stores, from one command per target format. Its own repository description calls it unmaintained, the last tag is an alpha from 2025, and that combination is the first thing to weigh before anything else. **rust-mobile/xbuild** — Cross compile rust to any platform (unmaintained) - Repository: https://github.com/rust-mobile/xbuild - Stars: 672 · Forks: 68 - Language: Rust - License: not declared - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/rust-mobile-xbuild ## One build command per target format, driven by a workspace of crates xbuild is described as a build tool for Rust projects with support for cross compiling and publishing to all major stores, and the stated goal is making native app development as easy as web development. The architecture is visible in the Cargo workspace, which lists the packaging formats as separate member crates: ```toml [workspace] members = [ "apk", "appbundle", "appimage", "mvn", "msix", "pri", "xbuild", "xcommon", ] default-members = ["xbuild"] exclude = ["examples"] ``` Each of those directories is a packaging backend. apk produces an Android package, appbundle produces an Android app bundle, appimage produces a Linux AppImage, msix produces a Windows Store package, mvn handles the Maven project layout that Android tooling expects, and pri is the shared code behind the Apple platform targets. xbuild is the command line front end and xcommon holds the pieces the backends share. That structure is the design. Rather than one binary that knows about every store, the packaging logic for each format lives in its own crate, and the default member is the CLI alone, so a normal cargo build in the repository root builds the tool and not the whole set of backends. The tool is written in Rust, the licence in the README is Apache-2.0 OR MIT, and the repository top level shows the same separation in directories alongside the workspace manifest. The repository description is blunt about the state of the project: it says unmaintained in parentheses after the summary. The last push was on 2026-07-21, and the recent tags are v0.1.0+4 from 2022-12-09, v0.2.0 from 2022-12-21 and v0.2.1-alpha from 2025-08-15. ## Devices are addressed by an adb or imd identifier The first thing the tool does is list what it can talk to, and the identifier scheme is the part worth understanding. The x devices command prints a table with a device identifier, a friendly name, a platform and architecture, and an operating system version: ```sh x devices host Linux linux x64 Arch Linux 5.16.10-arch1-1 adb:16ee50bc FP4 android arm64 Android 11 (API 30) imd:55abbd4b70af4353bdea2595bbddcac4a2b7891a David’s iPhone ios arm64 iPhone OS 15.3.1 ``` Every target has a prefix that says which transport reaches it. The host is prefixed with host, an Android device is prefixed with adb followed by the serial, and an iOS device is prefixed with imd followed by a long identifier. The rest of the identifier is the device's own key, so a device is named by its transport plus its identity. That scheme carries through to the build command, where the device is selected with the same string: ```sh x build --device adb:16ee50bc ``` The output shows the pipeline in three numbered stages: fetch precompiled artifacts, build rust, and create apk. The first stage reports that the component for the target aarch64-linux-android is up to date, which is the prebuilt standard library for the target triple being fetched rather than compiled from source. The second stage is the Rust compilation itself, and the third is packaging the result into an apk. For a Rust developer the most interesting part is that the Rust build is genuinely just cargo under the hood. The same Cargo.toml, the same crates, the same features. What xbuild adds is the part that has nothing to do with Rust, which is the packaging and the device handling. ## x doctor is the first command to run on a new machine The troubleshooting section starts with a case that is not xbuild's fault, and the answer is a diagnostic command. x doctor is documented as letting you know if there are any external tools missing, and the output is a report of the toolchain grouped by area, with a version and a path for each binary: ```sh x doctor --------------------clang/llvm toolchain-------------------- clang 14.0.6 /usr/bin/clang clang++ 14.0.6 /usr/bin/clang++ llvm-ar unknown /usr/bin/llvm-ar ``` The rest of the report covers rust, with rustup and cargo, android, with adb, javac, java, kotlin and gradle, ios, with the libimobiledevice family such as idevice_id, ideviceinfo, ideviceinstaller, ideviceimagemounter and idevicedebug, and linux, with mksquashfs. That grouping is the dependency list of the whole tool in one screen. Producing an apk needs the Android SDK and a Java toolchain, producing an AppImage needs squashfs tooling, and producing anything for iOS needs the libimobiledevice utilities to talk to the device. The report is more useful than a package list because it shows what is present, at what version, and where. The missing entries are the failure signal. A build that fails because a tool is absent is the most likely first failure, and x doctor answers it in one command. The presence of unknown versions for some llvm tools also shows that the tool reports what it can detect rather than asserting that everything is correct. ## The two hard problems are GTK headers and Apple signing The troubleshooting section names two failures that are not about Rust at all, and they are the real cost of this tool. The first is a build script failure in glib-sys, which the documentation explains means that gtk3-dev is not installed, and the fix is to install the gtk3-dev package. This is the classic cross compilation trap. A crate that binds to a system library needs the C headers for the target, and the error surfaces as a failing custom build command in a crate whose name says nothing about graphics. The message is about glib-sys, the cause is a missing GTK development package, and the fix is a system package install. The second is Apple signing, and here the documentation is explicit about the limit. Without an apple developer account there is no cross platform way of generating mobile provisioning profiles, and the two options offered are to work it out using xcode or to use a tool called cook. The same applies to signing keys and certificates, where the pointer is to a separate document on apple codesign certificate management. Both of these are the point where the promise of native development being as easy as web development meets the platform. A web build has no code signing step and no per-target C library headers. The iOS path in particular cannot be made fully automatic without an Apple developer account, and the tool does not pretend otherwise. The mitigation is that x doctor tells you which pieces of the external toolchain are present, so the failure surfaces as a missing entry in a report rather than as a compiler error deep in a build script. ## What the release history says about adopting it The version sequence is short and tells the story. v0.1.0+4 came out on 2022-12-09, v0.2.0 on 2022-12-21, twelve days later, and then v0.2.1-alpha on 2025-08-15. After the alpha there is nothing tagged, but the last push was on 2026-07-21. So the project moved fast for about two weeks in December 2022, then went quiet on releases for nearly three years before an alpha, and has continued to receive commits since without cutting another tag. Combined with the repository description calling it unmaintained, the honest reading is that this is a codebase in a stalled state with occasional work rather than a project on a release cadence. The distinction between the last push and the last release matters more here than it does for a library, because xbuild is a tool that shells out to a changing toolchain. Android SDK versions, Gradle versions, Kotlin versions and the Rust target list all move. A tool that knows the state of those things in 2022 is not necessarily able to drive them in 2026, and the alpha tag from 2025 does not tell you what the current commit does. The licence is Apache-2.0 OR MIT, which is the most permissive combination available and means adopting the code carries no obligations. The repository is not archived, so the code is still there to read and to fork. For a team considering it, the cost is not the licence and not the installation, which is a single cargo install. The cost is that you would be depending on a tool whose own description says it is unmaintained, and the fallback when it fails is reading its source. ## Where xbuild is the wrong tool The first wrong case is shipping to a store with a deadline. The tool builds a signed artefact, and signing is exactly the part that depends on a platform's current requirements, on an account, and on tooling that is being updated. A project with a release date needs a build path that somebody is accountable for, and this one is not. The second wrong case is a team that already has a working native build. If your Android project already builds through Gradle with a configured NDK, and your iOS project already builds through Xcode, then xbuild replaces a pipeline that works with one you have to validate from scratch, including the signing story and the glib-sys class of problem. The value of a build tool is that it removes work, and if the work is already done elsewhere, the tool is only risk. The third is a target that is not in the workspace. The members list covers apk, appbundle, appimage, mvn, msix and pri. A Linux distribution package, a Homebrew formula or a Snap is not in that list, and the exclusion of examples from the workspace hints that the crates are still being developed against sample projects rather than a settled target matrix. The alternative worth naming is assembling the toolchain directly, which is what xbuild wraps. For Android, that means the Android SDK and NDK with a cargo target and a linker configuration, and for iOS it means Xcode with the Rust targets installed for the device architecture. The difference in approach is that the hand-assembled route produces a build you fully understand and can debug, at the cost of writing the config once per project, while xbuild produces a uniform command across formats and hides the toolchain wiring that is exactly what goes wrong. The sensible middle path for most people is to use the platform tools for the platform you actually ship to, and to treat xbuild as an experiment for the formats you do not have a pipeline for yet. ## Conclusion xbuild fits an engineer experimenting with Rust on Android or iOS who wants one command instead of a hand-wired NDK, Xcode and Gradle toolchain, and who is willing to read the source when it breaks. It is the wrong choice for a team shipping to a store today, because the repository describes the project as unmaintained, the last push was on 2026-07-21 and the most recent tag is v0.2.1-alpha. Before you plan around it, check the target formats in the Cargo workspace members, run x doctor on a machine with the Android and iOS tooling installed, and decide whether you would rather assemble the toolchain yourself with cargo-ndk and the platform tools. ## FAQ ### What is xbuild? xbuild is a build tool for Rust projects with support for cross compiling and publishing to all major stores, with the goal of making native app development as easy as web development. It is written in Rust and its README states the licence as Apache-2.0 OR MIT. ### How do I install xbuild? With cargo install xbuild, from a shell. The tool is published on crates.io and the README gives that single command under Getting started. ### Which packaging formats does xbuild support? The Cargo workspace has a member crate per format, listing apk, appbundle, appimage, mvn, msix and pri, alongside the xbuild command line crate and the shared xcommon crate. The README also describes publishing to all major stores. ### What is x doctor for? The README says x doctor should let you know if there are any external tools missing. It prints the versions and paths of the clang and llvm toolchain, rustup and cargo, the android tools, the ios libimobiledevice utilities and the linux tools. ### Is xbuild still maintained? The repository description calls it unmaintained. The last push was on 2026-07-21 and the most recent tag is v0.2.1-alpha from 2025-08-15, with earlier releases v0.2.0 and v0.1.0+4 both from December 2022. ## Sources - [Issues](https://github.com/rust-mobile/xbuild/issues) - [README](https://github.com/rust-mobile/xbuild/blob/master/README.md) - [Releases](https://github.com/rust-mobile/xbuild/releases) - [rust-mobile/xbuild on GitHub](https://github.com/rust-mobile/xbuild) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rust-mobile-xbuild