In fact, we tried.
As for the problem we encountered ( iOS Safari ) , limited memory and reload issue still exists. ( compared 2022.3 and Unity 6 )
In fact, we tried.
As for the problem we encountered ( iOS Safari ) , limited memory and reload issue still exists. ( compared 2022.3 and Unity 6 )
We are facing the same issue. We built a WebGL version with Unity 6, and the game works fine on Android, but it constantly crashes and restarts on iOS. It seems to be a memory issue on iOS, because with a 2GB memory budget on Android, thereās never a problem, but on iOS, the 2GB memory fills up quickly, and the browser restarts the app.
You can be lucky it even starts.
On iOS browser tabs get killed at around 500 MiB on 2 GiB devices according to frequent user reports. Unless this has changed in the recent iOS updates and/or recent Unity versions.
Coming back at this I noticed it hasnāt been answered yet. This behaviour is documented in the WebGL Memory page. The recommendation is:
For mobile browsers [ā¦] configure the Initial Memory Size to the typical heap usage of the application.
Ideally you do want to allocate the maximum memory the app is going to use up front, or youāre much more likely to see such crashes (page reloads).
when memory increase,like from 256M to 288M,unity just make a new buffer of 288M first, and then copy buffer of 256M to bufffer of 288M.Itāll needs 256M+288M memoryć
Some great news:
I just updated to iOS 18.2 on my iPhone and I havenāt had any memory related issues in Safari anymore I was able to use up to 4 GB of memory.
So most likely the fix for this Safari bug landed: 269937 ā MegaBug: WASM memory, SAB and Gigacage fragmentation, causes unpredictable wasm memory allocation
in Unity 6000? or does it apply generally to all Unity webgl 2.0 builds? (our game still crashes at the ~500MB ram on Unity 2022.3)
It should work on all Unity builds. Unity 6.0 and later have a limit of 4 GB and older versions 2 GB.
If you run into a crash with iOS 18.2 still than it is probably a different bug.
Nice, I did a quick check on my iPhone SE 2020 with iOS 18.2 and I can get to ~1600 MB without the page crashing (both Unity 2022.3 & Unity 6000.0)
Builds used:
In the newer builds there is a cheat that you can run in the html console called runUnityCommand("AllocateByteArrayMemory", int mb);
, run it with e.g. runUnityCommand("AllocateByteArrayMemory", 500);
to allocate a 500MB byte array (that stays referenced so it is not GC collected).
Not sure how youāre managing this but if I allocate a starting heap size of 2GB my later model iPhone SE mostly crashes straight away when it tries to load the asset bundle 3D scene from UnityCache. With a 512MB starting size itās able to load the scene but will crash once I load in a few 4096x2048 images (maybe 10-15 compressed in GPU memory).
The new iPad Mini can get about 55 of the same images, suggests to me that thereās still a Safari limitation thatās perhaps dependant on the amount of onboard RAM the iOS device has.
Anyway, for me the issue is not fixed
True. The iOS watchdog will kill browser tabs that consume too much memory for its liking. That limit is by and large still somewhere around 500 MB according to user reports. And you just provided another confirmation (launches with 512 MB, crashes the moment you request even more memory).
2 GB web memory usage on mobile devices is absurd to say the least. Youād have to wait another 10 years maybe before you can do that.
Congrats! This is a good report!
I have tried it on my end with iOS 18.3 and I can confirm that it works up to 4GB on a recent iPhone !
It now also works with web apps that previously did not work at all. I am very impressed!
I look forward to developing rich web/mobile content with this update
I am able to allocate 4GB of memory on the iPhone SE2, which should only have 3GB of memory, but is this because I am using virtual memory?
I have also tested our software with iOS 18.3 on my iPhone 12 with 4GB of RAM. I have tested it for several minutes and so far it hasnāt crashed. Normally it would crash within a minute of use.
This is great news, hopefully this means we can fully support mobile devices from this point forward!
Thanks @CodeSmile I agree that what weāre trying to do is pushing the boundaries. Other platforms can handle quite a bit until it reaches the physical device limitations but iOS seems to be playing it safe from what Iāve experienced