Codex 新增 iOS 构建插件：将模拟器画面串流进浏览器，支持热重载

做过 iOS 开发的人大多体会过这种痛苦：为了看一眼 SwiftUI 组件的效果，Xcode 的 Canvas 经常转圈转到怀疑人生，动不动就崩溃断连。

Codex 似乎打算绕开这个泥潭。它最近加入了一个名为 Build iOS Apps 的插件，核心是引入了模拟器浏览器映射工具。说白了，它直接把本地运行的 iOS 模拟器画面，实时串流进了 Codex 自带的应用内浏览器。

怎么把模拟器搬进浏览器

这套方案的底层并没有去魔改苹果的底层框架，而是用了一套清晰利落的工程化流转。

当开发者或者 Codex 想要查看界面时，流程会先通过系统的设备命令获取可用模拟器的标识符，随后在后台终端里运行 serve-sim 服务。

这个服务会把选定模拟器的画面流媒体化，并在本地输出一个预览网址。Codex 的内置浏览器只要打开这个地址，就能直接看到实时运行的 iOS 画面，甚至在网页里完成基本的界面交互。

为了保证运行可靠，它还配了严格的清理机制。终端退出时会自动杀掉 serve-sim 辅助进程，防止悬挂进程占用端口，在建立连接前还会要求验证是否有真实画面帧渲染出来，避免把空白网页当成成功。

丢弃式工程与动态库热重载

很多人更关心的可能是另一个问题：SwiftUI 预览如果脱离了 Xcode，还能不能像本地一样实时修改、即时生效。

这个插件交出的答卷挺巧妙。针对可以导入的 Swift Package 组件，它提供了一个专门的启动脚本。它会指向你的代码包清单和目标组件，然后在你的源码目录之外，临时生成一个随用随抛的寄宿工程。

这个寄宿工程会被自动编译并安装到模拟器中运行，同时默认开启文件监听模式。一旦你修改了 Swift 代码，工具不会去重新打包或重启整个应用，而是直接重新生成动态库并热替换进正在运行的进程，几秒内就能看到新界面。

它完整兼容了常见的 PreviewProvider 和较新的 #Preview 语法，支持通过正则表达式过滤要显示的预览项，还能用页面控制器切换不同的预览变体。

更让人放心的是它的操作边界：官方规范明确要求，绝对不要为了跑通预览去擅自修改用户的工程文件、工作空间或构建配置。所有临时项目都在外部生成，代码仓库始终保持干净。

为什么重要

我们认为，这一步对正在尝试用 AI 写完整项目的开发者来说是个非常及时的补丁。

过去让 AI 写 iOS 原生代码，最大的堵点就是视觉反馈。写 Web 应用时，AI 能够轻易调起本地网页并截图做验证；但面对苹果的封闭生态，AI 往往只能盲写代码，写完后还要人类去 Xcode 里点开看排版。现在，模拟器画面直接进到 Codex 浏览器，意味着 AI 可以自己截图验证布局、排查像素偏差，真正补全了视觉调试的闭环。

它的设计思路也非常聪明。它没有硬着头皮去入侵庞大脆弱的 Xcode 项目文件，而是把范围约束在独立的 Swift Package 内，利用外置寄宿工程加动态库注入来实现热重载。这种做法规避了损坏用户工程配置的风险，把脏活都留给了临时环境。

当然，局限同样明显。它目前主要面向模块化的 Swift Package，对于那些强耦合在老旧大型工程里的纯业务界面，热重载并不能直接拿来即用；而且它依然重度依赖本地 Mac 环境和已安装的 Xcode 模拟器，算不上纯云端的免配置方案。

但整体来看，把模拟器推流和无侵入热重载结合起来，给原本封闭沉重的移动端 AI 编程撕开了一个口子。如果你的项目已经在走模块化路线，这套工具非常值得第一时间试一试。