Apple's App Review Process Is Becoming a Gatekeeper for Software It Doesn't Understand

Apple has every right to protect iPhone users from malicious software.

No serious developer wants an App Store application to download arbitrary native code, evade code signing, or transform itself into something Apple never reviewed. Those restrictions are a major part of why people trust the platform.

But there is a growing difference between protecting users from unreviewed native code and treating anything that looks like software development as though it is secretly installing another iPhone app.

That distinction matters, especially now that AI coding tools can create websites, interfaces, and complete applications from nearly anywhere.

Apple's concern around so-called vibe-coding apps is understandable. A native app should not be able to download code that escapes its reviewed boundaries or quietly gains new access to the device. But if a development tool generates a website on a remote machine and displays that website inside WKWebView, the security question should be about what that content can do—not whether the result happens to resemble an app.

A webpage rendered by WebKit is not automatically another installed iOS app.

That does not mean every website wrapped in a thin native shell belongs in the App Store. Apple has a separate minimum-functionality rule for exactly that problem. But a rule against repackaged websites is not the same as a rule against a full development client using a web view to display a user's work.

Conflating the two could have serious consequences for an entire generation of development tools.

A web view does not install another iOS app#

Consider a development application that lets someone edit a project on a Mac or cloud machine, run a development server there, and inspect the result inside WKWebView on an iPhone.

What is actually happening?

The source files remain in the development environment. The server compiles or serves the project. It returns HTML, CSS, JavaScript, images, and other web resources at a URL. WebKit loads those resources, renders the page, and executes client-side JavaScript using its web runtime.

That process does not, by itself:

modify the native application binary;
inject new Swift or Objective-C code into the installed app;
install another iOS application;
bypass Apple's code-signing system; or
grant the webpage arbitrary access to the device.

Developers building this kind of client are not trying to use a web view to control, replace, or change the native functionality of the host app. There is usually no reason for them to do so. The native client already provides the editor, workspace controls, Git tools, terminal, agent interface, and device integration that Apple reviews.

The web view has a much narrower purpose: it lets users see and interact with the web project they are currently building. It is an output surface for the user's work, not a mechanism for rewriting the native application around it.

Apple's own documentation describes WKWebView as a platform-native view for displaying interactive web content. Apple's App Review Guidelines also say that apps browsing the web must generally use the appropriate WebKit framework and WebKit JavaScript, with limited regional entitlements for other browser engines.

That does not mean all web content is harmless. A host app can deliberately expose native capabilities through a JavaScript bridge. A malicious page can phish a user, exploit a browser vulnerability, or mishandle private data. Those are real risks, and Apple should review them seriously.

But they are capability risks. They come from what the host exposes, what the content can access, and whether the platform's security boundaries hold. They do not come from whether the webpage has tabs, buttons, an editor, or a design that looks native.

An "app preview" is a description, not a technical fact#

Words can quietly decide the outcome of a review.

Calling a web project an "app preview" makes it sound as though an iPhone application is being compiled elsewhere, streamed onto the device, and executed outside Apple's review process. That would be meaningfully different from what many development tools actually do.

If a user writes:

html

<h1>Hello world</h1>

and a remote development server serves that HTML at a URL, opening the URL in WebKit does not turn the document into an iOS application.

Adding React does not change that. Adding Next.js does not change that. Having an AI agent write the React does not change that. Making the result resemble a mobile application does not change the runtime or grant it new privileges.

The content may be sophisticated software in the broad sense. Modern websites can be editors, games, video tools, design systems, and complete development environments. But sophisticated web content is still web content.

Safari does not become a new native application every time someone visits a different URL. A WKWebView does not become a new native application every time it renders a different development server either.

The native functionality remains the host and its browser surface. The content changes inside that surface.

Those are not the same thing.

Apple's own guidelines expose the ambiguity#

Guideline 2.5.2 says apps may not "download, install, or execute code" that introduces or changes the app's features or functionality. It also provides a limited exception for certain educational apps that let users view and edit source code.

The purpose of that rule is sensible. Apple needs to prevent a reviewed binary from turning into an unreviewed native runtime after approval.

But the guidelines do not stop there. Guideline 4.7 expressly allows apps to offer certain software that is not embedded in the binary, including HTML5 and JavaScript mini apps, subject to additional safety, privacy, commerce, indexing, and age-rating requirements. Guideline 4.7.2 then draws a particularly important line: the host may not extend or expose native platform APIs to that software without Apple's prior permission.

That is already an acknowledgment that remotely supplied JavaScript is not categorically forbidden. It is also an acknowledgment that access to native capability matters.

The unresolved question is where ordinary web content ends and "software offered in an app" begins.

Does a development client "offer" software when a user opens their own project? Is a private development URL supposed to be treated like a catalog of mini apps? Does every branch preview need the metadata and universal-link structure designed for software distributed to an audience? Would the answer change if the identical URL were opened in Safari?

Developers should not have to infer those answers from the visual appearance of their output or from whichever noun an individual reviewer uses to describe it.

Minimum functionality is a legitimate but separate question#

Apple does have a guideline addressing apps that are little more than websites inside native containers.

Guideline 4.2 says an app should provide features, content, and interface elements that elevate it beyond a repackaged website. It also says apps should not primarily be web clippings, content aggregators, marketing material, or collections of links.

That policy is understandable. The presence of a WKWebView should not automatically entitle a thin wrapper around a public website to App Store distribution. Apple wants submitted apps to provide adequate utility and a meaningful experience of their own.

But that is a different question from whether web content displayed inside an otherwise native application becomes executable code that changes the host app.

A development client may include native workspace management, file navigation, code editing, Git operations, terminal sessions, agent controls, device pairing, and authentication. Its web view is not the product being wrapped. It is one surface within the product: the browser used to inspect what the developer is building.

The generated webpage is the user's project, not the native implementation of the development client itself. Displaying that project does not imply that its developer wants the page to control or mutate the client's native features.

This is where Apple's current rules become unclear. Under Guideline 4.2, a web wrapper can be rejected because it is not app-like enough. Under a broad reading of Guidelines 2.5.2 or 4.7, interactive content inside a full-featured native tool can be treated as though it is an additional app. Apple can reasonably reject thin website wrappers without classifying every website rendered inside a native tool as downloaded application functionality.

The guidelines should say clearly how App Review distinguishes those cases.

The real test should be the security boundary#

Apple should ask concrete questions:

Where does the code execute?
Can it modify the reviewed native binary?
Can it install executable native code or bypass code signing?
Can it call private APIs?
Does the host expose native APIs, hardware, files, or permissions to the web content?
Can the content escape WebKit's and the host application's sandbox?
Is the developer distributing a catalog of third-party software, or is a user inspecting a project they control?

Those questions map to actual security and platform risks.

"Does this webpage resemble an app?" does not.

Appearance is an especially poor proxy now that ordinary websites routinely look and behave like desktop and mobile software. A polished interface can be less privileged than a blank page with a dangerous native bridge. Judging the first more harshly because it looks app-like would invert the security model.

Apple should regulate capability, privilege, and distribution—not aesthetics.

AI makes this distinction urgent#

A modern coding agent can:

create a project;
edit source files;
install dependencies;
run a development server;
deploy a branch;
produce a URL; and
let the developer inspect the result.

That workflow is becoming ordinary software development.

The machine doing the work might be a MacBook. It might be a cloud VM or a Linux container. The screen used to supervise it might be a Mac, an iPad, or an iPhone. Moving the screen should not change the technical classification of the software running on the remote machine.

If the developer opens the generated URL on a laptop, it is plainly a webpage. If the same developer opens the same URL through a WebKit view on an iPhone, it should not become unreviewed native code by proximity.

Otherwise Apple is not merely protecting iOS. It is deciding which forms of computing are legitimate when initiated or supervised from an iOS device.

That is a much broader exercise of power.

The developer has almost no leverage#

This is where App Review stops being a narrow technical process.

Apple operates the platform. It controls the primary distribution channel for reaching iPhone users in many markets, even as alternative distribution is now available in some regions. It writes the App Review Guidelines, interprets them, conducts the review, and runs the appeal process.

Apple also describes those guidelines as a "living document" and says that new apps presenting new questions may produce new rules at any time.

There is a reasonable reason for that flexibility: software changes quickly, and no static rulebook can anticipate every abuse. But flexibility for Apple becomes uncertainty for everyone building on its platform.

A startup may spend a year developing a product around a reasonable reading of the published rules. It may hire employees, raise capital, acquire customers, and build expensive infrastructure. Then App Review can decide that a central capability falls on the wrong side of a distinction that was never clear when development began.

Apple does provide a path to appeal a rejection, and the guidelines say the company aims to apply its rules fairly and consistently. That process matters. It does not erase the commercial asymmetry when the same platform owner writes the standard, applies it, and controls access to the market.

The developer agreement makes the imbalance worse#

Apple's current Developer Program License Agreement deserves more attention in this conversation.

To the extent applicable law permits, the agreement excludes liability for categories including lost profits, lost data, business interruption, and other commercial losses associated with the agreement, Apple's software and services, or participation in the program. It then says Apple's total liability under the agreement will not exceed $50, apart from circumstances where applicable law requires otherwise, including its stated personal-injury qualification.

Think about that mismatch.

A developer could build a company worth millions of dollars whose launch and growth depend on App Store distribution. A review decision could cost that company customers, employees, investor confidence, and market timing. Yet the contract is written to sharply limit Apple's exposure to the commercial losses that would matter most to that startup.

This does not mean Apple has made itself impossible to sue. Contractual limitations can be challenged, statutes can create rights outside a contract, and enforceability depends on the claim and applicable law. The agreement itself contemplates litigation and dispute resolution. Its default provision routes covered disputes to state or federal courts in the Northern District of California, subject to exceptions elsewhere in the agreement, including special treatment for certain government entities and European claims.

The $50 clause is not a force field.

It is still a striking allocation of risk: the developer bears potentially existential platform risk while Apple's contractual exposure is heavily restricted.

One party controls access to the market. The other generally accepts a standard agreement because there is no individually negotiated alternative for joining the program and distributing through Apple's ecosystem.

Apple has the platform. Apple wrote the agreement. Apple wrote the guidelines. Apple interprets the guidelines. And Apple decides whether the software ships through its store.

Calling that an ordinary developer-platform relationship understates the power involved.

This is why the gatekeeper conversation will not go away#

The criticism of Apple's control over iOS is no longer limited to frustrated independent developers.

The European Commission has formally designated Apple as a gatekeeper under the Digital Markets Act for services including the App Store, iOS, Safari, and iPadOS. In the United States, the Department of Justice's antitrust complaint against Apple has likewise challenged aspects of the company's control over app distribution and platform access. A complaint contains allegations, not final findings, but its existence shows how far the concern has moved beyond App Review anecdotes.

People can disagree about whether Apple's conduct satisfies the legal definition of monopolization in a particular jurisdiction. The policy concern is easier to see.

When one company controls an operating system, major distribution channel, technical restrictions, review rules, and approval process, its product-policy decisions can begin to function like private market regulation.

App Review is not merely quality assurance. For many developers, it determines whether a business can reach a vast part of the mobile computing market.

That power deserves scrutiny proportional to its consequences.

Apple can protect users without deciding what counts as real development#

There is a reasonable middle ground.

Apple can prohibit apps from dynamically downloading native executable code that changes the capabilities of the reviewed binary. It can enforce sandbox boundaries, prevent code-signing circumvention, block private API access, and stop applications from installing unreviewed iOS binaries.

It can require explicit permission when a host exposes native capabilities to web content. It can demand transparency about remote software distributed to users. It can aggressively police malware, fraud, and abuse.

None of those protections require Apple to classify a developer's remotely hosted webpage as another installed iOS application merely because it is interactive or looks polished.

For development clients, Apple could publish a clear rule based on four things:

Execution: Web content remains inside WebKit and does not execute as native code on the device.
Privilege: The host does not expose undeclared native APIs, permissions, or device capabilities to that content.
Integrity: The content cannot modify the host binary, bypass code signing, or escape the application's sandbox.
Control: App Review distinguishes a user's own development project from a developer-curated catalog of third-party mini apps distributed to the public.

That would give Apple a technically meaningful standard and give developers a rule they can design around.

The boundary should be based on what code can actually do to the device—not what the webpage happens to look like, whether an AI wrote it, or whether the screen displaying it fits in a pocket.

Because once a platform owner can decide that a webpage becomes an "app" whenever the use case makes it uncomfortable, the issue is no longer just sandbox security.

It is gatekeeping.

Developers deserve rules that are technically coherent, predictably applied, and proportionate to the risks they are supposed to address.