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!
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
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.
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!
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!!
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.
@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!
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.