Why Publish Games on the Web Instead of App Stores

The Commission Problem

Apple takes 30 percent of every in-app purchase and subscription payment processed through the App Store. Google Play takes the same cut, reduced to 15 percent for the first million dollars in annual revenue under their small business program. For an indie developer earning $50,000 a year from a game, that 30 percent commission is $15,000, money that could fund another six months of development.

The web has no platform commission. If you sell premium content through Stripe, you pay roughly 2.9 percent plus 30 cents per transaction. If you monetize through ads, the ad network takes its cut but there is no additional platform tax on top. The difference in revenue retention is dramatic, especially at the scale where most indie developers operate.

Apple's commission is not just a financial issue. It comes with rules. You must use Apple's in-app purchase system for digital goods. You cannot link to your own website for purchasing. You cannot tell users that cheaper options exist outside the app. These restrictions constrain your business model in ways that do not apply on the open web, where you can accept payment through any processor, offer any pricing structure, and communicate freely with your players.

The Review Process and Its Costs

Every update to an iOS app goes through Apple's review process, which typically takes one to three days but can stretch to a week or more during busy periods. Rejections happen for reasons ranging from legitimate policy violations to subjective interpretations of vague guidelines. A game that uses a system font in a way a reviewer does not like, or that includes content a reviewer considers inappropriate, can be rejected without warning.

Google Play's review process is faster, usually completing within hours, but it has its own unpredictability. Automated scanning can flag false positives, and resolving those flags requires navigating Google's support system, which is notoriously difficult for small developers to get human attention from.

On the web, you deploy when you are ready. Push a file to your server, and every player sees the new version on their next visit. Hotfixes for critical bugs go live in minutes, not days. A/B testing a new feature is trivial because you control the serving infrastructure. There is no gatekeeper between your code and your players, which is both a freedom and a responsibility.

Discoverability and the Store Tax

A common argument for app stores is that they provide built-in discoverability. This was more true in 2012 than it is today. The App Store now contains millions of apps, and the vast majority of game downloads are driven by advertising, social media, and press coverage, not by browsing the store. Apple's search ads program means you often have to pay to appear in search results for your own game's genre keywords.

The web's discoverability mechanisms are different but not worse. Search engine optimization can drive organic traffic to your game for years after launch. A well-structured landing page that ranks for relevant keywords delivers free, ongoing player acquisition. Social media sharing of direct links to playable games converts at a higher rate than sharing app store links, because the player can try the game immediately without committing to a download.

Game portals like itch.io, Newgrounds, and CrazyGames have dedicated audiences of players looking for browser games. Listing your game on these platforms is free and can generate meaningful traffic. Reddit communities, Discord servers, and forums dedicated to specific game genres are also effective distribution channels when you can share a link that leads directly to gameplay.

Cross-Platform by Default

A native game that runs on iOS and Android requires either two separate codebases or a cross-platform framework like Unity, React Native, or Flutter. Each adds complexity, build tooling, and platform-specific bugs. A web game runs on every device with a browser. One codebase, one deployment, one URL. Phones, tablets, laptops, desktops, and even smart TVs with browsers can all access the same game.

This universality extends to operating system versions. A native iOS game that uses the latest APIs may not run on older iPhones. A web game that sticks to well-supported standards works on any device with a modern browser, regardless of the OS version, because the browser abstracts away OS-level differences. The lowest common denominator of web standards is high enough to build compelling games without exotic APIs.

For multiplayer games, the web's cross-platform nature is especially valuable. A player on an iPhone can play against a player on an Android phone or a player on a desktop, all accessing the same URL with the same game code. There is no need for cross-play infrastructure or platform-specific networking code.

Update Speed and Iteration

Game development, especially for live service games, depends on rapid iteration. You launch, watch how players behave, adjust, and ship fixes and improvements continuously. On the web, this cycle is as fast as your ability to push code. Deploy a new version and it is live for everyone. Roll back a broken change in seconds.

On the App Store, every iteration passes through the review process. If a reviewer rejects your update, you fix their concern, resubmit, and wait again. A cycle that takes hours on the web can take a week or more through a store. For games that depend on seasonal content, event-driven updates, or rapid balance tuning, this delay is a significant competitive disadvantage.

Server-side changes are possible in native apps too, but changing the client code, fixing UI bugs, updating rendering logic, or adding new game mechanics all require a new build submission. On the web, the client and the server are both under your control with no intermediary.

When the App Store Is Still the Right Choice

The web is not the right platform for every game. If your game needs heavy device integration like ARKit on iOS, deep push notification customization, or access to hardware sensors that the web does not expose, a native app is more appropriate. Games that depend on the App Store's subscription management infrastructure, with its handling of receipts, family sharing, and refunds, may find it simpler to accept the commission in exchange for that infrastructure.

High-end 3D games that push the GPU to its absolute limits will get better performance from native code. While WebGPU closes the gap significantly, there is still overhead in the browser layer that matters at the extreme high end. AAA-quality graphics with millions of polygons, complex post-processing, and minimal load times are still easier to achieve natively.

Games targeting markets where a large portion of users have older, lower-end devices may also find that the web's overhead is a problem. In some regions, phones with 2 GB of RAM and older GPUs are common, and the browser's memory overhead reduces the budget available for the game itself. In these cases, a lightweight native app can deliver a better experience on constrained hardware.