On 31 August, a Stale Licensed APK Stops Reaching New Users on 43% of Android. That Is the HTML5-vs-APK Decision in One Number.

Before you buy Android games or license HTML5 games, price the maintenance clock each format attaches: one has a Play Store deadline, the other never stops.

The HTML5-versus-APK conversation almost always starts in the wrong place: which format performs better, which one players prefer, whether WebGL has caught up with native. Those are engineering questions, and for a casual catalogue the honest answer is that the difference stopped mattering years ago. A match-3 title runs fine in both.

The difference that survives contact with a real business is administrative. An APK sits inside a store that periodically raises the floor and cuts off anything that does not step up. An HTML5 build sits on a URL that nobody polices, on a platform that changes underneath it without telling you. Both cost money to keep alive, on completely different schedules — and the schedules are what should decide your format, not the render pipeline. There is a date on the calendar this week that makes the point better than any argument.

📅 The Deadline That Lands This Week

Google Play's target API level requirements state that from 31 August 2026, "New apps and app updates must target Android 16 (API level 36) or higher," and that "Existing apps must target Android 15 (API level 35) or higher to remain available to new users on devices running Android OS higher than your app's target API level."

Read the second half carefully, because that is the part that hits a licensed catalogue rather than a single flagship app. Nothing gets deleted — Google is explicit that "Users who have previously installed the app from Google Play will not be impacted." An extension is available on request "to November 1, 2026."

So a title that misses the floor throws no error, sends no email on the day, and shows up in no dashboard. It quietly stops being installable by new users on newer phones. If you licensed 300 APKs and 40 were built against an older SDK by a developer who has since moved on, you find out from a slow, unexplained decline in installs — usually a month or two after it started.

➗ Where the 43% Comes From

Put a number on "newer phones." Statcounter's Android version market share for July 2026 puts Android 16 at 25.49% worldwide and Android 15 at 17.19%, with Android 13 on 14.78%, Android 14 on 13.14%, Android 12 on 10.09% and Android 11 on 8.32%.

Take a licensed APK that targets API 34 — Android 14, which was a perfectly respectable target when a lot of catalogue builds were last touched. From 31 August it is unavailable to new users on any device running an OS higher than its target. Android 15 and 16 together are 42.68% of Statcounter's July 2026 sample. Anything newer than 16 adds to that.

Two caveats, because a number this convenient invites overreach. Statcounter measures pageview share, not device share, and skews toward devices that browse; Google's own Play-side distribution data samples a different population and lands elsewhere. And version mix varies hard by market — a catalogue aimed at Tier 1 Europe faces a newer install base than one aimed at a market where three-year-old handsets dominate. The point is not that the figure is exactly 43%, but that the exposed share is somewhere between a third and a half of the addressable base, for a build you did not write and cannot recompile.

🌐 The Web Side Has No Deadline. It Has a Cadence.

The mirror image deserves equal honesty. No gatekeeper can delist an HTML5 game. Nobody reviews your portal. There is no target API level for a URL and no annual compliance exercise. For a lot of buyers that alone settles it.

What replaces it is unscheduled breakage. Google announced in March 2026 on the Chrome for Developers blog that Chrome moves to a two-week release cycle from 8 September 2026, starting with Chrome 153 — roughly 26 releases a year instead of 13. None will delist anything. Some will change an autoplay behaviour, a storage rule, an audio-context requirement or an iframe permission that a slice of a thousand-title catalogue happens to depend on.

The failure mode is the difference. An APK problem is dated, catalogue-wide and announced: you know when it lands, you know it affects everything, and you can plan a quarter around it. An HTML5 problem is undated, partial and silent: eleven titles out of 900 stop playing audio on one browser, and you find out from a support ticket, or you never find out at all because players just bounce. A team with a games ops function handles the web failure mode easily and hates the store deadline. A marketing team that will not look at the portal again after launch is better off with the announced, plannable one — if, and only if, somebody is contractually obliged to do the annual bump.

🚪 The Install Step Is the Rest of the Trade

Everything above is maintenance. The reason anyone accepts APK maintenance is that the install buys things a web build cannot have: a home-screen icon, push notifications, genuinely offline play, store search as a discovery channel, and a device fleet you can preload onto.

The cost is the funnel. AppTweak's 2025 conversion-rate benchmarks put the average across all categories on US Google Play at 16.15%, defining conversion as the share of users who download after viewing the listing page. Games sit well below that — AppTweak names Games–Strategy at 6.6%, the lowest subcategory on Google Play. Other 2026 benchmark write-ups put casual games lower still, in the low single digits; published figures disagree by several multiples because they sample different traffic sources and define the denominator differently. Take the range, not the number: roughly 3% to 7% of people who reach a casual game's store listing install it.

An HTML5 game on a portal has no listing and no install. It has its own leak — load time, and a player who taps back before the loader finishes — but that leak is measured in seconds of patience, not in a decision to give up storage space. If your traffic arrives once and may never come back, the install step is a tax you cannot afford. If your traffic is a device you already control, it is free.

💳 The Billing Rail Moves With the Format

The third axis is money, and it moved recently enough that a lot of licensing decisions were made under the old assumptions. Google's policy update for developers serving US users confirms a settlement agreement with Epic entered on 4 March 2026, and states that "developers enrolled in the external content links and alternative billing programs in the US will need to report transactions and successful downloads and pay the relevant service fees starting on October 1, 2026." The same page records that from 22 June 2026 Google began providing app listings to third-party US Android app stores unless developers opted out by 22 July 2026.

The practical reading for a catalogue buyer: routing payments outside Play in the US is now allowed and now metered. Play's fee schedule ties the rate to region and programme, so read your own market's page rather than a summary of it — but plan on external transactions carrying a fee and a reporting obligation, not on being free.

A web portal is on a different rail entirely. You take card or wallet payments directly, or — on a carrier deck — bill through the operator, which is the whole reason telecom portals are built in HTML5. There is no store to share with. There is also no store handling refunds, tax registration, chargebacks or churn dunning for you, which is real work that Play's fee is partly buying.

🧭 Five Buying Scenarios, Decided

Abstract comparisons are useless. Here is how the choice actually resolves.

A carrier or operator portal, several hundred titles, live in weeks

HTML5, and it is not close. The operator wants a web deck integrated with carrier billing and breadth on day one. Three hundred APKs would mean three hundred store listings you do not control and a billing rail the operator does not own. When operators buy a games catalogue for a carrier deck, the billing integration decides the format before anyone looks at a game.

An OEM preload or an enterprise device fleet

APK, and only a handful of titles. A preload slot is one app, so the right shape is a single container app with a curated set inside it, not a catalogue of separate installs. This is the scenario where the 31 August clock matters most, because a preloaded build that ages out is embarrassing in a way a portal title is not — you shipped it on the hardware.

A trade-show booth or event activation

HTML5, on a tablet in kiosk mode. Nobody installs anything at a booth, the machine has no store account, and you want to change the game the week before the show. Wi-Fi at a venue being what it is, ask for a build that runs from local files rather than a hosted URL.

A brand campaign with a six-week flight

HTML5, embedded in the campaign site or linked from social. An APK adds an install step to a funnel that already has a conversion goal at the end of it, and a store review to a schedule set by a media buy. The exception is a campaign whose whole point is driving app installs — then the game belongs inside the app you are already promoting.

A subscription games service in a market with patchy connectivity

APK, or both. Offline play is the product. A service worker gets an HTML5 catalogue part of the way there, and "part of the way" is a bad promise to sell a subscription on.

And the case for neither

If you need one game, deeply tied to a mechanic nobody else has, and it is the centrepiece rather than the furniture — commission it from a studio, or build it. A catalogue licence is the right instrument for breadth and the wrong one for a single hero title. Anyone who tells you licensing wins every scenario is selling, not advising. What it wins is volume, speed and cost per title, and it wins those decisively.

📋 The Format Clauses to Settle Before You Sign

Whichever way you go, put the maintenance obligation in the agreement rather than in an assumption. Six things to get in writing:

• Who ships the target API bump, and how often. Play raises the floor on a rolling annual basis. "We provide updates" is not a commitment; "we deliver compliant builds within N days of each announced Play deadline, for the term" is.
• Whether the obligation is per title or catalogue-wide. A per-title update fee across 300 APKs is a different business than an included catalogue refresh.
• Who holds the signing key and owns the Play listing. If the licensor publishes under its own developer account, your "catalogue" is a set of listings you cannot move. If you publish, you inherit every obligation attached to being the developer of record.
• Whether the same titles are available in both formats under one agreement. Discovering in month nine that your HTML5 licence does not cover an APK build is the most expensive version of this mistake.
• Browser-breakage response on the HTML5 side. A named response window for "this title stopped working in current stable Chrome" is worth more than a longer feature list.
• What happens at renewal. Removing an app your users have installed is a different operation from removing a URL.

🚫 Four Ways Buyers Get the Format Choice Wrong

• Picking APK because "an app feels more serious." A positioning instinct, not a distribution argument, and it costs you the install-funnel loss above for nothing.
• Assuming an HTML5 catalogue converts to APK cheaply. Wrapping a web build in a container is technically easy and commercially loaded — it changes the rights you need, the age rating you carry, and who is developer of record.
• Buying APKs with no plan for the annual bump. The build is a snapshot of a compliance state that expires. Budget the refresh, or buy from someone who owes you one.
• Shipping a thousand-title catalogue as a thousand listings. Play takes a dim view of near-identical bulk submissions. One container app with a curated catalogue inside it is the shape that survives.

🎯 How It Works When You License HTML5 Games and Buy Android Games Together

The reason to have this conversation with a direct licensor rather than a one-title seller is that the format decision stops being a purchase and becomes a scope question. Forestry Games has licensed games since 2017 and carries a catalogue of 1,049 titles spanning both HTML5 and Android APK builds, with HTML5 development done in house. That means the same catalogue conversation covers a web portal, an APK container, or both, under one licence scope rather than two suppliers and two negotiations.

What a licence covers is deliberately concrete: HTML5 builds for web, portal and embedded use, APK builds where the use case is Android, source where the arrangement calls for it, branding and reskin options, and hosted or self-hosted delivery depending on whether you want to run infrastructure. A catalogue that size is not meant to be taken whole — the useful exercise is mapping a subset onto your surface, your territory and your audience. Start with the catalogue, or go straight to license HTML5 games for web and portal use, or to buy Android games if the distribution is a store, a preload or a device fleet.

🧸 Licensing Branded Games for Campaigns, Portals and Events

Where a generic catalogue is not enough, branded content is a separate licensing route. Forestry Games works with branded IP and has brand partnerships including Disney, Nickelodeon, Cartoon Network and Warner Bros, and businesses can license branded game content through it for campaigns, portals, events and apps.

Branded licensing changes the format calculus in one specific way: brand approvals attach to builds, so shipping the same branded title as both an HTML5 build and an APK is two approval paths, not one. Settle the formats you need at the start of the scope conversation rather than adding one later. If a branded campaign, a white-label portal or an event activation is on your roadmap, ask for a licence scope that names every format and surface up front — and ask for a portal demo if the deliverable is a running site rather than a set of files.

✅ What to Do Before 31 August

If you already have licensed APKs live, this is a twenty-minute job worth doing today. Pull your published titles, check the target API level on each, and sort them into three piles: at or above API 35 and fine for now; below 35 and about to lose new-user visibility; and titles you cannot check because the licensor publishes them. That third pile is the one to raise on your next call — exposure with no control.

If you are still choosing a format, stop asking which one performs better and ask which maintenance clock your team can service. Web traffic that arrives once, breadth on day one, a carrier billing rail, or a campaign with a deadline — that is HTML5. A device fleet you control, offline play as the product, or store search as a discovery channel — that is APK, with a named party owing you an annual compliance build. Most operators end up needing both eventually. Browse the catalogue and ask for a licence scope that names both formats before you need the second one.