Apple App Store Blocks Updates for Vibe Coding Apps
As Apple celebrates its 50th anniversary, the company finds itself at a crossroads of technology and platform governance once again.
Recently, Apple has imposed restrictions on several Vibe Coding applications in its App Store, sparking widespread discussion among the developer community and industry observers.
Reports indicate that Apple has blocked updates for at least two applications based on the Vibe Coding concept, including the well-known online development platform Replit, and has removed the related product Anything twice, citing security compliance. Apple has demanded significant adjustments to the core “Vibe Coding” functionalities of these applications, and during certain review stages, Apple reviewers hinted at the need to completely remove these features.
This restriction has directly led to applications like Replit being unable to push new versions to iOS, forcing users to remain on outdated versions. Given the rapid pace of technological iteration, each time Apple blocks an update, it widens the gap between old and new versions, ultimately leading to a significantly different experience for iOS users compared to those on other platforms.
Dhruv Amin, co-founder of Anything, stated in a media interview that Apple removed their application on March 26. Although it was briefly restored, the company has not been able to gain re-approval since then.
Replit’s CEO Amjad Masad has openly expressed that they have adhered to all of Apple’s rules, yet Apple’s actions have rendered developer tools on iOS inoperable.
Just days ago, a frustrated Amjad Masad publicly criticized Apple for siding with historical errors.
Why Is Apple Doing This?
The core reason for Apple’s restrictions on Vibe Coding applications is its belief that these applications bypass the long-standing review mechanisms of the App Store, posing potential security risks.
Apple points out that the key issue with these applications is that they allow users to run unreviewed software logic within the app. Although the generated code typically runs in a cloud or browser environment (rather than being directly installed on iOS devices), it fundamentally circumvents Apple’s pre-review process by dynamically generating and executing code—something Apple cannot accept.
Moreover, Apple has stated that this restriction is not a temporary measure but is based on existing terms in the App Store review guidelines (Rule 2.5.2).
“Applications should maintain independent operation within their software package, should not read or write data outside designated container areas, and should not download, install, or execute any code that introduces or alters application features or functions. Educational applications intended for teaching, development, or allowing students to test executable code may download code under specific circumstances, provided that this code is not used for other purposes. Such applications must ensure that users can fully view and edit the source code provided.”
This clause explicitly states that applications “should not download, install, or execute code that introduces or alters application features or functions.”
It is noteworthy that this rule was established before AI coding became an independent technological category, but Apple believes its applicability covers all dynamic code execution scenarios.
Specifically, why does Vibe Coding trigger this rule?
The reason is simple: Apple’s review process evaluates the code before approving an application for release. If an application can execute code generated after review, much of the value of the review process is rendered moot. The application a user runs could be entirely different from the version approved by Apple.
This rule has historically prevented scripting environments, plugin systems, and circumvention of the App Store’s update mechanisms.
For Apple, the App Store review mechanism is not only a commercial distribution channel but also the cornerstone of its security model—protecting against malware, privacy abuses, and illegal access to sensitive permissions like the camera, contacts, and location. This “closed and controllable” ecosystem is also a significant source of trust for iPhone users.
In response to external criticisms regarding its actions against Vibe Coding applications, Apple has stated that its actions are not targeted at Vibe Coding itself but are based on the enforcement of existing rules, emphasizing that different products have different implementation paths. For example, Claude also supports generating and running applications, but its functionalities are more internal to the application, unlike Replit, which relies on an external browser environment. Additionally, Apple has not rejected the trend of AI programming—its development tool Xcode has introduced capabilities from OpenAI and Anthropic this year.
The Battle Behind the Restrictions: Defending the 30% Commission
Among the developer community, some have expressed skepticism about Apple’s justification of “safety compliance” for restricting updates to Vibe Coding applications, arguing that its reasoning lacks coherence.
Their core argument is that the act of users creating web applications using tools like Replit does not alter the underlying logic of the Replit application itself—this operation is essentially personalized content generation completed within the application, which neither involves fundamental adjustments to Replit’s functionalities nor disrupts the normal operation of other applications in the App Store. Therefore, Apple’s direct equating of “dynamically generated content” with “security risk” lacks practical basis.
Further analysis suggests that Apple’s stringent review of dynamic code execution is fundamentally about maintaining its absolute control over the application ecosystem through rules—even if technological means (like cloud execution) have reduced local risks, Apple still prefers to control the boundaries of application functionalities through its review authority, ensuring that all actions within the ecosystem remain within a regulatory scope.
Beyond the pretext of technical safety, a video segment from The Information featured AI reporter Stephanie Palazzolo and Apple-focused journalist Aaron Tilley discussing deeper commercial conflicts reflected in Apple’s blocking of updates for Replit and Vibecode applications.
Stephanie Palazzolo pointed out that Apple’s actions are driven by three major motivations:
First, the surge in review pressure. With the lowering of AI programming barriers, the number of new applications submitted to the App Store has exploded, overwhelming Apple’s review team. By restricting such programming tools, Apple can slow down the influx of new applications from the source.
Second, and most critically, is the prevention of “escaping the App Store.” Applications generated using tools like Replit are often web applications (Web Apps) that can run without being listed on the App Store. For Apple, this not only means losing control over application data but also losing the ability to extract up to 30% in “Apple tax.”
Finally, competitive threats cannot be ignored. These lightweight, intelligent third-party programming tools are gradually competing with Apple’s own developer tool Xcode in functionality. Apple clearly does not want to see developers bypassing the official ecosystem to embrace more flexible third-party AI tools.
They also noted that while most heavy developers still prefer to operate on MacBook desktops, the obstacles on mobile have already caused substantial harm to these AI startups. For instance, due to months of being unable to update their mobile application, Replit has seen a significant drop in its ranking on the App Store’s popular developer tool chart, with traffic and revenue affected to varying degrees.
Apple journalist Aaron Tilley commented that historical experience shows that Apple never backs down when it feels its platform position is threatened. From the dispute with Epic Games over payment systems to responding to European regulatory demands for sideloading, and to the tussle with Tencent over the mini-program ecosystem, Apple has consistently defended its “walled garden” model.
The logic is not complicated: by strictly controlling distribution channels and transaction paths, Apple ensures both user experience and safety while maintaining its value capture ability within the ecosystem.
This commercial motivation is particularly evident in financial data.
The services business, which includes the App Store, has become one of Apple’s key growth engines, with annual revenue exceeding $100 billion and profit margins significantly higher than hardware sales. If applications bypass the App Store and are distributed directly via the web, Apple will be unable to extract 15% to 30% in commissions. This makes the boundary between “safety” and “protection of the business model” increasingly subtle.
Meanwhile, the rise of Vibe Coding has exceeded expectations. In just over a year, this market, which was nearly nonexistent, has birthed several companies valued at billions of dollars. More importantly, it is changing the structure of software production—from professional developers to designers, creators, and even ordinary users. Data shows that the number of applications published on the App Store has increased by about 60% year-on-year over the past year, reaching a new high in nearly a decade, and this is just part of the entire Vibe Coding ecosystem. Many applications are actually born in open web environments and have not entered Apple’s review system.
Numerous projects created by individuals further illustrate this change.
Some users without programming backgrounds have successfully transformed their ideas into real products for the first time using AI programming tools, even achieving commercialization. These users do not have the traditional development path conditions of using Mac and Xcode, while Vibe Coding precisely fills this gap. From this perspective, Apple’s provided path of “developing on Mac and then submitting for review,” while technically feasible, does not truly address the needs of this emerging user group.
Although Apple may eventually reach some compromise with these companies, allowing them to continue existing, these applications will inevitably operate only within the “warning lines” defined by Apple.
On the execution level, this incident also exposes uncertainty. Reports indicate that since the beginning of this year, Apple has repeatedly adjusted its review reasons for related applications, and even when developers have modified previous issues, they still face new compliance challenges. Meanwhile, the rankings and revenues of related applications in the App Store have also been affected. Developers have expressed that their products have complied with Apple’s rules for years and have passed hundreds of reviews, and this restriction has left them feeling “surprised and disappointed.”
From a broader perspective, the core issue of this controversy is not whether Vibe Coding will become popular—this trend is almost a foregone conclusion—but rather in which ecosystem it primarily occurs.
Rebecca Haw Allensworth, an antitrust law professor at Vanderbilt University, stated that economists have long observed that monopolists encourage competition on their platforms only to a certain extent.
“They want to control the direction of innovation, steering it away from things that would undermine their monopoly,” she said.
If Apple continues to ban these tools, developers may leave. They will turn to developing web-based applications, as publishing applications on the web does not require Apple’s permission. Ultimately, iPhone users may face a worse application ecosystem because Apple has driven away developers who once enriched the ecosystem.
Apple is not facing this dilemma for the first time. In the 1990s, Microsoft rapidly expanded the personal computer market through an open ecosystem, while Apple fell into difficulties due to its closed strategy. It was not until Steve Jobs returned and re-emphasized user experience and the release of creativity that the situation was reversed.
User Reactions: Apple Is Pushing Users Further Away
In the context of Apple restricting multiple Vibe Coding applications, discussions within the developer community have quickly intensified.
On Reddit, users have complained that this policy is outdated.
Apple’s rule can be traced back at least 17 years, to when Jobs was CEO! In an era where Mac computers use A chips and iPads use M chips, this truly proves how outdated the developer policy is.
Some users argue that Apple’s actions are in defense of the App Store’s interests, contradicting their closed product strategy with the AI Coding concept. One wrote:
This was bound to happen. If people can write their own applications and run them with just a prompt, the entire App Store market will collapse. Apple’s strategy is completely contrary to the concept of AI programming.
On Hacker News, many comments have dissected this incident from various angles, including rule interpretation, technical implementation, and platform governance logic.
Regarding the rules themselves, the controversy initially focused on Apple’s restrictions on “running external code.”
One user directly quoted the relevant provisions, pointing out that Apple explicitly requires applications “not to download, install, or execute code that alters application functionalities,” with limited exceptions for educational applications. This has become a starting point for many to understand this incident—namely, that Vibe Coding applications inherently allow users to generate and run code, thus naturally placing them in a gray area of the rules. Some comments suggest that from this perspective, the restriction of such applications is “not surprising,” as “allowing custom code to run within applications has always been prohibited.”
However, the problem lies in Apple’s seemingly “double standards.” Several users noted that some long-standing applications have actually been doing similar things. For instance, one pointed out that Apple’s own Swift Playgrounds allows users to write and run code but is classified as an “educational application,” thus qualifying for the exception clause; while third-party applications like Pythonista have allowed arbitrary Python code execution for years without facing the same restrictions.
Some comments bluntly stated, “The ’educational’ exception clause seems more like a convenient loophole,” and the real issue is whether Apple selectively enforces the rules.
Another important thread in all comments is the reflection on platform openness.
Some comments view this incident in the context of broader ecosystem competition. One user pointed out that for a long time, Linux and Windows have been significantly superior to Apple in terms of customizability, while Apple has adhered to the philosophy of “defining user experience by the platform.” In the current era, where generative AI makes “software customization” possible, this model may face challenges.
Some believe that as users increasingly wish to generate and modify applications on demand, traditional app forms are becoming “rigid,” while the appeal of open platforms like the web is rising.
In light of this trend, some developers shared practical cases. One comment mentioned that they are building “white-label” Vibe Coding capabilities for a company that has completed Series B funding, allowing its SaaS platform clients to directly generate the needed functionalities. It is reported that this model has attracted about 1,200 daily users and significantly increased product engagement. Such cases are seen as direct proof of the potential commercial value of Vibe Coding and reinforce the judgment that demand already exists, and platform restrictions are hard to block.
In more direct expressions of emotion, some users have elevated the issue to a critique of “weaponizing rules.”
Some viewpoints suggest that in practical operations, rules are often not executed neutrally but are used as tools to block specific things. “Rules are not rules; they are tools,” one user compared with personal experience, stating that this practice is not uncommon in various regulatory environments.
Years ago, I witnessed a group successfully halt the construction of an apartment building. They exploited a legal loophole—actually, they did not care about that legal provision itself, but they knew that as long as they invoked it, the development project would be stalled. As a result, they got what they wanted.
That day, I realized: for many people, rules are not truly rules. Rules are merely tools they use to obstruct what they see as thorns in their side, and the original purpose of the rules is irrelevant.
I find this mindset very disgusting, but unfortunately, it is precisely the operating principle of many.
Applied to this matter, Apple’s rule against “running external code” may simply be a means to eliminate things they disapprove of. However, what “Apple disapproves of” does not encompass all applications that run external code. While many applications have been killed off, for some reason, Apple refuses to detail these specifics in written regulations. If this is indeed the case, it is quite disappointing, but I am not surprised at all. Because every regulator I have encountered tends to leave themselves an escape hatch that allows them to freely ban anything they wish to.
Reference Links:
https://developer.apple.com/app-store/review/guidelines/
https://www.mindstudio.ai/blog/apple-blocking-vibe-coding-apps-explained
https://www.reddit.com/r/apple/comments/1rx53n0/apple_quietly_blocks_updates_for_popular_vibe/
Comments
Discussion is powered by Giscus (GitHub Discussions). Add
repo,repoID,category, andcategoryIDunder[params.comments.giscus]inhugo.tomlusing the values from the Giscus setup tool.