Theo 谈 iOS：开发摩擦、App Store 规则与移动软件的未来

我更喜欢 iOS，也很喜欢自己的 iPhone，但我认为 Apple 对平台的控制越来越阻碍软件发展。开发和发布 T3 Chat、T3 Code 应用时遇到的限制，让我尤其沮丧。我的担忧不仅关乎 iPhone，还涉及整个移动行业的发展。

我从重要性、成本和能力三个维度看软件：它们彼此不同，不一定相互绑定。初代 iPhone 让移动软件的能力和重要性大幅提升，尽管与此前更简单的移动应用相比，开发成本也可能提高。

Theo 播放了 Steve Jobs 当年的演讲：Jobs 介绍如何利用 Safari 和网页标准开发、分发 iPhone 应用，无需额外 SDK。他把网页分发和更新视为优势；Theo 认为这一早期愿景比今天的移动开发体验开放得多。

我承认早期移动网页有其局限，但轻松实验的承诺很重要。在我看来，随着 Apple 市场地位增长，它的激励也变了。我认为它控制分发与支付，让它更缺少动力改善开发者体验。

我用常见的 30% 佣金作为 Apple 激励机制的例子，并认为 iPhone 用户在移动消费中占比很高。实际佣金和支付规则会因项目、交易及地区而异，不能把这个比例理解为普遍适用。

这次视频的直接导火索是我的 iPad。团队应用已经能在我注册过的手机上运行，但我把 iPad 加入开发流程后，设备连续 36 小时处于待处理状态。在流程卡住期间，我无法把自己参与开发的应用安装到自己拥有的设备上。

即便设备获批，我又遇到一条晦涩提示，最后发现必须在账号控制台接受新的开发者协议。多次重定向和各种横幅让问题很难定位。我抱怨的是：想在自己的硬件上测试一个小改动，却要跨过这么多流程。

签名、设备配置和分发各自都有要求。对只是想修改并测试应用的开源贡献者来说，需要 Mac、账号配置和项目签名设置尤其麻烦。Expo 等工具能隐藏部分复杂性，但无法消除所有平台限制。

我还抱怨了七天后重新安装和反复签名的问题。Apple 文档说明，七天期限适用于免费 Personal Team 的配置描述文件；这并非每种付费开发者配置的通用要求。可用的测试和分发方式也取决于账号和地区。 [Apple 开发者文档](https://developer.apple.com/help/account/basics/about-your-developer-account/)。

这些步骤让我觉得平台对实验并不友好。如果应用开源，我希望能修改、测试并贡献代码，而不是先穿过与账号有关的一整套复杂流程。我认为这种摩擦会劝退想了解软件如何运作的人，也包括已经喜欢 Apple 设备的用户。

沙盒是另一部分问题。我希望应用更容易协作，用户也能更方便地定制行为，例如像浏览器扩展那样修改体验。iOS 确实提供了指定的共享和应用间交互机制，但我认为它们的范围和使用体验对我想构建的东西限制过多。

我还批评了即时编译和动态执行方面的限制，这会影响模拟器及其他工具的可能性。具体技术权限存在例外，并取决于应用和地区；我的重点是，开发者不能假定移动设备拥有桌面上的同等自由。

浏览器引擎体现了这种区别。我反对 Apple 长期以来的 WebKit 规则，因为我希望浏览器开发者能试验自己的引擎。Apple 目前为欧盟和日本说明了符合条件时使用替代引擎的权限，因此不能说全球一律禁止。 [Apple 开发者文档](https://developer.apple.com/support/alternative-browser-engines/)。

我希望软件能够以原作者未曾预料的方式扩展和组合。我认为 Apple 的安全与审核边界限制了这种实验，即便平台确实存在一些获准的扩展和共享机制。关键问题是，用户应当能在自己的设备上拥有多大控制权。

谈到分发时，我认为应用审核和商店规则让 Apple 对用户能够获得什么拥有过多控制权。实际选择会因地区而异，也会随时间改变，一些市场已经出现替代分发方式。我更广泛的批评是：即便已经有愿意使用产品的用户，开发者仍面临把关。

我举了游戏串流和登录政策的例子，认为规则可能挡住有用的产品。但这些例子需要限定：Apple 公布的指南涉及串流游戏，并对部分企业登录提供例外。开发者应针对具体应用核对当前规则，而不能把我的例子当成普遍禁令。 [Apple 开发者文档](https://developer.apple.com/app-store/review/guidelines/)。

支付限制和佣金对创作者与平台都很重要，因为各方都有成本。我以 Twitch 订阅、支持创作者，以及数字购买和实体服务的差异为例，说明政策如何影响商业模式。适用费率和外部支付选项取决于交易及司法辖区。

我记得自己在 Twitch 工作时，团队曾用单独的应用内货币来应对应用内订阅的成本和限制。我觉得为了商店的支付规则而重做简单的订阅流程很荒谬。具体安排和规则可能已经与当时不同。

应用审核也是不确定性的来源。我曾遇到审核人员输错我提供的测试账号，从而延误更新。我的担忧不是每次审核都会出错，而是开发者可能被一个自己无法直接调试或控制的流程卡住。

我也对误导性的订阅报价感到愤怒，尤其是儿童在免费试用后遇到高额周期性收费时。我认为 Apple 应该采取更多措施阻止诱导性设计。至于公司动机及这类应用带来的收入规模，我在视频中提出的是个人指控，并没有在这里给出可验证的测量。

接下来我要抱怨 Xcode。我把它的一些设计和年代问题归因于 Apple 的 NeXT 历史，但对我而言更实际的是今天遇到的崩溃、重新索引、需要清理的缓存以及重复构建。这些是我的经历和抱怨，并非完整历史，也不是对所有 Xcode 项目的评价。

我描述了打开 Xcode 后，未修改文件仍被重新索引、内存占用很高的情况。模拟器的下载和维护也带来摩擦。对于主要在其他操作系统上工作的开发者，依赖 Apple 工具链生成 iOS 二进制文件也意味着需要持续使用 Mac。

Expo 可以改善迭代流程：手机上已有原生外壳后，可以从开发服务器加载 JavaScript。我仍担心分发或测试动态更新的应用时遇到审核和签名问题。我对 T3 Code 审核结果的担忧只是预测，并不代表它已经被拒。

我让 AI 收集更多抱怨，再与自己的经历对照。清单包括增量构建意外重复工作、错误信息难以理解、清理派生数据以及重启 IDE。AI 生成的清单只是调查起点，不能独立证明每个问题都适用于所有开发者。

SwiftUI 和类型检查是另一个例子：简洁的表达式可能难以编译或诊断，错误也未必清楚指出根因。开发者为了绕过工具限制，不得不改写原本合理的代码时，我觉得尤其沮丧。

混合语言、依赖繁多的项目会增加更多需要协调的部分。我提到了 CocoaPods 等第三方工具，以及组织大型构建的困难。Apple 平台也有其他依赖管理机制，因此我的批评针对工作流及其历史，并不是说完全没有包管理系统。

我描述了索引、SwiftUI 预览和调试器的问题，并询问观众是否使用预览。聊天回复只是个人经验，不能代表整体调查，但它们与我的挫败感相呼应。对我来说，问题在于必需工具链中许多小故障不断累积。

模拟器带来另一种测试落差：它可能占用大量磁盘、丢失实用功能，而且行为可能与真实设备不同。登录、推送通知、后台行为和权限配置等方面的差异，都曾让我难以判断。

我也不喜欢 project.pbxproj 的改动难以阅读，而且可能产生合并冲突。屏幕上的生成研究提到，较新的同步文件夹和外部项目生成工具可以缓解问题。我的抱怨是团队仍要花精力管理项目结构，而不仅仅是代码本身。

一位观众说 iOS 开发者最终会习惯这些怪癖。我认为这不足以解决问题：即便团队学会绕过它们，反复构建失败、调试摩擦和缓慢反馈仍然消耗时间。熟悉问题不应等同于接受糟糕的开发体验。

我更广泛的担忧是：AI 可以改变我们使用电脑的方式，而不只是给应用加一个聊天机器人。在桌面上，我使用语音输入、窗口管理工具，以及能够跨应用交互的 agent。这些工具改变的是应用之间的工作流，而不只是单个应用内的内容。

例如，Wispr Flow 可以把语音转成文字，输入我正在使用的桌面文本框；Codex 可以操作浏览器和其他应用。桌面自动化同样有问题，但至少我可以尝试。我希望移动端也能有类似范围的选择。

在 iOS 上，我描述了语音输入应用通过键盘绕行、访问麦克风需要额外步骤的做法。我认为这是平台边界如何塑造产品本身的例子。我预测某些体验永远无法实现，这是对 Apple 方向的个人判断，并非已被证明的未来。

Theo 播放设计师 Scott Jenson 的演讲片段，讨论在 Google 推出非常规想法的困难。Jenson 回忆说，有人告诉他，如果 Apple 先做出某个功能，这个功能就更容易推出。Theo 借这个轶事说明，他认为 Android 过于频繁地追随 Apple，而没有探索替代方案。

我认为 Android 也存在许多类似问题，不过它确实提供了不同的能力和选择。我认为 Google 照搬 Apple 激励机制的说法只是个人解读，并非 Google 内部动机的证据。我希望 Android 支持更多定制，让用户有更大的实验空间。

我甚至开始尝试修改 Android，以实现自己想要的定制，尽管不知道这个项目是否会有结果。重点不是某个现有平台已经解决了一切，而是移动设备应当比现在更鼓励实验。

想象一个孩子在 iPad 上制作应用并分享给朋友，或者一个人根据自己的无障碍需求调整界面。我希望多种助手和输入工具能够竞争系统级体验，也希望构建、分享软件变得容易上手。

当我向模型描述 Android 实验中的设备本地构建时，它反复假定需要远程服务器或虚拟环境。我真正想要的其实是桌面上熟悉的体验：安装软件、本地构建，并在适当边界内改变设备行为。

我仍认为 iPhone 是出色的硬件。我对 Apple 的请求是，让这些硬件支持更多实验：安装更多软件、直接在设备上构建，并选择自己的交互方式。这些是对产品方向的期待，并不意味着安全方面的权衡会消失。

我担心，在封闭设备环境中长大的孩子可能主要把软件视为消费品，而不是可以改变的东西。这是我的担忧，并非对整代人的测量结论。我希望下一代有机会创建并分享自己的体验。

我不知道 Apple 是否会改变，自己也沮丧到考虑把更多工作迁移到 Linux。但开发 iPhone 应用仍然需要使用 Apple 的工具。我希望人们能给孩子探索电脑的机会，让他们理解软件是可以改变的。

我最后的请求很简单：把这些强大的设备同时当作创作和消费的平台。我希望人们能够安装、实验和学习，而不是以为设备上只能运行平台所有者选定的软件。