Build iPhone Apps Without a Mac? What xtool Actually Does (and What the Hype Skips)

If you wanted to build an iPhone app, the usual starting point was a Mac and Xcode. Apple’s iOS SDK ships inside Xcode, which made the development machine part of the decision before you had written much code.

xtool changes where you can do that work. It lets you build, sign and install an iOS app from Linux or Windows through WSL. You can use a PC for the build workflow while still using Apple’s SDK and developer services.

That is a meaningful change for someone who wants to build iOS apps without a Mac. But the details matter: the project format, the Apple download, the account you use and the difference between xtool itself and a separate kit built around it.

What xtool actually does

xtool is an open source, MIT-licensed command-line tool written in Swift. Its core workflow takes a Swift Package Manager package, builds it into an iOS app, signs it and installs it. It can also communicate with Apple Developer Services.

The project runs on Linux, on Windows through WSL and on macOS. Windows support here means running inside Windows Subsystem for Linux. It does not mean a native Windows application doing the build directly.

The app is a Swift package. You describe your application through SwiftPM rather than handing xtool an Xcode project. That is central to understanding the tool: the input is a package, and the output is an app you can sign and install.

On Linux, the prerequisites also include a Swift toolchain and usbmuxd. Installation onto the phone happens over USB. The workflow therefore includes both compiling the application and getting the signed result onto a connected device.

Think about those as separate milestones when evaluating it: preparing the SDK, building the package, signing the app and installing it on the phone. A successful build answers one question. Seeing the application run on your own device answers another.

What the hype skips

You still download Xcode

You still need Apple’s iOS SDK, and that SDK only ships inside Xcode. The documented setup involves a one-time Xcode download from Apple’s developer site, using a free Apple ID. xtool extracts the SDK pieces it needs from that download.

So yes, the build can happen without a Mac. The Apple download remains part of setup. When a headline leaves that step out, it leaves out a dependency you need before trying the workflow.

Read Apple’s license terms for Xcode and its SDKs before using this workflow; this is not legal advice.

SwiftPM is the project format

xtool apps are Swift packages, not Xcode projects. For a new experiment, that tells you how to start. For an existing app, it raises a question you should answer before assuming the project will build: how will it fit this package-based workflow?

A separate conversion helper exists in the Omarchy kit discussed below. Keep that distinction clear when reading demonstrations. A capability added by a wrapper is not automatically a capability of the underlying xtool CLI.

Windows means WSL

If you are evaluating this from Windows, read the WSL path in the xtool installation documentation. Treat WSL as part of your development environment rather than assuming the Linux instructions describe a native Windows setup.

That is also why a result reported on an Omarchy Linux machine should not be presented as a verified result on Windows. The host environment is part of what was tested.

The Omarchy kit adds more pieces

omarchy-apple-dev, by Joshua Warren, is an open source kit that wraps xtool. It targets Omarchy Linux, which is Arch-based, on x86_64 or Apple Silicon.

The kit adds Linux ports of Xcode’s resource compilers for storyboards, asset catalogs, String Catalogs and Core Data models. It also includes a helper to convert an .xcodeproj, USB installation, and TestFlight or App Store upload with a paid account.

Those additions explain why the kit appears in discussions about a broader iOS development workflow on Linux. They also explain why it is useful to identify which project a particular claim describes. The SwiftPM build tool and the kit around it have different scopes.

I have not confirmed that omarchy-apple-dev works on WSL. xtool’s WSL support should not be read as confirmation that this separate kit works there too.

In his account of the workflow, Warren says he built a SwiftUI app on Linux, submitted it to the App Store and debugged it on an iPhone. That is his reported experience. It is useful evidence to investigate, while remaining separate from a result reproduced on your own project.

Flutter support is experimental

The kit’s Flutter support is experimental. The reported verification was on one Omarchy setup with an iPad connected over USB. That is a specific test result, and it should keep that scope when repeated.

TestFlight upload of Flutter apps is also experimental. App Store review of a Flutter app was not tried. Building an app, installing it on a device, uploading it and going through review are separate steps. A result at one step does not establish the result of the next.

If you are following Flutter’s Apple-platform changes, my Flutter 3.47 overview is useful background. Keep that framework reading alongside the kit’s own documentation when deciding what to test. This experimental path needs evaluation against your app before it becomes part of a delivery plan.

Account requirements still matter

xtool’s setup includes a password sign-in option for people who do not have a paid developer membership. Check xtool’s documentation for the limits that apply to free Apple IDs before choosing that route.

A paid account is needed for App Store distribution. The Omarchy kit’s TestFlight and App Store upload paths require one too. Keep account access, device installation and store distribution as separate questions when assessing what you can try.

Who this suits, and who should still get a Mac

My view is that xtool is worth exploring if you already work on Linux, want to experiment with a Swift package-based iPhone app and can make time to understand the build and signing workflow. Start with a small app whose purpose is to prove the process on your machine.

It also suits a developer who wants to understand which parts of building an iOS app belong to the compiler, SDK, packaging, signing and device installation. Working through those stages deliberately can make the experiment valuable even before you decide whether to use it for a larger project.

I would still plan to get a Mac if a client deadline depends on a workflow you have not reproduced, or if your team needs to keep working in its existing Xcode project. In that situation, test an alternative against the actual project before committing delivery dates to it.

For Flutter work, I would treat this as an experiment until I had verified the stages my app needs. The reported iPad installation is interesting, but experimental TestFlight upload and untried App Store review leave questions a production release plan must answer.

If hardware cost is why you are interested, include your setup and investigation time in the decision. Set aside a bounded trial, write down what you need it to prove and decide afterwards whether the result justifies continuing. That keeps the experiment useful even if you ultimately choose a Mac.

The decision should reflect what you need to ship and what you have personally verified. A small learning project gives you room to investigate. A release commitment needs evidence from the project you intend to deliver.

Try it yourself

Start with xtool’s first-app tutorial, reportedly about 30 minutes. Treat that as a guide to the tutorial’s size, not a promise about your setup time. Read the prerequisites before starting.

Use the xtool GitHub repository for the core project and its documentation. If the additional Omarchy workflow interests you, read the separate omarchy-apple-dev repository.

Record your host environment and which stages you complete: SDK setup, build, signing and USB installation. If you investigate distribution, record that result separately. That gives you something more useful than a headline: a clear account of what worked on your machine and what remains to be tried.

Then make one change to the app and repeat the build, sign and install cycle. A repeatable edit-to-device loop gives you a better basis for deciding whether to continue. If a stage fails, name that stage in your notes so you can ask a focused question in the relevant project’s repository.