苹果疯狂狙击Vibe Coding App

极客邦科技InfoQ·2026年04月15日 15:52

苹果说你的代码不安全，你就连呼吸都是错的。

1 苹果 App Store 阻止多款 Vibe Coding 应用更新

在苹果创立五十周年之际，这家曾以“让每个人都能使用计算机”为使命的公司，正再次站在技术路线与平台治理的十字路口。

近期，苹果在其 App Store 中对多款“Vibe Coding”应用采取了限制措施，引发了开发者社区与行业观察者的广泛讨论。

据多方信息显示，苹果已阻止至少两款基于 Vibe Coding 理念的应用更新，其中包括知名在线开发平台 Replit，并以安全合规为由将相关产品 Anything 下架了两次。苹果要求这些应用必须对其核心的“Vibe Coding”功能进行重大调整，甚至在某些审核阶段，苹果审核人员曾暗示要彻底移除这些功能。

这一限制直接导致 Replit 等应用无法向 iOS 端推送新版本，用户被迫停留在旧版本。由于技术迭代速度极快，苹果每次阻止更新都在拉大新旧版本的差距，最终造成 iOS 用户的体验与其他平台用户产生显著差异。

Anything 的联合创始人 Dhruv Amin 在接受媒体采访时表示，苹果公司于 3 月 26 日下架了他们的应用程序。此后，尽管曾短暂恢复上架，但该公司一直未能获得重新批准。

Replit 的首席执行官 Amjad Masad 公开直言不讳地表示，他们一直遵守苹果公司的所有规则，但苹果公司的这一行为使 iOS 上的开发者工具处于无法运作的境地。

前天，还在愤怒中缓不过来的 Amjad Masad 再次发 x 痛斥苹果站在了历史错误的一边。

那么，苹果为什么要这么做？

苹果之所以对“Vibe Coding”应用采取限制措施，核心原因在于其认为这类应用 绕过了 App Store 长期坚守的审核机制，存在潜在的安全风险。

苹果指出，此类应用的关键问题在于 允许用户在应用内运行未经审核的软件逻辑。尽管生成的代码通常运行于云端或浏览器环境（而非直接安装在 iOS 设备本地），但其本质是通过动态生成代码并即时执行的方式，绕过了苹果对应用功能的预先审核流程——这是苹果无法接受的。

并且苹果方面表示，这一限制并非临时举措，而是基于 App Store 审核指南中已存在多年的条款（规则 2.5.2）。

“应用程序应在其软件包内保持独立运行，不得读取或写入指定容器区域之外的数据，也不得下载、安装或执行任何引入或更改应用程序（包括其他应用程序）特性或功能的代码。旨在用于教学、开发或允许学生测试可执行代码的教育类应用程序，在特定情况下可以下载代码，但前提是这些代码不得用于其他用途。此类应用程序必须确保用户能够完全查看和编辑其提供的源代码。”

该条款明确规定：应用程序“不应下载、安装或执行引入或更改应用程序功能或特性的代码”。

值得注意的是，此规则制定于 AI 编码成为独立技术类别之前，但苹果认为其适用范围覆盖了所有动态代码执行场景。

具体而言，Vibe Coding 为何触发该规则？

理由很简单，苹果的审核流程会在批准应用发布前对其代码进行评估。如果应用能够执行审核后生成的代码，那么审核流程的大部分价值就荡然无存了。用户运行的应用可能与苹果批准的版本截然不同。

这条规则历来会阻止脚本环境、插件系统以及绕过 App Store 的更新机制。

对苹果而言，App Store 的审核机制不仅是商业分发渠道，更是其安全模型的基石——用于防范恶意软件、隐私滥用以及对摄像头、通讯录、位置等敏感权限的非法访问。这种“封闭且可控”的生态，也正是 iPhone 用户长期信任的重要来源。

对于外界质疑的苹果针对 Vibe Coding 应用的说法，苹果则回应称，其行为并非针对 Vibe Coding 本身，而是基于既有规则的执行，并强调不同产品在实现路径上存在差异。例如，Claude 虽然也支持生成和运行应用，但其功能更多在应用内部完成，而非像 Replit 那样依赖外部浏览器环境。此外，苹果也并未拒绝 AI 编程趋势——其开发工具 Xcode 已在今年引入来自 OpenAI 与 Anthropic 的模型能力。

2 封锁背后的利益博弈：30% 佣金的保卫战

在开发者群体中，一部分人对苹果以“安全合规”为由限制 Vibe Coding 应用更新的做法存疑，认为其理由难以自洽。

他们反驳的核心逻辑是：用户通过 Replit 等工具制作网页应用的行为，并未改变 Replit 应用本身的底层逻辑——这类操作本质是用户在应用内完成的个性化内容生成，既不涉及 Replit 功能的根本性调整，也不会干扰 App Store 中其他应用的正常运行。因此，苹果将“动态生成内容”直接等同于“安全风险”的判定，缺乏实际依据。

外界进一步分析认为，苹果对动态代码执行的严苛审核，本质上是 通过规则限制维持其对应用生态的绝对控制权——即使技术手段（如云端运行）已降低本地风险，苹果仍倾向于通过审核权把控应用功能的边界，确保生态内的所有行为均处于可监管范围内。

除了技术安全的借口，《The Information》的一档视频栏目里，AI 记者 Stephanie Palazzolo 和关注苹果公司的记者 Aaron Tilley 谈及了苹果阻止 Replit 和 Vibecode 等应用更新背后折射出的更深层次的商业利益冲突问题。

Stephanie Palazzolo 指出，苹果此举背后隐藏着三大动机：

首先是审核压力的剧增。随着 AI 编程门槛的降低，每天提交到 App Store 的新应用数量呈爆炸式增长，这让苹果的审核团队不堪重负。通过限制此类编程工具，苹果可以从源头上减缓新应用的涌入速度。

其次，也是最核心的利益点，在于防范“逃离 App Store”。利用 Replit 等工具生成的往往是网页应用（Web Apps），这些应用无需上架 App Store 即可运行。对于苹果而言，这不仅意味着失去了对应用数据的掌控，更意味着无法从中抽取高达 30% 的“苹果税”。

最后，竞争威胁亦不可忽视。这些轻量级、智能化的第三方编程工具，在功能上正逐渐与苹果自家的开发者工具 Xcode 形成竞争。苹果显然不希望看到开发者绕过官方生态，去拥抱更灵活的第三方 AI 工具。

他们还谈到，尽管大多数重度开发者仍倾向于在 MacBook 桌面端进行操作，但移动端的受阻已然对这些 AI 初创公司造成了实质性伤害。以 Replit 为例，由于数月无法更新移动端应用，其在 App Store 热门开发者工具排行榜上的排名已显著下滑，流量与收入均受到不同程度的影响。

苹果记者 Aaron Tilley 评价道，历史经验表明，苹果在感到平台地位受到威胁时绝不会退缩。从与 Epic Games 围绕支付体系的争议，到应对欧洲监管对侧载（sideloading）的要求，再到与 Tencent 在小程序生态上的博弈，苹果始终在捍卫其“围墙花园”模式。

其逻辑并不复杂：通过严格控制分发渠道与交易路径，既保障用户体验与安全，也维持其在生态中的价值捕获能力。

这种商业动机在财务数据中体现得尤为明显。

App Store 所属的服务业务，已成为苹果增长的重要引擎之一，年度收入规模超过千亿美元，且利润率显著高于硬件销售。而一旦应用绕过 App Store、直接通过网页分发，苹果将无法从中抽取 15% 至 30% 的佣金。这也使得“安全”与“商业模式保护”之间的界限，变得更加微妙。

与此同时，Vibe Coding 的崛起速度远超预期。仅在过去一年多时间里，这一原本几乎不存在的市场，已孕育出多家估值数十亿美元的公司。更重要的是，它正在改变软件生产的主体结构——从专业开发者，扩展到设计师、创作者乃至普通用户。数据显示，过去一年 App Store 应用发布量同比增长约 60%，创下近十年来新高，而这还只是整个 Vibe Coding 生态的一部分。大量应用实际上诞生于开放的 Web 环境，并未进入苹果的审核体系。

不少仅有一个人做出来的项目也进一步说明了这种变化。

一些没有编程背景的用户，借助 AI 编程工具首次将创意转化为真实产品，甚至实现商业化。这类用户并不具备使用 Mac 和 Xcode 的传统开发路径条件，而 Vibe Coding 恰恰填补了这一门槛鸿沟。从这个角度看，苹果所提供的“在 Mac 上开发、再提交审核”的路径，虽然技术上可行，但并未真正回应这类新兴用户群体的需求。

虽然苹果最终可能会与这些公司达成某种妥协方案，允许它们继续存在，但这些应用注定只能在苹果划定的“警戒线”内运行。

在执行层面，这一事件同样暴露出不确定性。有消息称，自今年初以来，苹果多次调整对相关应用的审核理由，即便开发者已针对先前问题进行修改，仍会面临新的合规挑战。与此同时，相关应用在 App Store 中的排名与收入也受到影响。开发者则表示，其产品多年来一直符合苹果规则，并已获得上百次审核通过，此次限制令其“感到意外与失望”。

从更宏观的视角来看，这场争议的核心问题，并不在于 Vibe Coding 是否会普及——这一趋势几乎已成定局——而在于其主要发生在哪个生态体系之中。

范德比尔特大学反垄断学教授 Rebecca Haw Allensworth 表示，经济学家们早就观察到，垄断者在其平台上鼓励竞争只是在一定程度上的。

“他们想控制创新的方向，使其远离那些会破坏他们垄断地位的事物，”她说。

如果苹果继续封禁这些工具，开发者们可能就会离开。他们会转而开发面向网络的应用，因为在网络上发布应用无需苹果的许可。最终，iPhone 用户可能会面临一个更糟糕的应用生态系统，因为苹果赶走了那些曾经丰富生态系统的开发者。

苹果并非首次面临这样的困境。在上世纪 90 年代，Microsoft 通过开放生态迅速扩大个人电脑市场，而苹果则因封闭策略一度陷入困境。直到 Steve Jobs 回归后，重新强调用户体验与创造力的释放，才扭转局势。

3 网友：苹果把用户越推越远

在苹果限制多款 Vibe Coding 应用的背景下，开发者社区的讨论迅速升温。

在 Reddit 平台，有用户吐槽这项政策实在是老掉牙了。

苹果的这条规则至少可以追溯到 17 年前，也就是乔布斯担任 CEO 的时候！在 Mac 电脑采用 A 芯片、iPad 采用 M 芯片的时代，这真切地证明了开发者的政策有多么陈旧过时。

还有用户表示，苹果这么做是在维护 App Store 的利益，他们封闭的产品战略与 AI Coding 理念背道而驰。他写道：

这迟早会发生。如果人们可以编写自己的应用程序，只需一个提示就能运行，那么整个应用商店市场将会崩溃。苹果的策略与 AI 编程的理念完全背道而驰。

在 Hacker News 上，大量评论从规则解释、技术实现到平台治理逻辑，对这一事件进行了多角度的拆解。

围绕规则本身，争议首先集中在苹果对“运行外部代码”的限制条款。

一位用户直接引用了相关规定，指出苹果明确要求应用“不得下载、安装或执行会改变应用功能的代码”，仅对教育类应用设有有限例外。这也成为不少人理解此次事件的出发点——即 Vibe Coding 类应用本质上允许用户生成并运行代码，因此天然处在规则的灰色地带。有评论认为，从这个角度看，这类应用被限制“并不令人意外”，因为“允许在应用内运行自定义代码，一直是被禁止的”。

但问题在于，苹果似乎很“双标”。多位用户提到，一些长期存在的应用实际上已经在做类似的事情。例如，有人指出，苹果自家的 Swift Playgrounds 本身就允许用户编写和运行代码，却被归类为“教育应用”，从而适用于例外条款；而像 Pythonista 这样的第三方应用，也多年来允许执行任意 Python 代码，却未受到同等限制。

有评论直言，“‘教育’例外条款更像是一个方便的漏洞”，而真正的问题在于苹果是否在选择性遵守规则。

在所有评论中，另一条重要脉络是对平台开放性的反思。

一部分评论将这一事件放在更宏观的生态竞争中来看。有用户指出，长期以来，Linux 和 Windows 在可定制性上明显优于苹果，而苹果则坚持“由平台定义用户体验”的理念。在生成式 AI 让“软件定制化”成为可能的当下，这种模式可能面临挑战。

有人认为，随着用户越来越希望按需生成和修改应用，传统 App 形态正在显得“僵化”，而 Web 等开放平台的吸引力正在上升。

围绕这一趋势，也有开发者分享了实践案例。有评论提到，他们正在为一家完成 B 轮融资的公司构建“白标”Vibe Coding 能力，使其 SaaS 平台的客户可以直接生成所需功能。据称，这一模式已吸引约 1200 名用户每日使用，并显著提升了产品活跃度。这类案例被视为 Vibe Coding 潜在商业价值的直接证明，也强化了“需求已经存在，平台限制难以阻挡”的判断。

在情绪表达更为直接的评论中，一些用户将问题上升为“规则工具化”的批评。

有观点认为，在现实操作中，规则往往并非中立执行，而是被用作阻止特定事物的手段。“规则不是规则，而是工具”，一位用户以个人经历类比称，这种做法在各类监管环境中并不罕见。

多年前，我亲眼目睹了一群人成功阻止了一栋公寓楼的建设。他们利用了一个法律漏洞——其实他们根本不在乎那个法律条款本身，但他们很清楚，只要祭出这一招，开发项目就得原地踏步。结果，他们如愿以偿。

那天我才恍然大悟：对很多人来说，规则并不是真正的规则。规则只是他们用来阻碍自己眼中钉的工具，至于规则本身到底是为了什么而制定的，根本不重要。

我认为这种心态非常令人作呕，但不幸的是，这正是许多人的行事准则。

套用到这件事上，苹果之所以制定“禁止运行外部代码”的规则，可能只是为了封杀那些他们看不顺眼的东西。而所谓“苹果看不顺眼的东西”，其实并不涵盖所有运行外部代码的应用。虽然被杀掉的应用很多，但由于某种原因，苹果拒绝把这些细节写进明文规定里。如果事实真是如此，那确实很差劲，但我一点也不觉得意外。因为我接触过的每一个监管者，都会给自己留一个“我看一眼就能定罪”的逃生舱，好让他们能随心所欲地查禁任何东西。