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.
The Financial Math for Indie Developers
The numbers make the case clearly for most indie game developers. A game that earns $10,000 per month through in-app purchases on the App Store keeps $7,000 after Apple's 30% commission (or $8,500 after the first year if eligible for the Small Business Program's 15% rate). The same game distributed through the web and using Stripe for payments keeps $9,700 after Stripe's 2.9% plus $0.30 per transaction processing fee. Over a year, that difference compounds to $32,400 in additional revenue at the higher commission rate. For solo developers and small studios, that margin covers salaries, hosting costs, and marketing budget.
Payment processing on the web is not limited to Stripe. Developers can use PayPal, Paddle, LemonSqueezy, or direct cryptocurrency payments, each with different fee structures. Some payment processors offer lower rates for high-volume digital goods (1.5-2.5%), further widening the gap against app store commissions. The flexibility to choose and switch payment processors is itself a competitive advantage that app stores do not offer. For web games using advertising as the primary monetization model, there is no commission at all, since ad networks pay directly to the developer regardless of distribution channel.
Hosting costs for web games are modest. A static site on Cloudflare Pages or AWS S3 with CloudFront serves millions of players for dollars per month, not thousands. The game files are cached at edge nodes worldwide, so players load the game from a server near them regardless of where the developer is based. Compare this to the cost of maintaining separate builds for iOS and Android, each requiring annual developer account fees ($99/year for Apple, $25 one-time for Google), code signing certificates, and the developer time to manage two separate submission and review pipelines.
The web eliminates platform commissions, review delays, and multi-platform build complexity. For games that do not require deep native hardware access or AAA-level GPU performance, publishing on the web gives developers more revenue, faster iteration, and broader reach than any app store.