摘要：作为一名长期从事 iOS 开发的程序员，最让我感到郁闷的莫过于是看着业界发展日新月异，而我们却仿佛是在原地踏步。我试过用 lovable.dev、bolt.new，和 a0.dev 这些平台构建网站和应用，使用体验甚是神奇。反观苹果生态，我们连 Xcode 里
作者 | Trevor Elkins
译者 | 马可薇
策划 | Tina
作为一名长期从事 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: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 x="21.25" y="19.25" width="389.5" height="843.5" clip-path="url(#roundedCorners)" class="overflow-hidden" src="https://a0.dev/v2/52/index.html?initialUrl=exp://u.expo.dev/933fd9c0-1666-11e7-afca-d980795c5824?runtime-version=exposdk%3A52.0.0&channel-name=production&snack=cc18e8a0-8c69-4bdd-8df0-7d15181cac48&snack-channel=5PYBIUJa1n&origin=https://a0.dev&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" >通过浏览器开发者工具可以看到，这个加载的正是生成的 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 级别工具，但苹果生态的特殊性让这种愿景难以实现。
多年来开发者持续诟病苹果平台的开发体验，但根源性问题始终未获解决，如今这个技术深坑已越发地难以填平。
声明：本文由 InfoQ 翻译，未经许可禁止转载。
今日好文推荐
代码界的“瘟疫”？卡帕西“Vibe Coding”兴起，YC披露：1/4新创公司，95%代码全由AI生成
OpenAI 又贵又“黑”，微软对供应商亮起“红灯”：曝出自研大模型，DeepSeek 或成救星？
被骂惨的“现象级”Manus，今天我们来扒一扒它的真实水平！
DeepSeek 开源周过后，国产芯片厂在焦虑中狂欢
来源：InfoQ