当 AI 重塑开发体验，iOS 生态为何显得格格不入？

作为一名长期从事 iOS 开发的程序员，最让我感到郁闷的莫过于是看着业界发展日新月异，而我们却仿佛是在原地踏步。我试过用 lovable.dev、bolt.new，和 a0.dev 这些平台构建网站和应用，使用体验甚是神奇。反观苹果生态，我们连 Xcode 里能正常运行的 GitHub Copilot 都少有，我认识的所有开发者都把苹果的“智能功能”关闭了。

据 Expo 项目的核心开发者之一 Evan Bacon 透露的数据，目前 App Store 购物类别中排名前百的应用中，有 40 个都是采用非原生开发的。随着 AI 应用构建工具的爆发式增长，未来非原生应用的比例只会持续攀升。

iOS 开发者的“Cursor”级体验究竟在哪？

在我看来，这一切都要追溯到苹果根深蒂固的闭源传统；是一个关于企业的长期决策是如何积重难返的警示案例。那让我们深入讨论，要想在 iOS 生态中打造类似 a0.dev 的开发体验，究竟需要突破哪些技术壁垒？

代码编辑器

在用户提出修改需求时，要能对代码进行更新并验证其可编译性。听起来不难，对吗？

首先你得有一台 Mac 设备。但即便满足了这个前提条件，iOS 代码编译的复杂度依旧是臭名昭著；苹果官方从未支持过 Xcode 之外的编译环境。虽然也有xcodebuild这类的命令行工具，但其对增量编译等基础功能的支持堪称灾难。开发者还会遭遇无数琐碎且耗时的障碍：系统会反复向苹果服务器发送验证请求、检查配置文件更新状态、确认应用是否具备正确授权（使用操作系统功能的权限），以及强行增加但没人乐意用的应用锁定功能。

在我的一个本地的测试项目中，虽然我能让这条命令运行，但还是会显示下面这些编译错误：

➜  Snake git:(main) ✗ xcodebuild -scheme Snake -configuration Debug -json -destination 'platform=iOS Simulator,id=C286A4E0-BC6C-49EA-A0C7-BBAB40CB0E0B' -quiet build/Users/telkins/dev/ios/Snake/SnakeTabView.swift:8:4: error: unknown attribute 'States'  @States private var path: [Screen] = []   ^/Users/telkins/dev/ios/Snake/SnakeTabView.swift:8:4: error: unknown attribute 'States'  @States private var path: [Screen] = []   ^/Users/telkins/dev/ios/Snake/SnakeTabView.swift:15:29: error: cannot find '$path' in scope      NavigationStack(path: $path) {                            ^~~~~** BUILD FAILED **

这种方案能行得通，大语言模型应该也能通过解析编译错误来自动修复问题，总算是有所突破了！

不过要是 AI 的解决方案需要创建新文件，这点应该难不倒 AI 吧？

现实很骨感。由于 Xcode 特有的 .xcodeproj 文件格式需要开发者手动维护文件引用关系，我们得想办法在编辑文件的同时，祈祷文件的引用不会出错。虽然开发者社区普遍使用 Ruby 工具库 xcodeproj 来操作项目文件，但苹果从未提供过官方支持工具。

到 2025 年，业内普遍推荐将代码模块化至 Swift Packages，这种方式确实有效，但每个 Package 仍需手动集成到主项目文件中。我们正处在一个尴尬的过渡期：既不能完全摆脱传统项目文件的束缚，又未能实现真正意义上的全 Swift Packages 应用构建。

幸好我们还不算彻底悲剧，目前有些值得关注的开发项目正在推进：

• Swift Build 近期宣布开源，预计将在构建系统领域带来显著改善

• Xcode 16 中引入的可编译文件夹功能，为非包化代码管理提供了突破性解决方案，开发者只需关联整个文件夹而非逐个文件进行关联

• 社区开发的 Sweetpad VS Code 扩展，通过智能化工程文件管理，大幅简化了传统开发流程

然而这些补救措施终究还是在亡羊补牢。iOS 开发生态的整体闭源属性依然根深蒂固，短期内难以被撼动。

实时预览

假设我们已经通过 AI 搞定了代码修改并且能通过编译，现在就该实时预览修改的效果了。以 Lovable.dev 等平台为例，它们的实现方式是在虚拟机运行本地开发服务器，用户只需在浏览器访问特定页面即可。对于采用 React Native 的 a0.dev 来说，原理同样简单：浏览器中呈现的不过是react-native-web的运行实例，比如这样：

<foreignObject  x="21.25"  y="19.25"  width="389.5"  height="843.5"  clip-path="url(#roundedCorners)"  class="overflow-hidden">  <iframe    src="https://a0.dev/v2/52/index.html?initialUrl=exp%3A%2F%2Fu.expo.dev%2F933fd9c0-1666-11e7-afca-d980795c5824%3Fruntime-version%3Dexposdk%253A52.0.0%26channel-name%3Dproduction%26snack%3Dcc18e8a0-8c69-4bdd-8df0-7d15181cac48%26snack-channel%3D5PYBIUJa1n&amp;origin=https%3A%2F%2Fa0.dev&amp;verbose=false"    class="w-full h-full border-0"    allowfullscreen=""    allow="cross-origin-isolated; accelerometer; ambient-light-sensor; autoplay; battery; camera; fullscreen; gamepad; geolocation; gyroscope; idle-detection; magnetometer; microphone; midi; payment; picture-in-picture; screen-wake-lock; usb"  ></iframe></foreignObject>

通过浏览器开发者工具可以看到，这个 <iframe> 加载的正是 react-native-web 生成的 HTML 页面。由于 React Native 本质上是 React 框架的延伸，开发者只需切换底层平台目标，就能在浏览器中获得近乎完美的预览效果。

但 iOS 开发完全是另一套游戏规则：你必须要让应用运行在 iOS 运行时环境中。这意味着开发者需要管理模拟器启动（内存占用极高）、处理设备更新和模拟器运行时版本兼容问题、想办法通过视频流传输机制将模拟器画面投射到浏览器的同时，建立双向交互通道同步用户输入事件。一点都不简单。

看起来 iOS 运行时才是技术瓶颈。难道不能通过 WASM 等技术让 SwiftUI 支持网页目标吗？很遗憾，SwiftUI 是闭源的！我们完全受制于苹果的技术路线图。虽然开源社区有 OpenSwiftUI 这样的优秀项目，但其实现原理却是通过对框架逆向工程。为什么苹果会想把 SwiftUI 做成闭源产品超出了我的理解能力。对比之下，安卓的 Jetpack Compose 不仅完全开源，更是通过 Compose Multiplatform 实现了跨平台开发。即便是 Skip 这类的创新项目，目前也仅支持安卓而非网页平台。

规模化构建

假设我们也已经攻克了模拟器的难题，现在要将解决方案扩展到供数千开发者使用。服务器虚拟化本来就是成熟技术，不是吗？

但在 iOS 生态中这仍是天方夜谭。要运行模拟器，我们就得有 macOS 设备，但这也是要命的地方：规模化部署 macOS 服务器非常困难。

首先，macOS 虚拟机按规定只能在正版 Apple 硬件上运行。其次，根据苹果的授权条款，物理 Mac 实例最低的租用周期长达 24 小时（参见 AWS 物理 Mac 实例的复杂配置流程）。

其次，即便成功启动 Mac 实例，苹果的虚拟化框架也会将并发虚拟机的数量严格限制在两台以内。选择在虚拟机运行构建服务本是出于安全考量，由于 iOS 模拟器可直接访问宿主文件系统，恶意应用可能窃取宿主系统或其他用户的数据。这种安全与效率的悖论，直接导致规模化部署需要堆砌数以千计的物理 Mac 设备。

最后，macOS 本质上就不是为无服务器环境设计的操作系统。Linux 系统上那些"开箱即用"的服务器体验，macOS 会给你带来各种意想不到的"特色功能"。

安卓生态怎么说？

鉴于谷歌的安卓生态是开源的，那它是否就比苹果生态更具优势呢？

理论上确实如此，多数项目通过简单的 ./gradlew assembleDebug 命令就能成功编译，虽然编译时间往往过长而难以形成高效的工作流。模拟器问题与 iOS 要面对的基本相似，虽然安卓模拟器的规模化运行可行，但同样存在其特有的技术难题。

要想实现真正实用的方案，安卓应用可能需要通过 Compose Multiplatform 转向网页平台。目前已有项目实现在浏览器渲染 Compose 视图，技术可行性已经得到了验证，关键在于要如何将开发体验至 Expo 的水准。

总结

感谢你读到这里，那我们从中能学到什么呢？在我看来，苹果对软件生态的封闭策略终于开始反噬自身，使其在 AI 竞赛中渐显颓势。当下蓬勃发展的 UI 框架无不建立在开源技术之上，越来越多的开发团队选择了 React Native 而非 Swift 尤其是在 AI 服务让应用搭建速度发生质变的今天。我期待能出现构建真正原生 iOS 应用的 Lovable 或 A0 级别工具，但苹果生态的特殊性让这种愿景难以实现。

多年来开发者持续诟病苹果平台的开发体验，但根源性问题始终未获解决，如今这个技术深坑已越发地难以填平。