Skip to content

xtool

Builds, signs and installs SwiftPM iOS apps from Linux, WSL or macOS without Xcode, so a Linux agent can ship to an iPhone.

Reviewed by Sheela · Updated

View on GitHub Open source

Our rating

3.9/5

xtool puts iOS builds within reach of a Linux agent, but Apple's sign-in still needs a human and a plugged-in phone.

What is xtool?

xtool is a cross-platform replacement for the parts of Xcode that turn code into an installed iOS app. It builds a Swift Package Manager project into an app, signs it, provisions it through Apple Developer Services and installs it on a USB-connected iPhone or iPad, from Linux, Windows through WSL, or macOS. A library, XKit, exposes the same provisioning and device functions to other Swift programs.

xtool is not an AI project. It is relevant here because coding agents mostly run in Linux terminals and containers, where iOS builds were previously impossible; with xtool the build, sign and install steps become shell commands an agent can run. The agent integration comes from a third-party skill by 2389 Research, not from the xtool repository.

It still depends on Apple: on Linux you need a Swift 6.4 toolchain, usbmuxd to talk to the device, and an Xcode.xip downloaded with your Apple ID, from which xtool extracts an iOS SDK. On macOS, Xcode itself must be installed.

Is xtool worth it?

xtool removes the Mac from the build-sign-install loop for SwiftPM iOS apps, a job Apple's own tools only do on a Mac. The repository has about 14,000 GitHub stars, is MIT-licensed, has been developed since November 2024 and shipped 1.24.0 on 26 October 2026. For a coding agent confined to a Linux VM, that turns an iOS app from a dead end into something it can compile and put on a device with `xtool dev`.

It replaces Xcode the tool, not Apple's SDK. Setup on Linux means installing Swift 6.4, usbmuxd and the xtool AppImage, then pointing `xtool setup` at an Xcode 27.1 archive that you download in a browser after signing in and accepting Apple's licence. Login has two modes: an App Store Connect API key, which needs the paid developer programme and is the documented recommendation, or your Apple ID password, which works with any account but relies on private Apple APIs; the docs suggest a throwaway Apple ID for the latter. Since 1.22.2, password login presents itself to Apple as a Pixel 7 device.

That private-API path is where the churn is. Apple ID users had to log in again after 1.22.2 on 14 October and again after 1.23.0 on 22 October, 1.24.0 fixed another source of HTTP 503 errors at sign-in, and an open issue (#407) reports 2FA codes never arriving on 1.24.0. Version 1.20.0 moved builds to SwiftBuild and required reinstalling the Darwin SDK. Six releases landed between 21 September and 26 October, and there are 124 open issues and pull requests, including mistyped xtool.yml keys being silently ignored (#353) and signing failures on app extension targets (#379).

The gaps against Xcode are structural. According to byteiota, there is no simulator on Linux, no SwiftUI previews and no Instruments, and apps sideloaded with a free account expire after 7 days. byteiota also describes a Claude Code skill for xtool; that skill is 2389 Research's using-xtool plugin, which mainly stops agents confusing xtool.yml with XcodeGen's project.yml, and the xtool repository itself ships only contributor notes for agents. The result is a half-automated loop: the agent can write, build and install, but a person still plugs in the phone, approves the 2FA prompt and checks the screen.

Where it earns its place

  • A developer at a two-person studio who works on Linux and owns an iPhone but no Mac

    Get a SwiftUI prototype running on my own phone

    Install Swift 6.4, usbmuxd and the AppImage, extract the SDK from Xcode.xip, then `xtool new` and `xtool dev`. Free with password login on a spare Apple ID, but sideloaded builds expire after 7 days and sign-in has broken several times in October 2026.

  • A platform engineer running Claude Code agents in Linux VMs

    Let the agent compile and install iOS builds instead of stopping at Swift code

    Add 2389 Research's xtool plugin so the agent uses xtool.yml and `xtool dev` correctly, and attach a test iPhone over USB. API-key login avoids storing an Apple ID password on the VM; a human still handles device trust and checks the result.

  • The CTO of a small app company paying for macOS CI minutes

    Move routine iOS build checks to cheaper Linux runners

    byteiota puts macOS GitHub Actions runners at roughly ten times the cost of Linux ones, so compiling SwiftPM targets on Linux saves money on every push. It needs an extracted Darwin SDK on the runner, and projects tied to .xcodeproj files must be converted first.

Before you commit

Setup
Linux or WSL: Swift 6.4 toolchain, usbmuxd (USBIPD passthrough on WSL), the xtool AppImage from GitHub releases, and Xcode 27.1's .xip for `xtool setup` to extract an iOS SDK. macOS: `brew install xtool-org/tap/xtool` with Xcode installed.
Integrations
Swift Package Manager projects configured with xtool.yml; App Store Connect API keys or Apple ID login; libimobiledevice tools for device access; the XKit SwiftPM library; a third-party using-xtool skill for Claude Code and npx skills from 2389 Research.
Data and privacy
Credentials go to Apple only, according to the docs; password mode uses private Apple APIs and identifies as a Pixel 7 device. No telemetry is documented. MIT licence.
Cost at scale
Free. Distribution through TestFlight or the App Store still requires the $99-a-year Apple Developer Program; the saving is Mac hardware and macOS CI minutes, which byteiota puts at about ten times Linux runner prices.
Limits
No Linux simulator, SwiftUI previews or Instruments; Windows only through WSL; 124 open issues and pull requests; Apple ID login has needed re-authentication twice in October 2026 and 2FA failures are reported on 1.24.0.

What's good

  • Builds and installs iOS apps from Linux and WSL
  • Plain SwiftPM projects; no .xcodeproj to maintain
  • API-key login uses Apple's public App Store Connect API
  • XKit library exposes provisioning and device control

What's not

  • Password login uses private Apple APIs and breaks often
  • Still needs Xcode.xip from Apple and a physical device on Linux
  • No simulator, previews or Instruments on Linux
  • Re-login and SDK reinstalls between recent releases

Best for

Developers and agent setups on Linux or Windows that need to build and install SwiftPM iOS apps on a real device without a Mac.

xtool: common questions

Is xtool worth it?
xtool puts iOS builds within reach of a Linux agent, but Apple's sign-in still needs a human and a plugged-in phone. We rate it 3.9 out of 5.
How much does xtool cost?
Free and open source (MIT). Password login works with any Apple ID; API-key login and App Store or TestFlight distribution need the paid Apple Developer Program ($99 a year).
What are the downsides of xtool?
Password login uses private Apple APIs and breaks often; still needs Xcode.xip from Apple and a physical device on Linux; no simulator, previews or Instruments on Linux; re-login and SDK reinstalls between recent releases.
Who is xtool best for?
Developers and agent setups on Linux or Windows that need to build and install SwiftPM iOS apps on a real device without a Mac.
How much does xtool cost for a team or in production?
Free. Distribution through TestFlight or the App Store still requires the $99-a-year Apple Developer Program; the saving is Mac hardware and macOS CI minutes, which byteiota puts at about ten times Linux runner prices.
Is xtool safe for company data?
Credentials go to Apple only, according to the docs; password mode uses private Apple APIs and identifies as a Pixel 7 device. No telemetry is documented. MIT licence.

Answers checked Oct 28, 2026.