Building an iPhone app without a Mac: how far Linux gets you
A video says a developer shipped an iPhone app from Linux with no Mac. We unpack the project, compare it with the Mac route and weigh the licensing risk.
For most of the iPhone’s life, shipping an app meant a Mac and Xcode. A short video now claims a developer used only Linux to build an app, submit it to the App Store, install it on an iPhone over USB, and pause it at a breakpoint. The video calls the developer an “Omarchy team” member. The project it refers to, omarchy-apple-dev (GitHub repository), sits under the personal account of Joshua Warren and is not part of the official Omarchy project. This piece sets the video aside and looks at the project itself: what it actually connects, and where it runs out.
Key points
- omarchy-apple-dev is built on the open-source xtool project and chains USB pairing, LLDB debugging and App Store packaging into a set of scripts. Its README records verification on October 3, 2026, on an x86_64 Arch machine.
- It covers USB installs and breakpoint debugging. Wireless deployment is blocked on iOS 26 for Linux-only setups, and Flutter builds are release-only.
- It still needs one download of Xcode from Apple. Whether the Mac requirement is a technical limit or a licensing one is disputed, and the repository itself gives no legal opinion.
What the project actually connects
Developing an iOS app breaks into four stages: compile the code, produce a signed bundle, install and debug it on a phone, and submit it to the App Store. On a Mac, Xcode handles all four. omarchy-apple-dev replaces each stage with a different tool.
The compile stage runs through xtool, which calls the Swift toolchain. xtool is MIT-licensed and describes itself as a cross-platform Xcode replacement. As of October 10, 2026, its repository had about 5,837 stars and was last pushed on October 6. The installer in omarchy-apple-dev builds a patched copy of xtool from source, with four fixes that correspond to xtool issues #290 through #293.
For the phone, the project uses pymobiledevice3 for USB pairing and installation, and device-run.sh launches the app. Breakpoints come from LLDB, which ships with the Swift toolchain at version 21.0.0 according to the README. For signing and packaging, it uses rcodesign. ship.sh checks the bundle layout, Info.plist keys, Mach-O architecture and provisioning profile locally, and it stops on any failure. The last stage calls the App Store Connect build-upload API directly.
The most important limit sits in the middle of that chain. The README is direct about it: the iOS SDK components exist only inside Apple’s Xcode distribution, so extracting the SDK from an Xcode.xip cannot be automated away. Leaving the Mac behind does not mean leaving Apple’s files behind.
Comparing it with the Mac route
The table below includes only facts that the README or Apple’s own pages support.
| Stage | Mac with Xcode | omarchy-apple-dev on Omarchy |
|---|---|---|
| Compiling SwiftUI | Toolchain bundled with Xcode | xtool calls the bundled Swift 6.4.0 |
| SDK source | Xcode installation | Extracted once from Apple’s Xcode.xip, then cached |
| USB install on a phone | Xcode device interface | device-run.sh installs through pymobiledevice3 |
| Breakpoint debugging | Xcode debugger | LLDB 21.0.0; --lldb needs no root |
| Wireless deployment | A Mac that once enabled “Connect via Network” keeps a wireless tunnel | iOS 26 refuses Linux-only hosts a tunnel, so USB is the only route |
| App Store packaging | Xcode Archive | ship.sh packages, validates offline, and optionally uploads |
| Flutter | Full support | Release mode only, with no debug mode or hot reload |
The table shows what Linux saves and what it does not. The route removes the Mac as a machine, not Apple’s developer resources. For everyday work, an app that does not depend on extensions, widgets or the simulator can run end to end. The README reports that the full mode builds IceCubesApp, and that NetNewsWire, with its extensions and 15 frameworks, passed App Store Connect processing. The no-xcode experimental mode skips the Xcode download, but its list of system frameworks and its SwiftUI subset are both narrow.
How strong is the evidence
The video and the author’s X post make the same claim, but both are the author’s own account. What a reader can check is the repository. The README records an install run from a fresh user account on an x86_64 Arch system on October 3, 2026, and a community member’s report from September 15, 2026, who built a real client project on a Framework Desktop with an iPhone 16. Flutter has its own signed-build receipt in the repo.
The author’s post says “Apple says you need a Mac to build iPhone apps.” We checked Apple’s Xcode page, and its body text does not state a Mac requirement. The download link points to the Mac App Store. The common assumption that a Mac is mandatory therefore does not appear as a plain statement in Apple’s public text. That does not prove the assumption wrong. It shows that the disagreement lives in how the rules are read, not in one clear sentence. We did not run this workflow ourselves, so every statement about tool behavior here comes from the repository documentation and the author’s own account, not from our testing.
The pushback: technical or licensing?
The sharpest reply under the post came from the app developer praeclarum, who wrote that this was never a technical hurdle and that it is a license hurdle. In his reply, the author said that for a separate project, omarchy-mlx, which runs open-source AI on Apple Silicon under Linux, he had expected a note from Apple’s lawyers or hiring managers. So far, he said, Apple seems to tolerate open-source work of this kind. A third reply warned, half as a joke, that all of this is fun until someone makes you disappear.
None of these replies is legal advice, and we found no public Apple text that forbids the approach. They do point to the same question, though. Whether this route holds over time depends on Apple’s stance and on each user’s judgment about risk, not only on whether the code runs. The repository does not settle that question either, so a reader should work it out before relying on the approach.
When it is worth trying
Three kinds of reader have a good reason to try it. The first has a Linux workstation already and wants to write a small SwiftUI tool and run it on their own iPhone. The second works in Flutter on Linux and needs a release build that is signed and checked locally. The third wants to understand how the iOS toolchain fits together, and reading the repository is a good way to learn that.
Other readers should look elsewhere. A team that needs the simulator or UI automation should keep using Xcode. A project built around widgets, extensions or macOS apps should choose the full mode and verify each piece. A commercial team that plans to ship publicly and has no tolerance for licensing uncertainty should consult a lawyer first and should not treat this route as a delivery plan.
There are also practical constraints. The iOS version and the Xcode version have to match, and the README pairs Xcode 27 with swift-bin 6.4. TestFlight and App Store distribution need a paid developer account, while device installs do not. Wireless deployment on iOS 26 depends on a Mac that once enabled “Connect via Network”, since a Linux host cannot claim the tunnel.
What to watch next
Three things are worth tracking. The first is upstream. xtool was last pushed on October 6, and omarchy-apple-dev depends on its patched build, so upstream changes could affect whether the project installs cleanly. The second is independent reproduction. Most of the verification so far comes from the author and one community member, and results on more machines will show whether the route is stable. The third is review. ship.sh can produce a package that validates offline and shows as VALID in App Store Connect, but it never submits a build for review, and the README admits that App Store review has not been tried for the no-xcode mode.
If the question is whether this is real, the answer is yes. The build, USB install, breakpoint debugging and upload each have a documented path, and the repository is public, so you can run it yourself. If the question is whether Linux can safely replace the Mac, the answer is still no. The repository does not make that claim, and the open licensing question is the reason.