被苹果下架两次后，这家AI编程工具如何"曲线救国"

一家上线仅数月的AI编程应用，被苹果App Store连续下架两次，创始人打了几十通电话、重写四次代码仍无法解决。这不是技术故障，而是一场关于"谁有权创造应用"的规则博弈。

两次下架：一场漫长的"合规"拉锯战

3月26日，Anything的联合创始人Dhruv Amin收到苹果通知：应用被移除。这距离他们首次遇到问题已过去三个月。

「从12月之后，我们和同类应用都开始遇到更新被阻的情况，」Amin向TechCrunch回忆。Anything最初的功能设计很单纯——让用户能在自己手机上预览正在开发的iOS应用。这个"预览工具"的定位，在2024年底之前运行顺畅。

转折发生在苹果援引开发者协议第2.5.2条款。该条款禁止应用下载、安装或执行代码。苹果在邮件中明确指出：「该应用自我定位为iPhone移动应用构建工具，宣传功能包括一键提交App Store、代码导出、完整源代码编辑。」

4月3日，Anything曾被短暂恢复。但苹果迅速补充条件：不能宣传自己是"应用制造工具"。这相当于让一家餐厅不许说自己卖饭。

Amin透露，团队尝试过邮件沟通、电话会议、正式申诉，并对技术架构进行了四次重写以配合苹果要求。当终于争取到一次通话机会时，苹果给出的核心顾虑是：用户可能利用该工具下载恶意代码，或构建有害应用后通过侧载安装，再声称"这通过了苹果审核"。

苹果的深层焦虑：审核体系的"连带责任"风险

苹果的解释暴露了一个结构性困境。传统应用审核模式下，苹果对上架内容负最终责任。而vibe-coding（氛围编程）工具的本质，是让非技术人员通过自然语言生成可运行的原生代码——这意味着审核对象从"应用"变成了"应用生成器"。

更棘手的是分发链条的变化。Anything支持代码导出和侧载预览，用户完全可以在苹果生态之外完成"开发→安装→使用"的闭环。苹果担心的不是技术本身，而是声誉风险：如果一个通过Anything生成的应用造成用户损失，舆论焦点会指向"苹果审核失职"。

这种担忧并非空穴来风。同类应用Replit、Vibecode同期遭遇更新暂停，显示苹果正在系统性地收紧对AI编程工具的政策。与Epic Games围绕《堡垒之夜》的公开诉讼不同，这次针对的是更早期、更脆弱的初创产品——它们没有足够资源打持久战。

Anything的三条逃生路线：从iMessage到桌面端

下架事件倒逼出产品策略的急剧调整。Anything目前布局了三条替代路径：

第一，iMessage集成。本月早些时候，该公司上线了新功能，允许用户直接在iMessage对话界面中构建应用。这绕开了App Store的独立应用审核，转而依附于苹果已批准的通讯平台。

第二，桌面 companion 应用。Anything计划推出电脑端配套工具，让用户在Mac或PC上完成vibe-coding，再通过其他方式将应用传输至移动设备。这本质上是将"应用生成"环节移出iOS生态。

第三，转向Android。Amin明确表示可能选择谷歌平台，因其开放程度更高。这对一家以iOS应用构建为核心卖点的产品而言，是战略层面的重大妥协。

三条路线的共同逻辑是：既然无法在iOS内部完成"创造→分发"闭环，就拆解流程、分散风险、寻找监管缝隙。

行业信号：平台权力与AI创造力的碰撞

Anything的遭遇并非孤立事件。它揭示了AI编程工具面临的结构性张力：当技术让"人人可开发"成为现实，平台审核机制却仍在按"专业开发者-集中分发"的旧逻辑运转。

苹果第2.5.2条款的设计初衷是防范恶意代码和越狱工具，其适用对象传统上是脚本解释器、虚拟机或游戏模组平台。将vibe-coding工具纳入此范畴，实质是将"AI生成的原生代码"与"外部下载的可执行文件"等同视之——这种归类方式本身就有争议。

更深层的矛盾在于价值分配。苹果App Store生态每年创造数千亿美元收入，其根基是"平台作为唯一可信中介"的信任结构。AI编程工具动摇的正是这个根基：如果用户能自主生成应用，平台的中介价值和抽成模式将面临重构压力。

Epic Games CEO Tim Sweeney对此类平台管控的持续批评，与初创公司的沉默挣扎形成对照。大公司的诉讼能推动政策讨论，但真正决定创新方向的，往往是Anything这类产品在夹缝中的生存实验。

vibe-coding的"移动化"困境

从技术演进看，vibe-coding的核心场景本应包含移动设备。智能手机是绝大多数人最熟悉的计算终端，也是应用消费的最终场所。在手机上直接"说句话就做个App"，是这一品类最自然的用户体验。

但苹果的封闭架构使这一路径充满障碍。iOS禁止JIT（即时）编译、限制动态代码执行、管控侧载渠道——这些设计在安全和性能层面有其合理性，却与AI编程的"实时生成、即时验证"特性直接冲突。

Anything的iMessage方案是聪明的权宜之计，但它将应用构建限制在对话流中，牺牲了可视化编辑和复杂交互的可能性。桌面端方案则割裂了"所想即所得"的沉浸感，把移动开发重新变回桌面任务。

转向Android能缓解部分问题，但谷歌生态的应用分发碎片化、设备兼容性复杂度，对vibe-coding这种追求"一键生成"体验的产品同样构成挑战。没有完美的避风港。

创业者的适应性进化

Amin的应对策略展现了早期AI产品团队的典型生存智慧：快速转向、多线布局、保持与平台的非对抗性沟通。

四次技术重写表明团队愿意配合规则，但苹果的反馈模糊性——"不能自称应用制造工具"这类定性要求而非技术指标——使得合规成本难以预估。这种不确定性对融资和团队士气的影响，可能超过下架本身。

选择iMessage作为突破口尤其值得玩味。它利用了苹果自有产品的功能延展性，将"应用生成"包装为"消息增强"，在语义层面弱化了工具属性。这种产品定义的柔韧性，可能是AI时代初创公司与平台博弈的关键技能。

桌面 companion 应用的规划则暗示了更长远的平台策略：先在开放环境建立用户基础和技术成熟度，再择机回归移动端。这与早期SaaS产品"网页先行、App跟进"的路径异曲同工。

规则滞后于技术的经典案例

Anything事件是技术监管滞后的最新注脚。开发者协议第2.5.2条款的文本多年未变，其适用边界却随着AI能力跃迁不断扩张。苹果审核团队似乎正在通过个案裁决，逐步建立针对vibe-coding的隐性政策。

这种"案例法"式的监管有其效率优势——无需等待冗长的规则修订流程。但对创业者而言，它意味着不可预测的风险敞口。今天被允许的功能，可能在下次更新时被重新解读为违规。

更广泛的疑问是：当AI使代码生成民主化，应用审核的权责边界是否需要重新划分？如果用户自主生成的应用造成损害，责任主体是平台、工具提供商、还是用户本人？现行法律框架对此缺乏明确答案，平台倾向于收紧控制以自保，创新空间因此被压缩。

为什么这件事值得持续关注

Anything的挣扎预示了AI原生应用的一类共同命运：它们挑战的不仅是技术难题，更是既有的平台权力结构和商业规则。

短期内，这家公司的三条逃生路线——iMessage嵌入、桌面工具、Android迁移——将为同类产品提供可复制的应对模板。其成败将直接影响投资者对"移动优先"AI编程工具的信心。

中期来看，苹果与vibe-coding开发者的互动模式，可能塑造整个类别的监管基准。是设立专门的AI生成应用审核通道，还是持续压制直至工具退化为桌面附属功能，两种路径对行业生态的影响截然不同。

更深层的意义在于，它迫使我们追问：当创造工具本身变得触手可及，谁应该拥有决定"什么可以被创造"的权力？平台的安全责任与用户的发明自由之间，平衡点在哪里？

Anything的故事还没有结局。Amin和他的团队仍在寻找那条能让"人人可开发"愿景与苹果生态共存的路径——如果这样的路径确实存在的话。

当AI让写代码变得像说话一样简单，我们准备好重新设计那些为专业开发者时代制定的规则了吗？