Every Licensee Ships the Same Catalogue. Google Play Calls That “Repetitive Content.”

Wrapping a licensed HTML5 games portal into an Android app collides with three Google Play policies: webview spam, repetitive content, and minimum functionality. Two of them are aimed squarely at catalogue licensees, and the third decides your architecture before you write a line of code.

The request arrives in roughly the same shape every time. An operator has a working web portal, a licensed catalogue behind it, some traffic, and a board member who wants to know why there isn't an app. The engineering answer sounds trivial — the games are already HTML5, put a WebView around the site, ship it. That plan has been failing review for about two years now, and the reasons are worth understanding before you spend a sprint on it.

📜 Three Sentences in Play's Spam Policy, and Two Are About You

Google's Spam policy is short. The clause everybody quotes is the Webviews and Affiliate Spam one: "We don't allow apps whose primary purpose is to drive affiliate traffic to a website or provide a webview of a website without permission from the website owner or administrator."

Most operators read that, confirm they own the domain they're wrapping, and move on. Fair enough — if the portal is yours, the permission question is settled. But the clause directly beneath it is the one that actually applies to a licensed catalogue, and almost nobody quotes it: "We don't allow apps that merely provide the same experience as other apps already on Google Play."

Sit with that for a second. A non-exclusive catalogue licence exists precisely so that many operators can ship the same titles. That is the product. It is also, read literally, a description of the thing this policy prohibits. If eleven licensees wrap the same games behind eleven different logos, the eleventh submission is defending itself against a sentence written for exactly that situation.

The third relevant rule sits in the Functionality, Content, and User Experience policy, which prohibits "apps that are static without app-specific functionalities, for example, text only or PDF file apps" and "apps that crash, force close, freeze, or otherwise function abnormally." The second half of that matters more than it looks: an iframe-heavy portal on a mid-range device does freeze, and a reviewer on a test handset will find it faster than your QA did.

None of this is theoretical enforcement. In its 2025 ecosystem safety report, Google said it prevented more than 1.75 million policy-violating apps from being published and banned over 80,000 developer accounts — down from 158,000 the previous year, which Google attributes to verification and pre-review checks discouraging submissions before they happen. Every published app ran through more than 10,000 safety checks. The pipeline is not a formality.

🪟 A WebView and a TWA Are Not Two Words for One Thing

This distinction gets flattened in most internal discussions, and it shouldn't be, because it changes what your app can do with the games inside it.

Android System WebView

The classic route. A rendering component inside your app's process. Your native code controls navigation, can inject JavaScript, can read and write cookies and local storage, can intercept requests. Maximum control. It is also a separately updated system component that ships through Play independently of the OS version, so you cannot infer a device's WebView version from its Android version — which matters when a game needs a specific WebGL or audio behaviour.

Trusted Web Activity

Built on the Custom Tabs protocol. Per Chrome's documentation, the content runs fullscreen in the user's browser rather than in a WebView. Different engine, different update cadence, generally more current. And a hard boundary: "The host app doesn't have direct access to web content in a Trusted Web Activity or any other kind of web state, like cookies and localStorage."

That sentence quietly kills a lot of feature specs. Native leaderboard reading the game's saved progress out of local storage? Not available. Native analytics wrapper counting plays by watching the web layer? Not available. If you want native and web to share state in a TWA, they share it through your server or they don't share it.

There's also a failure mode worth designing around: if Digital Asset Links verification fails, the browser falls back to displaying your site as a Custom Tab. The app still works. It just has browser UI on top of it, which is a visible, shipped-to-users version of "this is a website in a box."

🔗 Digital Asset Links Asks a Question Your Licence Should Have Answered

TWA verification needs an assetlinks.json file served from /.well-known/ at the root of the domain, plus matching metadata in the app, signed with the right key. Signing key mismatches are the single most common cause of verification failure.

Root-of-domain control is the part that becomes a commercial question rather than a technical one. If your portal runs on your own domain, this is a ten-minute job. If a vendor hosts your white-label portal on their subdomain, you need them to publish a file pointing at your app's signing certificate — and to keep publishing it through every platform migration they do. Get that in the agreement. It is a two-line clause that prevents a launch-week outage.

💳 Sell Anything and the Architecture Is Chosen for You

Play requires digital goods and subscriptions sold inside a Play-distributed app to go through Play Billing. In a TWA, Chrome's Web on Android guidance is to implement two web APIs: the Digital Goods API to read your Play Console products and existing purchases, and the Payment Request API to run the transaction. Support landed in Chrome 101 and above on Android and ChromeOS.

The practical shape of this is a second billing integration you did not previously have. Your portal already has a payment processor for web subscribers. Now it also needs a Play path that only activates inside the app — detected at runtime by checking for getDigitalGoodsService on window, and falling back to your web checkout when it's absent, because the same pages still serve ordinary browsers. Two purchase flows, two SKU catalogues, one entitlement model that has to reconcile both. Google's own reference sample flags the obvious failure: product IDs in Play Console must match what your backend stores, and IDs cannot be renamed after creation.

Budget for this properly. It is usually the single largest line item in turning a subscription portal into an app, and it is invisible in any estimate that treats the job as "put a wrapper on the site."

One honest caveat: Play's billing rules have been under court-ordered change in the United States, and the position there has moved more than once. If the US is a material market for you, verify the current requirement directly rather than trusting any article, this one included.

📅 Whatever You Ship Already Has a Rebuild Date

From 31 August 2026, new apps and updates submitted to Play must target Android 16 (API level 36) or higher, per Play Console's target API level requirements. Existing apps need to target API 35 or above to stay available to new users on devices running a newer OS than the app targets. Developers can request an extension to 1 November 2026.

That deadline is twelve days out as this is written. The point is not the specific date — it's that a wrapper is not a build-once asset. If you also licensed a set of Android titles as separate APKs, every one of them sits on the same calendar as the wrapper. Ten APKs plus a portal app is eleven artefacts to rebuild annually, forever, and someone has to own that.

🧩 What Actually Makes It Not-a-Website

The test reviewers apply is not "did you add features." It is "can this app do something the browser tab cannot." For a games portal, a few things genuinely clear that bar:

• Real offline play. Package a subset of titles into the APK and serve them from a local origin so they run in airplane mode. This is the strongest signal available to you, and it's the one reviewers test directly — putting the device in airplane mode and seeing whether anything renders.
• A native download manager. Let players pick which games live on the device, show sizes and progress, handle eviction when storage runs low. Browsers cannot manage a game library this way.
• Play Games Services. Achievements, cloud saves, and sign-in are platform capability with no browser equivalent. For a catalogue of a thousand casual titles this is also a genuine retention feature, not just review armour.
• Gamepad and TV input. If you target Android TV, leanback navigation and controller mapping are substantial native work that no web build supplies.

And one that people over-weight: push notifications. Web push works on Android in the browser, so a native push implementation is a weaker differentiator than the pitch decks suggest. Apple has rejected apps whose native features merely mirrored what the mobile browser already did. Assume Play reviewers can make the same distinction.

🍎 Apple Asks the Same Question in Blunter Language

Section 4.2 of the App Store Review Guidelines: "Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store." And 4.2.2: "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links."

The clause that should worry portal vendors more is 4.2.6, which rejects apps "created from a commercialized template or app generation service … unless they are submitted directly by the provider of the app's content," and states plainly that "these services should not submit apps on behalf of their clients." Apple's permitted alternative is a single binary hosting all client content in an aggregated or picker model.

If your business is building white-label game apps for brands and telcos and submitting them under your own developer account, that is the guideline that decides whether the model works on iOS. It has been enforced against no-code app builders since well before games entered the picture. Either the client submits under their own account with their own content, or you consolidate into one binary — and consolidating usually contradicts the entire commercial premise of white-label.

🚫 Five Ways Operators Get the App Build Wrong

• Scoping it as a wrapper. The wrapper is a week. Offline packaging, a download manager, Play Billing, and Play Games Services are a quarter. The estimate that gets approved is almost always the first number.
• Checking licence scope after the build. Plenty of HTML5 licences grant web distribution on named domains and say nothing about native apps, or say nothing about packaging game assets into a binary. "Nothing about it" is not permission. Ask before, not after.
• Assuming brand titles come along. Licensed-character games frequently carry tighter platform restrictions than the rest of a catalogue, and a store listing is a different approval question than a web page. Confirm per title.
• Testing on the team's phones. Your reviewers will not be on flagships, and neither are the players you licensed a casual catalogue to reach. An iframe portal that freezes on a mid-range device is a functionality violation, not a performance nitpick.
• Shipping the same app as ten other licensees and expecting the differentiation to come from branding. The repetitive content clause is not about your logo. It is about the experience.

🎮 Where a Licensed Catalogue Fits

Forestry Games has licensed games since 2017 and runs a catalogue of 1,049 titles spanning HTML5 and Android, alongside in-house HTML5 development and branded IP work with partners including Disney, Nickelodeon, Cartoon Network and Warner Bros.

The transferable point is a due-diligence one, and it applies to any licensor. Before you plan an app, get written answers to three questions: does the licence cover native distribution as well as web; may game assets be packaged into an application binary for offline play; and are any titles in the bundle restricted to web-only. Where the answer to the second is no, an offline mode is off the table — and offline was your strongest argument that the app is more than a website. If you need deeper control than a licence gives, that is the conversation where source-code terms become relevant rather than a default upgrade.

🧭 What to Decide Before You Open Android Studio

Start with the honest version of the question: what will this app do that your mobile site does not? Write it down as a list. If the list is "notifications and an icon on the home screen," you do not have an app project — you have a PWA install prompt, and shipping that is a fraction of the cost with none of the review risk.

If the list holds up, pick the architecture from the constraints rather than the other way round. Need native code reading the game's client-side state? That forces WebView. Want the current browser engine and the least maintenance? TWA, and plan your state sharing server-side. Selling subscriptions in-app? Price the Play Billing work before committing to a date.

Then check the licence. It is the cheapest step in the whole sequence and the only one that can invalidate everything after it.