Apple is using AI to fix Safari’s extension problem 苹果利用AI解决Safari扩展问题

Apple’s big solve for Safari’s extension drought is to let you “vibe-code” them yourself. On the surface, this is a classic Apple play: identify a glaring weakness—a barren extension library compared to Chrome or Firefox—and address it not by lowering the walls for professional developers, but by handing users a simplified, AI-powered tool to build what they need themselves. It’s elegant, it’s on-brand, and it’s almost certainly going to be a profound disappointment for anyone hoping for a genuine ecosystem shift.

Let’s be clear about the problem. Safari’s extension ecosystem is a desert. For years, developers have balked at Apple’s strict review guidelines, opaque policies, and the sheer technical friction of building for WebKit. The result is that power users and professionals often default to Chrome or Firefox for essential tools: robust password managers, advanced ad-blockers, niche productivity scripts, developer utilities. Apple’s solution isn’t to meaningfully ease those burdens for the talented developers who build and maintain this crucial software. Instead, it’s to encourage a DIY ethos with a generative AI prompt. The subtext is loud and clear: if you want something done right for your specific workflow, do it yourself. We’ll provide the magic pen.

The demo—a recipe tracker conjured from a plain English description—is charmingly mundane. It perfectly illustrates the likely ceiling of this feature. We are not talking about building the next uBlock Origin or 1Password through a chat interface. These are complex applications requiring deep integration with browsers, continuous security updates, and cross-platform compatibility. What Apple is offering is a playground for trivial, single-purpose widgets. It’s a tech demo masquerading as a platform solution. It solves a problem most users didn’t know they had by creating a solution to a problem it itself defines.

This move reveals a deep-seated Apple philosophy: the user as a creative consumer, not a collaborative partner. They don’t want to engage with the messy, competitive world of open extension development. They want to control the entire experience, from the tools you use to how you acquire them. By letting you “generate” an extension, they keep you within their walled garden, using their AI, distributed through their channels (presumably), and subject to their oversight. It’s not about fostering an ecosystem; it’s about managing a curated garden of user-made artifacts that pose no systemic challenge to Safari’s own features or Apple’s business model.

Technically, the challenges are staggering. How does the AI handle requests that touch on privacy-sensitive APIs? What happens when a user’s “simple” description requires complex networking calls or interacts with page elements in potentially insecure ways? Will these generated extensions undergo rigorous security review, defeating the purpose of instant creation? Or will they exist in a sandbox so restrictive they’re useless for anything beyond the demo’s recipe cards? The devil is always in the implementation details, and Apple’s history suggests the details will favor safety and control over utility and power.

Compare this to Mozilla’s approach with Firefox. They’ve spent years nurturing a vibrant, if imperfect, community with clearer documentation, more open APIs, and a culture that actively seeks developer partnership. They treat extensions as a core, strategic part of the browser’s value proposition. Apple, by contrast, treats Safari as a feature of the operating system, an extension as a potential risk to be managed. This AI tool isn’t a course correction; it’s doubling down on that mentality.

The cynical take is that this is a brilliant PR win. It dominates the news cycle with a forward-looking “AI” story, frames Apple as innovative and user-empowering, and provides cover for continuing to not do the harder work of revamping their developer relationships and technical frameworks. It’s a pressure valve for user frustration, not a structural fix. It says, “See? You don’t need those third-party extensions we make so hard to build. You have the power now!” while conveniently ignoring that building a good, secure, maintained extension is a job for a professional.

Ultimately, this feature will likely delight a certain kind of casual tinkerer. It’s fun to ask for a widget that darkens a specific site or adds a button to copy text in a certain way. But for the professional, the developer, the power user whose workflow depends on a suite of well-crafted, reliable extensions, this changes nothing. The gap between Safari and its rivals will remain a chasm. Apple isn’t building a bridge; they’re selling you a kit to build your own rickety plank across it, and they’ll be the ones inspecting it for safety before you can take a single step. It’s a solution that protects the status quo of Apple’s control, and that’s perhaps the most telling judgment of all.

苹果终于承认了Safari的扩展生态是个烂摊子——然后递上了一把更不确定的钥匙。

这个“让AI帮你写扩展”的演示看着挺酷：输入一句话描述，比如“保存网页上的菜谱”，Safari就能吐出一个叫“Recipe Keeper”的插件。苹果管这叫“vibe coding”，我管这叫“皇帝的新代码”。问题在于，菜谱管理这种简单功能或许能糊弄过去，但扩展生态的核心从来不是做几个玩具级插件。当用户需要的是拦截广告、同步密码、深度定制网页行为的工具时，一句模糊的提示词能生成稳定、安全且符合个人需求的复杂代码吗？我看悬。

更讽刺的是，苹果过去用严苛的审核机制和封闭的API把第三方开发者挡在门外，现在却想用AI这个黑箱来替代。这就像一家餐厅因为嫌厨师难管，直接撤了厨房改用自动炒菜机，然后跟顾客说：“你们自己写菜谱，机器给你们做。”问题是，机器做的菜真能吃吗？扩展可不是菜谱，它直接调用浏览器内核权限。一个由AI生成、用户可能完全不理解其代码结构的扩展，简直是安全噩梦。苹果的审核团队准备好处理数万个由非专业人士临时起意生成的“即兴扩展”了吗？

这本质上暴露了苹果的傲慢与矛盾：既不愿真正开放生态让开发者蓬勃创新，又想靠AI噱头解决历史包袱。真正的解决方案很简单——老老实实降低开发门槛、提供更好的文档和激励。但这条路需要扎实的生态运营，远不如甩出一个“AI革命”的标签来得轻松。

最让我怀疑的是“vibe coding”这个词本身。编程是逻辑的艺术，而“氛围编程”听起来像在酒吧里写代码——浪漫，但漏洞百出。用户描述需求时漏掉的每一个细节，AI都可能用一种看似合理却隐患重重的方式自动补全。这不是赋能，这是在制造下一代“技术文盲”，让用户觉得自己创造了东西，却对底层的运行机制一无所知。

所以，别急着欢呼。这更像是苹果在扩展生态长期落后的焦虑下，打出的一张AI投机牌。它解决的是苹果的营销问题，而不是用户的真实需求。当有一天你用AI生成的扩展导致浏览器崩溃或数据泄露时，苹果客服会不会说：“这是你自己让AI写的哦”？

真正的进步，从来不是把复杂的问题丢给一个更复杂的黑箱，然后假装问题消失了。