不用 Mac 做 iPhone 应用：Linux 路线能走多远
一条视频称仅用 Linux 就能做 iPhone 应用。本文拆解背后的开源项目，比较 Mac 路线，并讨论授权风险。
长期以来，做 iPhone 应用几乎等于一台 Mac 加一份 Xcode。一条视频号内容则说，有开发者仅用 Linux 就打通了整条流程：构建、提交 App Store、通过 USB 装到 iPhone 并在断点处暂停。视频把作者称为“Omarchy 团队开发者”，但他的开源项目 omarchy-apple-dev（GitHub 仓库）挂在他个人的账号下，并非官方 Omarchy 仓库。本文不复述视频，而是拆开这个项目，看它真正打通了什么，又卡在哪里。
要点
- omarchy-apple-dev 建立在开源项目 xtool 之上，把 USB 配对、LLDB 调试、App Store 打包串成一组脚本。README 记录的验证时间是 2026 年 10 月 3 日，环境是 x86_64 的 Arch 系统。
- 它能覆盖 USB 真机安装和断点调试，但无线部署在 iOS 26 上被阻，Flutter 只支持 release 构建。
- 它仍然需要一次 Apple 官方 Xcode 下载，而 Apple 与 Mac 之间的授权边界，社区有人认为才是真正的门槛，仓库本身不给出法律意见。
它打通了哪几段
把 iOS 开发拆开，大致有四段：写代码与编译，生成签名后的应用包，把应用装进手机并调试，最后提交 App Store。Mac 路线里这四段都由 Xcode 完成。omarchy-apple-dev 的做法是用其他工具替换每一段。
编译这一段，它用 xtool 调用 Swift 工具链。xtool 在 GitHub 上以 MIT 协议开源，自我介绍为“跨平台的 Xcode 替代品”，仓库截至 2026 年 10 月 10 日约有 5,837 颗星，最近推送在 10 月 6 日。omarchy-apple-dev 的安装脚本会从源码构建一个打过四处补丁的 xtool 版本，补丁对应 xtool 仓库的 #290 至 #293 号议题。
真机这一段，它用 pymobiledevice3 完成 USB 配对与安装，device-run.sh 再把应用启动起来。断点调试靠的是 Swift 工具链自带的 LLDB，README 写明版本为 21.0.0。签名与打包这一段，它用 rcodesign 签名，ship.sh 在本地检查包结构、Info.plist、Mach-O 架构和描述文件，检查失败就停止。上传这一段，它直接调用 App Store Connect 的构建上传接口。
最关键的一处限制也在这里。README 写得很直接：iOS SDK 的组件只存在于 Apple 的 Xcode 发行包中，因此“从 Xcode.xip 中取出 SDK”这一步无法自动化掉。没有 Mac，并不代表没有 Apple 的文件。
和 Mac 路线逐项对比
下表只列 README 或官方页面能支撑的事实。
| 环节 | Mac 加 Xcode | omarchy-apple-dev（Omarchy） |
|---|---|---|
| 编译 SwiftUI | Xcode 自带的工具链 | xtool 调用自带的 Swift 6.4.0 |
| SDK 来源 | Xcode 安装包 | 从 Apple 的 Xcode.xip 中提取一次并缓存 |
| USB 真机安装 | Xcode 设备界面 | device-run.sh 经 pymobiledevice3 安装 |
| 断点调试 | Xcode 调试器 | LLDB 21.0.0，--lldb 模式无需 root |
| 无线部署 | 启用过“通过网络连接”的 Mac 保有无线隧道 | iOS 26 上 Linux 独占隧道被阻，只能用 USB |
| App Store 打包 | Xcode Archive | ship.sh 打包、离线校验，可选上传 |
| Flutter | 完整支持 | 仅 release 模式，没有 debug 与热重载 |
表格说明了分工。Linux 路线省掉的是 Mac 这台机器本身，而不是 Apple 的开发资源。日常开发中，只要应用不依赖扩展、小组件或模拟器，它能覆盖的范围就已经不小。README 称，在完整模式下可以编译 IceCubesApp，并且 NetNewsWire 连同扩展与 15 个框架通过了 App Store Connect 的处理。另一方面，no-xcode 实验模式不需要 Xcode 下载，但可用的系统框架与 SwiftUI 子集都很有限。
证据有多硬
视频与作者的 X 帖子说的是同一件事，但它们只是作者本人的陈述。能独立核对的是仓库本身。README 记录的验证环境包括 2026 年 10 月 3 日在 x86_64 Arch 上以全新用户跑通的安装流程，以及一位社区成员 2026 年 9 月 15 日在 Framework Desktop 上用 iPhone 16 完成真实客户项目的报告。Flutter 的签名 .ipa 也有单独的收据文件记录。
作者 X 帖子的说法是“Apple says you need a Mac”。我们检查了 Apple 的 Xcode 页面，正文中没有找到 Mac 必需的表述，页面上的下载链接指向 Mac App Store。也就是说，“必须用 Mac”这个常识，在 Apple 的公开正文中并没有被逐字确认。这不证明它成立，只说明争论点落在解释上，而不在一句明确的官方条文上。需要说明的是，本文作者没有在本机跑通这条流程。文中关于工具行为的描述全部来自仓库文档和作者记录，并非本站的实测。
授权还是技术问题
帖子下面最尖锐的一条回复来自 App 开发者 praeclarum，他写道：技术上从来不是障碍，卡住的是授权。作者在回复中提到，他的另一个项目 omarchy-mlx（让开源 AI 在 Linux 下的 Apple Silicon 上运行）一开始就预料会收到 Apple 律师或招聘经理的消息，但至今对方似乎容忍这类开源项目。另一条回复半开玩笑地提醒，这一切都挺好玩，直到你被人搞消失为止。
这些回复都不是法律意见，我们也没有找到 Apple 明确禁止此类做法的公开条文。但它们指向同一个事实：这条路线能否长期成立，取决于 Apple 的态度和使用者自己的风险判断，而不仅仅取决于代码能不能跑通。仓库自己也没有就授权给出结论，这一点应当在采用前看清。
什么时候值得试
适合尝试的情况有三种。第一，手边已经是 Linux 工作站，想做一个 SwiftUI 小工具并装到自己的 iPhone 上。第二，已经在 Linux 上写 Flutter，只需要一个能签名、能通过本地校验的 release 构建。第三，想理解 iOS 工具链内部的人，把它当作研究对象读一遍，收获也很大。
不适合的情况同样明确。需要模拟器和 UI 自动化测试的团队，应当继续使用 Xcode。依赖小组件、扩展或 macOS 应用的项目，要选完整模式，并且逐项验证。计划正式上架、又对授权风险没有底线的商业团队，应当先咨询律师，不要把这条路线当作交付依据。
还有几个实际约束。iOS 版本与 Xcode 版本必须匹配，README 给出的组合是 Xcode 27 对应 swift-bin 6.4。TestFlight 和 App Store 发布需要付费开发者账号，而设备安装不需要。无线部署在 iOS 26 上只能靠那台曾开启过“通过网络连接”的 Mac，Linux 本身拿不到隧道。
接下来要看什么
有三件事值得跟踪。第一是上游。xtool 的最近推送在 10 月 6 日，而 omarchy-apple-dev 的安装脚本依赖它打过补丁的版本，上游的变动会直接影响这个项目能否重装。第二是独立复现。目前仓库的验证主要来自作者本人和一位社区成员，更多机器上的结果会说明这条路线是否稳定。第三是审核。ship.sh 能生成通过离线校验的包，并在 App Store Connect 中显示为 VALID，但它从不替你提交审核，而 README 也承认 no-xcode 模式下的 App Store 审核尚未尝试。
读这条视频时还要注意时间。视频发布于 2026 年 10 月 9 日，比作者的 X 帖子晚三天。视频里的画面和说法，建议对照仓库的 README 和 FINDINGS.md 逐项核对，再决定要不要照着做。
如果你只想知道这件事是不是真的，答案是：构建、装机、断点调试和上传都已有可复现的记录，而且仓库是公开的，可以自己跑一遍。如果你想问的是这条路线能不能无风险地替代 Mac，答案仍然是否定的。