State of Unity webgl on mobile

So it seems iOS is down for now: Webassembly no longer working on iOS 11.2.2

On android it seems to work just fine but at less than native resolution - what controls the resolution of the unity webgl content?

Android firefox does ask to be allowed to record audio though which is weird…

We recently made all our applications work with Android (and soon iOS 12.2!) and I’d say the general gotchas were:

  • Memory limits are obviously much tighter (lower end Android/2GB iOS devices can do about ~300MB or so on the heap before failing)
  • There’s no compressed texture support for Android (etc2) or iOS (pvr) with Unity (out of the box) so your textures will be ~4x the size (makes the previous point way worse)
  • Every phone/tablet almost always has some “retina like” screen and since Unity (again out of the box, but you can work around this) doesn’t understand dpi on webgl, you’ll get naive scaling by default (sometimes as high as 3x!)
  • There’s no “kosher way” to prevent a device from going to sleep on the web, so you’ll have to use workarounds like nosleep.js
  • A lot of our javascript callbacks were on mouse events, corresponding touch events had to be added
  • Wasm performance on iOS is great (basically desktop quality), but I’d only rate Android as good (might be slower than what you are accustomed to)
  • Instant page reloads are a killer; browsers can’t seem to gc the previous Unity content/div fast enough and mobile devices almost never have enough memory to handle this
  • using the OS provided virtual keyboards in a wasm/Unity context is actually really hard, so hard we just made our own virtual keyboard
  • This one is a bit specific, but we had to create this whole extra assetbundle variant build pipeline so that we could selectively load different texture assetbundles depending on platform (and still have it magically work)
  • There’s a lot buggy Android devices (and mobile gpu drivers) out there…

For the most part though, I’d say it kind of all just works if you keep art budgets/scope realistic. These are definitely exciting times! App stores’ days may be numbered!

10 Likes

Yes the non-native resolution just makes it look poor - how did you fix that?

Please work on mobile webgl Unity! - by default you see a poorly styled (tiny) warning message and then badly scaled content!!

You can change some Unity editor files so the patch is automatically included in each build.

1 Like

It seems that the wasm streaming option in 2019.1beta works well on both iOS and Android(Chrome).

Projects that couldn’t be cached now both loads faster and can be loaded from cache

The osx retina fix is not ideal for mobile on which you really just want to set the canvas to a suitable resolution and aspect ratio for the current device and orientation. I will have to try and modify the device-ratio solution to become a custom width/height one

Try with the Better Unity WebGL Template and see what that looks like.

Yeah our solution ended up being quite custom. A lot of coordination between the unity wasm module and the html/css surrounding it. That’s what I kind of meant in the other thread about Unity having no easy options. Now that I fully understand all the edge cases and interaction points (with html/css/etc.), it’s going to take Unity a lot of work to make some out of the box solution that “just works” for everyone’s use case. It may not even be possible/feasible.

3 Likes

Unity WebGL: Honestly, It basically doesn’t work well. On most of my tests on iPhone 8, games basically ran for about 10s and then completely crashed the browser. Some super-simple html games worked fine.

If you want to test webgl games on mobile, I wrote an article here!

Where?

2 Likes

Unity should hire someone from three.js and let him work on their WebGL export module. Right now it’s just aweful!! Doesn’t work on mobile and takes forever to load!!

2 Likes

I am amazed webgl from unity wont run on Android. Stunned… I have been tellign clients it’s possible, is this really 2021? Unbelievable.

1 Like

It will run on Android, but it requires engineering effort to optimize your assets to do so. It won’t run efficiently out of the box, but it can most definitely be done. Project Tiny may be one solution for you depending on your project requirements.

It does run. Change the pipeline to URP and it will run smooth.

Yes I noticed that it does work after the warning on some projects, other projects I get a javascript error. Will look into project tiny, thanks guys

It does run on both android and iOS. Loading times aren’t optimal and minimal file size is not that great, but it runs quite well. URP has better performance, but also a larger initial file size.
To see a live demo along with the code, take a look at GitHub - JohannesDeml/UnityWebGL-LoadingTest: Unity WebGL platform and version comparisons with a lot of nice extras

1 Like

Great work!

And you don’t need to use post build process. You already use WebGLTemplate, just add this code to the html file
https://gist.github.com/De-Panther/f08cb4902bd21ee403d579a12510be2c

1 Like

Nice solution as well! However I feel like removing code is always better than adding code to the build :slight_smile:

@JamesArndt1 we are limited by VRAM usage (which translates to RAM in WebGL as its all shared as you know) and wondering if swapping to URP is recommended for WebGL projects that are having memory issues? We do not crash, but safari shows the “using too much memory” warning and we really need to eliminate it but running out of things we can optimise. Currently using in built pipeline.

Anybody else here that knows if URP is better for memory please let me know!

1 Like

Summing up recent progress since @kognito1 's 2019 post above, and roadmap on this area:

  • memory usage and startup times should have gotten a little bit better starting from Unity 2020.1 with the new page loader templates. Be sure to have WebAssembly Streaming enabled, and have the web server also configured to enable it. We expect memory usage to get better again on Unity 2021.2, after a new compiler toolchain migration.
  • Unfortunately in general Chrome on Android is still a mess: there are still a small number of 32-bit new entry level Android devices being manufactured in 2021, and even on 64-bit devices, Chrome is still 32-bit process. This is the main reason why WebAssembly applications can rarely exceed 300MB on the Wasm heap size.
  • adding compressed texture support is now on the board, initially to add the different compressed texture formats, but that will require either doing multiple builds per each format type, or do multiple asset bundles one for each format type
  • high DPI support was completed (was it 2020.1, I forget), so mobile devices should get good native resolution. There was a range of versions where mobile devices would default to standard DPI, but that is now changed to default to high DPI also on mobile. On older Unity versions, check out the main generated index.html: If it has a line “config.devicePixelRatio = 1;”, remove it to get high DPI.
  • regarding page reloads causing content not being able to load: there were some bugs on Unity front (and apparently still is at least when Decompression Fallback is enabled), and there are known bugs on Safari, Chrome and Firefox fronts. Safari iOS 12.x had issues that it would not be able to run multiple wasm pages consecutively, fortunately that has been fixed. Cleanup seems to be difficult on the web, and mobile devices run into issues earlier than desktop devices.
  • adding virtual keyboard support is something that is on our task board as well. In the meanwhile, there was another thread on this forum that offered two excellent looking plugins, check them out!
  • finally on performance: we are tracking with Google some issues about entry level Android devices, where the GPUs are so weak that Chrome’s own WebGL compositor eats away most of the fillrate performance on the devices. There is a “constant overhead” that Chrome/WebGL brings, and that is squeezing Unity rendering performance down. (then again, I would not dare to claim Unity rendering performance to be 100% speed of light either)

One thing to be very aware are background music clips. Audio on the web is very memory usage heavy, because of limitations of Web Audio API. A good way to check out audio memory usage is with Firefox about:memory tab, which can show how much of memory is consumed by uncompressed audio data.

8 Likes