“Mobile Compatible” Is a Field the Licensor Fills In. Test It Before You Sign.

Mobile is 52% of web traffic, but "mobile compatible" in an HTML5 game licence catalogue is a self-declared field, not a test result. Check it yourself.

Every catalogue sheet I have been sent in the last two years has a column for it. Sometimes it is headed Mobile, sometimes Responsive, sometimes it is just a phone icon. It is always populated. And it is almost never wrong in the way you would expect, because the games do load on a phone. That is the trap. Loading is not playing, and the gap between the two is where a catalogue purchase quietly loses half its audience.

This survives due diligence because nobody's incentives point at catching it. The flag on the sheet came from the developer's own submission form, three parties upstream. Your reviewer opens four titles in a desktop browser, drags the window narrow, watches the canvas rescale, and ticks the box. Neither of those is a test.

📊 The Split That Makes This Commercial Rather Than Technical

Statcounter Global Stats put worldwide platform share for July 2026 at 52.57% mobile, 45.93% desktop and 1.5% tablet. Mobile crossed desktop years ago and has not gone back.

Two honest caveats before anyone quotes that at a supplier. First, it measures browsing across the whole web, not your portal. Game portals have their own mix and it varies enormously by territory, traffic source and genre — pull your own analytics before you argue with the global average. Second, if your portal's mobile share is unusually low, that may be a symptom rather than a fact about your audience. A catalogue that plays badly on phones produces a desktop-skewed audience, and then the skew gets used to justify not fixing the catalogue.

Statcounter publishes the same breakdown by country and region. If your licence covers territories where mobile share runs well above the world figure — and several do — run the numbers for those territories specifically, because that is where the exposure concentrates.

🧾 The Flag Gets Populated Upstream, and Nobody Re-Tests It

Follow the chain. A developer submits a build and fills in a metadata form. An aggregator or licensor ingests the build and the metadata together. A reseller licenses the catalogue on and passes the sheet through. At no point in that chain does anyone have both the incentive and the device to check.

It is worse than a trust problem, because "mobile compatible" has at least four meanings in active circulation:

• The game renders at a phone viewport without breaking layout.
• The game accepts touch input at all.
• The game was designed for touch input.
• The game was designed for touch input and reaches playable state acceptably on a mid-range phone over cellular.

Only the fourth is what you think you are buying. The first is what the column usually certifies.

🎮 Five Ways a Flagged Title Fails on an Actual Phone

The keyboard is load-bearing

Arrow keys, WASD, spacebar to jump. Everything else about the title works: it boots, it renders, the music plays, the menu buttons respond to taps. The player simply cannot move. This is the most common failure and the one automated checks never catch, because from the outside it looks like a working game.

Hover is a state your player cannot reach

Tooltips, aim previews, hit-area highlights, "hold the cursor here to see the trajectory." On a touchscreen there is no state between not-touching and tapping. MDN documents the CSS interaction media features that exist precisely for this: pointer resolves to fine or coarse, hover to hover or none. The subtlety is any-pointer and any-hover, which test every available input rather than the primary one. A touchscreen laptop matches pointer: fine and any-pointer: coarse at the same time, which is why user-agent sniffing and single-feature checks both give you the wrong answer on exactly the devices where it matters.

The game wants an orientation your page will not give it

Landscape-only titles are fine on a platform that manages orientation for them. CrazyGames lets a developer declare supported orientation at submission and enforces it site-side, so the game does not have to implement locking logic. Inside your own iframe, on your own domain, nothing enforces anything. Fullscreen is not the escape hatch either: caniuse puts global Fullscreen API support at 96.48% while recording Safari on iOS as only partial from version 12 through the current release. The gap in that 96% is concentrated on the device your landscape game most needs it on.

Touch targets sized for a cursor

The W3C's WCAG 2.2 Success Criterion 2.5.8, Target Size (Minimum), sets the pointer-target floor at 24 by 24 CSS pixels at Level AA, with specified exceptions. Games routinely ship UI chrome drawn inside the canvas at whatever size the artist chose, then scaled by a canvas transform, so the effective tap area on a 360-pixel-wide phone is smaller than anything you measured in a design file. Pause, mute and restart are the usual casualties, and they are the controls a frustrated player reaches for first.

It is too heavy to reach gameplay on a phone connection

CrazyGames' technical requirements are the most concrete public numbers anyone in web games has published on weight: a 250 MB total ceiling, a 1,500-file limit, and an initial download of 50 MB or less measured from load start to the first gameplay-start event, excluding menus. Then the line that matters here: "In order to be eligible for the mobile homepage, the initial download size can not exceed 20 MB."

That is one platform's bar for its own placement, not a law. But it is a published, specific number from an operator with 50 million players and every reason to get it right, and it is a far better working definition of mobile-ready weight than anything on a catalogue sheet.

🔍 Two Platforms Already Wrote Your QA Spec

The useful shortcut here is that the companies with the most to lose from a bad mobile session have published what they require, and you can borrow it for free.

CrazyGames states the input requirement plainly — "Game supports mouse, keyboard, and touch if mobile is supported" — and its gameplay requirements add that a game "should have intuitive controls on different types of devices," with text and images legible at devicePixelRatio: 1 across responsive 16:9 iframe sizes and mobile screens. It names 800×450 as a critical iframe size to test.

Poki's quality guidelines come at it from the design side. Poki wants games that are web-first, which it defines as "designed with the web as a primary platform, not just a mobile port," and it asks developers to support alternatives to keyboard input where they can: "mouse only input, drag steering, auto acceleration, or customizable keys."

Read the two together and the shared definition is input parity plus weight. Not "renders on a phone." If a title in your catalogue would not clear the published bar of the platforms your own portal competes with for the same players, the flag on your sheet is measuring something else.

🧪 A Twelve-Minute Test Per Title, on Real Hardware

Device emulation in browser devtools gives you the viewport and lies about everything else that matters: input latency, thermal throttling, memory pressure, and Safari's own behaviour. Buy one mid-range Android handset and one older iPhone. They will cost less than the first month of a catalogue licence.

1. Load it on cellular, not office wifi. Time how long until you can actually do something.
2. Play one complete round using only your thumbs. No keyboard, no mouse, no pinch-zoom, no rotating the phone to find a button.
3. Rotate the device mid-round. See whether the game survives it or resets.
4. Background the tab for thirty seconds and come back. Audio, state, and the render loop should all return.
5. Tap the smallest control you must use. Usually pause, mute or restart.
6. Play it once more in the other orientation.

Step 2 is pass/fail and non-negotiable. A title that fails step 2 is not mobile compatible at any price, and no amount of licensor explanation changes that. Failures at 3, 4 and 5 are usually cheap fixes for the original developer — which is only useful to you if your contract gives you a route to ask.

You are not testing a thousand titles by hand, and you do not need to. Take a stratified sample: every genre that appears on the sheet, the strongest few in each by whatever popularity signal you were given, plus a random draw from the tail where the neglected builds live. If the pass rate in your sample sits materially below what the sheet implies, you now have a number to negotiate with instead of an impression. What you must not do is extrapolate from the four titles the licensor demoed, or from four you picked because you liked them.

📝 Three Clauses That Put the Risk Where It Belongs

Testing before signature only helps if the contract carries the finding forward to the titles you did not test.

1. Warrant the flag, not the game. Something binary and testable: every title marked mobile compatible accepts touch as its sole input method for all core gameplay. Not "is optimised for mobile," which is an adjective and unenforceable.
2. Make the remedy replacement, not refund. Refund clauses get argued about and rarely invoked. A right to swap failing titles for equivalents at no cost gets used, because it is easy for both sides to say yes to. Define the window — 30 to 60 days from delivery is normal — and define equivalent: same genre, comparable popularity band, no reduction in title count.
3. Take an acceptance period before final payment. Even a short one changes the conversation, because it means the supplier finds out about failures while they still have a commercial reason to care.

🚫 Five Ways Buyers Get This Wrong

• Calling devtools device mode a device test. It validates layout. It cannot tell you whether the game is playable.
• Testing only the titles the licensor demoed. Those are the ones that work. That is why they are in the demo.
• Treating "responsive" as a synonym for mobile compatible. Responsive is a property of layout. Playable is a property of input.
• Assuming an on-screen control overlay can be bolted on later. Without the build's source, it usually cannot — and a licence granting distribution rights very often grants no modification rights at all.
• Buying on title count and genre mix, then discovering the mobile-playable subset is the catalogue you actually purchased. If 40% of a catalogue fails step 2, you bought a smaller catalogue at the original price.

🌲 Where This Fits With Forestry Games

Forestry Games has licensed HTML5 games and Android titles since 2017 and develops HTML5 games in-house, alongside a licensed catalogue of 1,049 games. The part worth taking from that is procedural rather than promotional: when you evaluate any licensor, including this one, ask for a device-tested subset instead of a column in a spreadsheet, and ask what happens contractually when a title fails on a phone. A licensor with in-house development can sometimes answer that with a fix rather than a swap, which is a materially different answer — and it is a fair question to put to every supplier on your shortlist before you get to pricing.

🧭 What to Do Before the Next Catalogue Sheet Lands

Do these in order, and do the first one this week regardless of whether you are buying anything.

• Pull your own device split for the last 90 days and compare it against the 52.57% global figure. Whichever way the gap runs, it tells you something.
• Run the twelve-minute protocol against ten titles already live on your portal. You will find out whether this is a purchasing problem or an inventory problem you already have.
• Write the protocol down as a one-page document and attach it to your next RFP, so suppliers know the bar before they quote.
• Put the warranty and the swap clause into the first draft you send, not the third. Clauses introduced late get traded away.

The single highest-value thing here is the cheapest: pick ten titles you are already paying for, hand a phone to someone who has never seen them, and watch. You will know within twenty minutes whether the column on your catalogue sheet means anything, and that answer is worth more than any number a supplier can put in a deck.