苹果软件不装苹果系统也能跑？200个已跑通
苹果的软件只能在苹果电脑上跑——这条默认认知，正在被撬开一道缝。2026 年 8 月初，全球最大的技术论坛 Hacker News 上，一个叫 Kakehashi（日语「架桥」）的开源项目冲上热榜，收获 156 分、34 条讨论。它做的事一句话就能说清：在一台装 Linux 的 ARM 电脑上，不装苹果系统、不用虚拟机，直接运行苹果软件本身。目前已经跑通了 200 多个苹果自带的命令行工具，连压缩软件 7-Zip 都能正常工作。苹果那堵「软件只配苹果机」的墙，第一次被正经技术凿出了口子。
图：Kakehashi 发布当天在 Hacker News 的讨论帖，作者在评论区逐条回复进度。来源：news.ycombinator.com
为什么这事听着像天方夜谭
普通人眼里，苹果软件和苹果电脑是一体的：Mac 上用的软件，拿到别的电脑上就是打不开。这不是巧合，是苹果精心设计的结果。
苹果的商业模式里，硬件和软件是绑着卖的。macOS 系统的使用协议写得明明白白：只允许装在苹果自家硬件上。想装到别的机器？协议不允许。再加上软件商店的抽成、云服务的订阅，整个生态环环相扣——你买的每一台 Mac，都是进入这个花园的门票。所以几十年来，想在非苹果设备上用苹果软件，只有两条路：要么装虚拟机，把整套苹果系统模拟出来，慢、吃配置、还占地方；要么走灰色地带折腾「黑苹果」，普通人碰都不想碰。
Kakehashi 走的是第三条路：不搬系统，只搬软件。
它怎么做到的：一个翻译官
把苹果软件搬去 Linux，难点在于两边「语言不通」。苹果软件按苹果的规矩打包、找苹果的系统帮忙干活；Linux 有自己的一套规矩。以前想让它俩对话，只能把整个苹果环境一起搬走。
Kakehashi 的巧思在于一个发现：苹果最新的 M 系列芯片和那些跑 Linux 的 ARM 电脑，底层说的是同一种「方言」。芯片听得懂同一套指令，软件的身体可以直接在 Linux 上跑，不用逐句翻译。真正需要翻译的，只有软件「找系统办事」的那些环节——读写文件、联网、申请内存。Kakehashi 干的活，就是在这些环节配一个翻译官：苹果软件喊「帮我打开这个文件」，翻译官转头用 Linux 的方式把文件打开，再把结果递回去。
图：苹果 M 系列芯片与主流 Linux ARM 设备同属 ARM 架构，指令集一致，让「软件搬家」成本大降。来源：Wikimedia Commons
翻译官模式有个名字，叫「兼容层」。它最出名的前辈，是让 Linux 跑 Windows 软件的 Wine。
30 年前就有人干过这事
1993 年，一个叫 Wine 的开源项目诞生，目标同样疯狂：让 Linux 电脑跑 Windows 软件。当时没人看好——Windows 软件成千上万，每个都要适配，这活干到猴年马月？结果 Wine 真的一点点啃了下来，从能用、到好用，用了三十年。
如今 Wine 已经悄悄长成了庞然大物：Steam 掌机运行的就是它的强化版，几十万人靠它在一台掌上设备里玩 Windows 游戏。当年那个「不可能」的项目，成了 Valve 硬件生意的地基。
Kakehashi 不是第一个想给苹果软件架桥的人。更早有个叫 Darling 的项目做过类似尝试，但进展缓慢。Kakehashi 的作者在讨论区特意声明：这不是 Darling 的分支，是用 Rust 语言从零写的独立实现，连系统调用都不走内核，权限要求极低。他还承认开发过程用了 AI 辅助写代码——评论区为此吵了一架，有人质疑这算不算「干净」的实现，作者说代码全部开源，欢迎任何人去审计。
5.2 倍慢，是死刑吗
目前最亮眼的成绩单：7-Zip 压缩软件，在 8 千个文件、240MB 数据的压力测试里，跑通且结果正确，但速度是 Linux 原生版的 5.2 倍慢——原生 22.5 秒，它要 118 秒。200 多个 curl 网络命令通过自动化测试；苹果 Xcode 自带的 Git 版本管理工具，基础功能也能用。
5.2 倍听起来吓人，但笔者看过数据后判断：这是兼容层的正常出场费。慢的部分主要出在「过翻译官」这个动作上——软件每找一次系统办事，都要在两边交接一次，文件越多、交接越频繁，差距越大。事实上换成大文件、少批次的压缩任务，差距立刻缩到只有 1.1 到 1.2 倍。Wine 早年比这惨得多。作者也承认，优化路线图已经画好，下一步是先啃下苹果 Xcode 完整工具链（包括编译 iOS 应用）和 macOS 版 Homebrew——那才是真正让苹果肉疼的战场。
评论区也有人泼冷水：苹果几乎每年大版本都在改系统底层接口，兼容层只能跟在后面追，追到哪年是个头？这话不无道理。追一个故意把门焊死的对手，本来就是在打一场不对称的仗。
这道缝，对普通人意味着什么
往大了说，这是「开放」对「封闭」的一次正面进攻。开源社区的信条是软件应该自由流动，苹果的信条是围墙花园里的体验最好——两边吵了几十年，谁也说服不了谁。Kakehashi 的意义在于：它证明了墙不是不能凿，只是需要合适的工具和足够长的耐心。
如果有一天，Mac 上那些独占软件——剪辑、作曲、设计工具——能在便宜的 ARM 电脑上跑起来，苹果的护城河还剩什么？历史给过一个参考：Wine 撬开 Windows 生态的结果，是 Windows 没死，反而「Windows 软件哪儿都能跑」成了常态，用的人更多了。墙被凿开，花园不一定塌，但园丁必须开始认真对待墙外的世界。
这场架桥运动最后能走多远，笔者不敢打包票——5.2 倍的速度差、每年更新的系统接口、授权协议的地雷，每一样都够喝一壶。但有一点值得记住：1993 年 Wine 刚出生时，也没人觉得它能把 Windows 软件搬上掌机。所有的墙，都是从一道缝开始的。
参考链接：
- Kakehashi GitHub 仓库（wie-project）：项目主页、README、架构文档与路线图
- HN 讨论帖（item?id=49145937）：作者亲述 7-Zip、curl、Xcode Git 进度及与 Darling 的关系
- Wine 官方历史文档：WineHQ「Wine Is Not an Emulator」项目介绍
- Wine 维基百科词条：1993 年诞生至今的发展史与 Steam Deck 应用
