Skate 3 browser on a phone: what actually decides whether it runs

How the port decides your device is small

The Skate 3 browser port does not ask you. It checks the user agent for iPhone, iPad, iPod, Android or Mobile, and it has one workaround worth knowing about because it explains an oddity you may run into: recent iPadOS versions report themselves as a Macintosh.

So the Skate 3 browser port treats a Macintosh user agent with more than one touch point as an iPad. If you are on an iPad and wondering why a "desktop" browser is being handed touch controls and a memory-conscious preset, that is the code path you are on.

Touch controls are decided separately, from whether the device reports touch points at all and whether the primary pointer is coarse. That is why a touch-capable laptop can get the on-screen pad while still being treated as a full-size device for graphics.

What Mobile Mode changes, exactly

The Skate 3 browser port offers a lighter preset to phones and tablets the first time they arrive, rather than assuming. It describes the two options in its own words:

Mobile Mode — "Every map, the full game and the original Skate 3 screens, using far less memory: lighter graphics, no background downloads, and a warning before the big cities. Recommended on this device."

Full quality — "The original look. Needs more memory than most phone browsers allow; the browser may close the game on the big cities."

Behind that description are four concrete changes, and they are worth knowing because they tell you what you are trading away:

Every one of these stays adjustable afterwards in the graphics settings, so Mobile Mode is a starting point rather than a ceiling. If you want to find the limit of your phone, raise one setting at a time — raising all four at once tells you nothing about which one cost you the tab.

Pick your first world carefully

On a phone this is the decision that matters most, because it changes how much memory the session needs. The Skate 3 browser port's world list separates its small parks from its three city districts explicitly:

When you do try a city, the Skate 3 browser port does not leave you guessing: it shows a warning naming the world you are about to load, and says plainly that a large city may still be too much for a phone in Lite mode; the parks are safer. Treat that as the project telling you where its own limit is.

Why the tab closes itself

This is the number one mobile failure and it is not a bug in the Skate 3 browser port. Browsers cap how much memory a page may use, and a skating game with a city world in it can exceed that. Mobile browsers are stricter than desktop ones, and the port's comment in its client names WebKit specifically as the engine that closes a tab which grows too large.

What makes it feel abrupt is that it can happen after a download has finished — the data arrived, and then the rendering pushed the tab over the line. So "it downloaded fine and then vanished" is consistent with a memory limit rather than a broken download.

The fixes are all about reducing the peak: stay in Mobile Mode, load a park rather than a city, and close other tabs before you start. Repeatedly reloading the same large city is the one thing that will not help.

The 48 MB limit on mobile saves

Mobile also gets a smaller cache than desktop, and the reason is mechanical rather than arbitrary: writing a map to storage means holding a second copy of it in memory while it is written, which is precisely the thing a phone cannot afford.

So the client refuses to save anything past 48 MB in mobile mode. The practical consequence is worth planning around: on a phone, large city worlds are downloaded again on every visit, while small parks load from storage after the first time. If you want fast repeat sessions on mobile, choose one park and stay with it.

Touch controls, briefly

The on-screen pad feeds exactly the same virtual controller the keyboard does, so nothing about the game's input changes — you have simply swapped the hardware. The left stick steers and crouches; the right pad is the FlickIt stick and springs back when you lift your finger, which is what makes the pull-down-then-snap-up gesture work with a thumb.

One thing to get right early: a flick needs room for both halves of the gesture. Starting the pull at the edge of the right pad leaves nowhere to snap back to, so keep strokes centred. Details of every input, including pad and keyboard, are on the controls guide.