# xtool: build and deploy iOS apps with SwiftPM on Linux and Windows

> xtool-org/xtool replaces parts of Xcode with an open toolchain that turns a SwiftPM package into a signed iOS app. It is aimed at Swift developers who do not want to keep a Mac in the build loop, and it comes with real constraints around SDKs, signing and device access.

**xtool-org/xtool** — Cross-platform Xcode replacement. Build and deploy iOS apps with SwiftPM on Linux, Windows, macOS.

- Repository: https://github.com/xtool-org/xtool
- Website: https://xtool.sh
- Stars: 5,514 · Forks: 156
- Language: Swift
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/xtool-org-xtool

## What xtool actually replaces, and who needs that

The README describes xtool as a cross-platform Xcode replacement that lets you "Build and deploy iOS apps with SwiftPM on Linux, Windows, and macOS." That sentence is the whole product thesis. If your app is a SwiftPM package, xtool takes it the rest of the way: producing an iOS app bundle, signing it, and pushing it to a device.

The audience is narrow but real. A Swift developer on Linux or Windows who wants to ship an iOS build normally faces a hard dependency on macOS hardware, because Xcode is the only supported path to an .app bundle and to the signing steps that follow. xtool targets exactly that gap. It also targets people who want Apple Developer Services available from scripts rather than from the Xcode GUI, which is what the ds subcommand and the XKit library are for.

It is not a general purpose iOS development environment. The README lists three capabilities: build a SwiftPM package into an iOS app, sign and install iOS apps, and interact with Apple Developer Services programmatically. There is no claim about storyboards, asset catalogs, Instruments, or the simulator. Anyone whose project needs those should read the rest of this article as background rather than as a migration plan.

## The xtool command surface: setup, sdk, dev, devices

The CLI is organized into four groups, and the grouping tells you how the tool expects to be used. Configuration subcommands are setup, auth and sdk. Development subcommands are new, dev and ds. Device subcommands are devices, install, uninstall and launch.

The sdk subcommand manages the Darwin Swift SDK. That is the mechanism that makes cross-platform iOS builds possible at all: without a Darwin SDK on the host, SwiftPM cannot target Apple platforms. The auth subcommand manages Apple Developer Services authentication, which is what signing and provisioning depend on. The ds subcommand exposes Apple Developer Services directly, so certificate or profile operations can be scripted instead of clicked through.

On the device side, install takes an ipa file, and launch starts an installed app. That split matters: xtool does not assume it built the ipa you are installing. You can build with xtool and install with xtool, or bring an ipa from somewhere else and use only the device half of the tool.

The README does not document what happens when a device is connected but not trusted, or how install behaves against a locked device. Those are the first things to check on real hardware.

## Installing xtool and running a first project

The README does not inline installation commands. It points to two guides, one for Linux and Windows and one for macOS, under xtool.sh/documentation/xtooldocs. Follow those for your platform rather than guessing at a package name.

Once xtool is on the PATH, the README's own help output is the best map of the tool. Running it with no arguments beyond help prints the subcommand groups described above, including the configuration, development and device groups.

```bash
$ xtool --help
OVERVIEW: Cross-platform Xcode replacement

USAGE: xtool <subcommand>

OPTIONS:
  -h, --help              Show help information.
```

The README then sends new users to a tutorial at xtool.sh/tutorials/xtooldocs/first-app, which covers creating and running a first xtool-powered app. The relevant subcommands for that path are new (create a project), dev (build and run it), and, once a device is attached, devices, install and launch.

The repository also ships a Docker-based development path. The Makefile defines a linux-dist target that runs Linux/build.sh inside the compose service, and a docker target that builds the image as ghcr.io/xtool-org/xtool:latest.

```bash
docker compose run --build --rm xtool Linux/build.sh
```

The compose file mounts the repository at /xtool, adds sys_ptrace and an unconfined seccomp profile, and maps host.docker.internal to the host gateway so device communication can reach the host. If you are evaluating xtool without installing it system-wide, that container is the least invasive way to see the CLI.

## Using XKit as a SwiftPM dependency

xtool is not only a binary. The README states that it includes a library for interacting with Apple Developer Services, iOS devices and more from your own app, and that you add it as a SwiftPM dependency on the XKit product.

```swift
// package dependency:
.package(url: "https://github.com/xtool-org/xtool", .upToNextMinor(from: "1.2.0"))
// target dependency:
.product(name: "XKit", package: "xtool")
```

Two details are worth noting. The version requirement shown is .upToNextMinor from 1.2.0, which is stricter than the usual upToNextMajor and means minor releases can carry breaking changes by design. And the package URL is the xtool repository itself, not a separate XKit repository, so pulling XKit pulls the whole project. That is a heavier dependency than a small focused library would be.

The README does not enumerate XKit's types or describe its API surface. If you are considering it for device automation or Developer Services calls, plan to read the source under Sources/ rather than relying on published documentation.

## Where xtool stops: SDKs, signing and Xcode-only projects

The biggest constraint is implied by the architecture rather than stated as a warning. xtool builds SwiftPM packages. A project that is an .xcodeproj with custom build phases, run script phases, CocoaPods integration or Interface Builder files is not described anywhere in the README as supported. Converting such a project to SwiftPM is a prerequisite, and for large apps that conversion is the actual work.

Signing is the second boundary. xtool signs and installs iOS apps, and it authenticates against Apple Developer Services through xtool auth. That means you still need a paid Apple Developer account and the certificates and provisioning profiles that go with it. xtool removes the Mac, not the account. The README does not explain how certificates are created or renewed, so treat that as undocumented until you find it in the installation guides.

Third, the Darwin Swift SDK has to exist for your target. The sdk subcommand manages it, but the README does not say which iOS SDK versions are available or how they are updated. Version drift between the SDK xtool provides and the iOS version you target is a real risk.

Finally, the project is built on libimobiledevice and related libraries. The Dockerfile pulls libplist 2.6.0, libimobiledevice-glue 1.3.1, libusbmuxd 2.1.0 and libtatsu 1.0.4, but builds libimobiledevice itself from the master branch rather than a pinned tag. Depending on an unpinned upstream branch means device communication behavior can shift without any change in xtool's own release notes.

## xtool compared with keeping a Mac build agent

The obvious alternative is not another open source tool but the conventional setup: a macOS machine or CI runner with Xcode installed, building the app and exporting an ipa. That approach supports everything Xcode supports, including projects xtool cannot touch, and it is the path Apple documents.

The difference in approach is where the build happens and what defines the project. With a Mac agent, the .xcodeproj or workspace is the source of truth and Xcode orchestrates compilation, signing and packaging. With xtool, the SwiftPM package is the source of truth and xtool orchestrates those same steps using open standards, as the README puts it, with the Darwin Swift SDK supplying the Apple platform pieces.

That trade is straightforward. You gain the ability to build on Linux or Windows hosts and to script Developer Services calls, and you lose compatibility with anything that only Xcode understands. A team with a single SwiftPM library plus a thin app target gets most of the benefit. A team with a mature Xcode project and a stable Mac CI fleet gains little and takes on a conversion project.

Cost matters too. Mac runners are typically the most expensive part of an iOS CI pipeline, so removing them is the main economic argument for xtool. The README does not make that argument, and it publishes no build time or resource figures, so treat the savings as something to measure on your own workload rather than as a documented number.

## Maintenance, licensing and what to watch between releases

The repository is not archived, and the last push was on 2026-09-22. Releases are frequent: 1.20.1 on 2026-09-21, 1.20.0 on 2026-09-21, and 1.19.2 on 2026-09-11. That cadence cuts both ways. Fixes arrive quickly, but so do minor versions, and the README's own example pins XKit with .upToNextMinor, which suggests minor releases are expected to carry changes that can affect dependents. Pin exact versions in Package.resolved and read the release notes before bumping.

The licence is MIT. That is permissive: you can use xtool and XKit in commercial and closed-source products, and you can modify and redistribute them, provided the copyright notice and licence text are preserved. It says nothing about Apple's SDKs, certificates or Developer Program terms, which are governed separately by Apple, and nothing here should be read as legal advice about redistributing Apple toolchain components.

Upgrade cost is mostly the SDK and the device stack. Because libimobiledevice is built from an unpinned upstream branch in the Dockerfile, rebuilding the image can pull different device-layer code even when the xtool version is unchanged. If you build your own image from this Dockerfile, record the commit you built from. The README does not document a rollback procedure for SDK or device-stack changes.

## Conclusion

xtool is worth adopting if you already write Swift packages and want iOS builds and device installs to happen on Linux or Windows machines. It is the wrong choice if your project depends on Xcode-only build phases, Interface Builder or Apple's own simulator workflows, since the README describes a SwiftPM-centered toolchain, not an Xcode clone. Before committing, verify that the Darwin Swift SDK for your target OS is available through the sdk subcommand, that your Apple Developer account can create the certificates and provisioning profiles xtool needs, and that your device appears under xtool devices. The Dockerfile pins Swift 6.3.3 and builds libimobiledevice from source, so check that the container target you pick matches the platform you deploy from.

## FAQ

### What is xtool-org/xtool?

It is a cross-platform Xcode replacement that builds and deploys iOS apps from SwiftPM on Linux, Windows and macOS. The README lists three capabilities: building a SwiftPM package into an iOS app, signing and installing iOS apps, and interacting with Apple Developer Services programmatically.

### How do I install xtool?

The README does not inline install commands. It links to two guides, Installation (Linux/Windows) and Installation (macOS), both under xtool.sh/documentation/xtooldocs.

### Does xtool work without a Mac?

The README describes Linux, WSL and macOS as supported hosts and lists a separate macOS installation guide, so Linux and Windows are treated as first-class platforms. You still need an Apple Developer account, since xtool signs apps and authenticates against Apple Developer Services.

### Can I use xtool as a library in my own app?

Yes. The README says xtool includes a library called XKit that you add as a SwiftPM dependency, with the product name XKit from the xtool package. The README does not document XKit's API surface beyond that.

### What licence does xtool use?

The repository is MIT licensed. That permits commercial and closed-source use as long as the copyright notice and licence text are preserved, but it does not cover Apple's SDKs, certificates or Developer Program terms.

## Sources

- [License: MIT](https://github.com/xtool-org/xtool/blob/main/LICENSE)
- [Project website](https://xtool.sh)
- [README](https://github.com/xtool-org/xtool/blob/main/README.md)
- [Releases](https://github.com/xtool-org/xtool/releases)
- [xtool-org/xtool on GitHub](https://github.com/xtool-org/xtool)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xtool-org-xtool