An iPhone Will Not Rotate for Your Game. Make Orientation a Catalogue Filter Before You License HTML5 Games.

Check orientation before you license HTML5 games. Safari on iOS has never shipped screen-orientation lock, so a landscape-only title cannot rotate a phone. That is a catalogue-selection decision, not a bug you get to fix once the batch has landed.

Every buyer runs the same demo. Laptop, licensor's showcase page, twenty titles clicked through in half an hour, a thumbs-up on the batch. Then the catalogue goes live on a real portal and the mobile session length collapses, and nobody can say why, because on desktop everything still looks fine.

A large share of the time the answer is geometry. The game wants one shape, the player is holding another, and the piece of software that used to reconcile those two things was never part of what you licensed.

📱 Nothing Inside the Build Can Rotate an iPhone

The web has an API for this. A game calls screen.orientation.lock('landscape') and the browser turns the display. It works, on some browsers.

Checked in September 2026, caniuse's support table for ScreenOrientation.lock shows the method unsupported in every version of Safari on iOS through 26.6, and unsupported in Safari on macOS as well. It is supported in Chrome for Android, Samsung Internet and Firefox for Android. The headline global figure on that page is roughly 81%, which flatters the situation badly: much of that percentage is desktop browsers, and MDN's own documentation notes that "typically orientation locking is only enabled on mobile devices, and when the browser context is full screen." A support number counting machines where the call does nothing is not a support number you can plan against.

Size the gap with traffic rather than with feelings. StatCounter's August 2026 figures put iOS at 32.36% of worldwide mobile operating system share against Android's 67.61%, and put mobile at 49.36% of all platform traffic against desktop's 49.11%. Round it: a third of the mobile half of the internet runs a browser that will not rotate anything on your instruction.

Which leaves two honest options for those players. Ship titles that are playable in the orientation the phone is already in, or draw a "please rotate your device" overlay and accept that some proportion of players will close the tab instead. There is no third option that a licensed build can execute on its own.

🎛️ The Portal Supplied the Rotate Prompt. Your Site Does Not.

Here is the part that catches experienced buyers. Most HTML5 titles in circulation were built to be published on the big web games portals, and those portals do the orientation work themselves.

CrazyGames' technical requirements say it in one line: CrazyGames handles orientation locking, and developers do not need to implement it. Portrait games are accepted there, with black bars or a background image filling the sides. Poki's published requirements take the same shape from the other direction — on mobile, cover the full screen in portrait or landscape, or both, and scale proportionally to 640×360, 836×470 or 1031×580, which is a 16:9 instruction with three stops on it.

So a title can satisfy a major portal's mobile requirements while containing no orientation handling whatsoever. The portal's player frame carried it. When you license that same build for your own site, you get the game and not the frame.

What the frame was doing, and what your wrapper now has to do:

• Deciding when to show a rotate prompt, and in which titles — which requires per-title orientation metadata you have to be given, not guess.
• Letterboxing a portrait game on a landscape screen and the reverse, with a background that does not look like a mistake.
• Fullscreen, which on iOS is its own problem: caniuse lists the Fullscreen API at about 97% globally but marks Safari on iOS as partial support across every version from 12 to 26.6, and MDN's note above means the orientation lock you wanted was gated behind fullscreen anyway.
• Safe-area padding, so the pause button is not under a camera cutout.
• Sizing the canvas and re-sizing it when the browser chrome moves.

None of that is difficult. All of it is a build you have to specify, and none of it is included in the phrase "1,000 mobile-ready titles."

📐 100vh Was Never the Height of the Screen

Mobile browsers grow and shrink their toolbars as the player scrolls. The classic vh unit resolves against the largest possible viewport — address bar hidden — so a canvas sized at 100vh is taller than the screen the moment the address bar is visible, and the bottom of the game sits behind browser chrome. The small, large and dynamic viewport units (svh, lvh, dvh) exist to fix exactly this, and have shipped across Chrome, Safari and Firefox since 2022.

The catch for a licensee is familiar: you cannot patch the build. If a licensed game's internal CSS uses 100vh, that is what it uses. Your leverage is one level up. Do not hand the iframe a percentage of a moving box — compute a pixel height in your wrapper, set it explicitly, and re-set it on resize. A wrapper that measures the real viewport can make a badly-sized build behave; a wrapper that passes percentages downward inherits every mistake in the catalogue.

Test the rotation, not the orientation

Many builds read the screen size once, at boot, and never again. That build survives a device held in one orientation for the whole session and falls over when the player rotates mid-game: the canvas keeps its old dimensions, or the game reloads and the player's progress is gone. Rotating before you press play tells you nothing. Rotate at level three.

🕳️ Landscape Is Where the Cutout Eats the Playfield

Apple's own guidance for notched devices, published on the WebKit blog, introduced viewport-fit=cover and the env(safe-area-inset-*) variables. The detail that matters for games: in portrait the reserved space is mostly top and bottom, and in landscape it moves to the left and right edges — which is precisely where a mobile game puts its thumbs, its joystick and its jump button.

The viewport meta tag belongs to your page, not to the licensed game inside the frame. So the inset decision is yours, it is made once in the wrapper, and it needs to be made against real hardware. Simulators are not reliable for this. Borrow a phone with a cutout and play a landscape title for two minutes with your actual thumbs.

🤖 On Android, Your Orientation Lock Is Now Advisory

The APK side of this changed, and the change is dated. Per Android's developer documentation, for apps targeting Android 16 (API 36) and higher, orientation, resizability and aspect-ratio restrictions are ignored on large-screen displays — smallest width around 600dp, which covers large tablets and unfolded foldables. The ignored list is specific: screenOrientation, setRequestedOrientation(), resizeableActivity, minAspectRatio and maxAspectRatio.

Games are excluded from this — but the exclusion is applied "based on the android:appCategory flag." That is a manifest value somebody has to have set. It is not inferred from the fact that the app is obviously a game.

Two more dates. Android 17 removes the temporary developer opt-out that Android 16 provided, so the escape hatch closes. And per the Android Developers Blog in February 2026, Google Play will require new apps and updates to target API level 37 from August 2027, which makes the behaviour mandatory for anything still being updated in the store.

For anyone about to buy Android games or sign an APK game licensing deal, that produces three questions worth asking before the batch arrives, not after: does every APK in the catalogue declare appCategory as a game; who updates the manifests and re-signs the builds when the target API level moves; and does the licence oblige the licensor to do it, or does that quietly become your job the first time Play changes a requirement.

🧪 The Orientation Test, Run in an Hour

Pick ten titles you are seriously considering. Use three devices: an iPhone with a camera cutout, a mid-range Android phone, and any tablet. For each title:

1. Open it holding the phone in portrait. Note exactly what happens — plays, letterboxes, prompts to rotate, or renders unusably small.
2. Turn on the device's own rotation lock and repeat. This is how a large number of real people hold their phones all day.
3. Play to the point of real input, then rotate mid-session. Watch for a reload, a frozen canvas, or lost progress.
4. Scroll so the browser toolbar collapses and expands. Does the bottom of the playfield disappear?
5. In landscape on the notched iPhone, check whether any control sits under the cutout or the home indicator.
6. Open the same title on the tablet. A 16:9 build on a 4:3 screen either letterboxes tidily or stretches badly, and you want to know which.
7. Reload mid-game. Some builds recover, most do not — that is a separate finding worth writing down.
8. Record one field per title: portrait, landscape, or both. That column is the filter you will use for the rest of the deal.

An hour of this on ten titles predicts the behaviour of the batch better than any spreadsheet the licensor sends you — and it turns "mobile compatible" from a claim into a measurement.

🚫 Five Ways Buyers Get This Wrong

• Trusting the "mobile" column. It is a field somebody typed. Test the ten titles that will carry most of your traffic.
• Testing only in desktop device emulation. Browser devtools will not reproduce rotation lock, safe-area insets, collapsing toolbars, or how a two-year-old Android phone actually renders a canvas.
• Reaching for the CSS rotate hack. Rotating the whole page 90 degrees with a transform is a well-worn shortcut and it breaks touch coordinates, input fields and the on-screen keyboard. It looks fixed in a screenshot and fails in a hand.
• Assuming a fullscreen button rescues it. On iOS the Fullscreen API is only partially supported, and orientation locking was gated behind fullscreen to begin with.
• Shipping a rotate overlay into a portrait-first market. If your traffic is one-handed commuting or a carrier portal opened from an SMS, an instruction to turn the phone sideways is a bounce, not a UX pattern.

📋 Questions to Put to a Licensor Before You Sign

• Do you supply per-title orientation metadata — portrait, landscape, or both — as structured data I can filter on?
• Which titles were built for portal player frames, and do those builds contain any orientation handling of their own?
• Does the delivery include a player wrapper that handles letterboxing, fullscreen and safe areas, or am I building that?
• How do the builds behave when the viewport changes mid-session — resize, or reload?
• For APK titles: is appCategory declared as a game in every manifest, and who owns manifest and target-API updates over the licence term?
• When a browser change breaks rendering in a title, who fixes it, and inside what window?
• Can I see the same title on my own hardware before it is counted in the batch?

🎯 What You Get When You License HTML5 Games From a Direct Licensor

This is where a direct licensor earns its place over a file handover. Forestry Games has operated since 2017 and licenses a catalogue of 1,049 titles spanning HTML5 and Android APK builds, with games also published on Google Play and the App Store, and develops HTML5 games in house. That combination matters here for a practical reason: when orientation, sizing or device behaviour needs to change, an in-house development capability is the difference between a fix and an apology.

A licence conversation covers HTML5 builds and APK builds together rather than as two separate procurements, with branding, hosting options and source where applicable, plus white-label portal delivery if you would rather not build the player wrapper yourself. Catalogue depth is what makes an orientation filter affordable — cutting every landscape-only title from a shortlist of forty leaves you nothing, and cutting them from a thousand still leaves a portal. You can license HTML5 games filtered to the shape your audience actually holds, or browse the catalogue and ask for a scope against your device mix.

🧸 Licensing Branded Games for Campaigns, Portals and Events

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 Forestry Games for campaigns, portals, events and apps. Orientation deserves more attention on branded work, not less: a campaign game usually arrives through a QR code or a social link, which means a phone held in one hand, in portrait, in whatever browser that platform opens.

If that is your route to market, decide the orientation before the creative is approved rather than after. The practical next step is to ask for a licence scope against your placement — APK game licensing for a store or preload play, HTML5 for web and campaign placements, or a portal demo if you want to see the wrapper doing the work.

✅ Do the Rotate Test Before the Next Batch

Orientation is unusual among catalogue problems because it is cheap to detect and impossible to fix later. An hour with three devices and ten titles gives you a column of data — portrait, landscape, both — that survives the whole deal: it decides which titles reach your homepage, what your wrapper has to do, and which markets you can serve on the traffic you actually have.

Do it before signature, not after go-live. Then ask your licensor for the same field across the full catalogue, and treat a licensor who cannot supply it as having told you something useful about the rest of the metadata.