WebGL projects not loading after IOS13 update

Hey everyone,

First time poster here. We have been experiencing some issues with our webgl projects after updating to IOS13. The projects show the unity loading bar, but freezes during the last bit of the loading and remains stuck. On IOS12 it worked perfectly fine in both safari and react-native webviews. However after IOS13 it simply won't load in neither.

We have tried almost everything to figure out whats been causing it, but no luck so far. We are running latest 2019.2.6f1 build.

Much appreciated!

 

Apple broke webassembly for large webassembly modules on iOS 13.0 and 13.1. I reported it and they've implemented a fix already (https://bugs.webkit.org/show_bug.cgi?id=200807). My hope is 13.2 (or whatever the next iOS version contains the fix...the Safari Technical Preview 92 on desktop already contains it, so there should be some optimism).

 

Yes, this is a disaster but sort of par for course. That's why I always build an asm.js side by side and hard code only tested iOS platforms for WASM.

 

Thanks for the info. Will wait for the fix then

 

For those that want to play along at home: https://trac.webkit.org/browser/webkit/?order=date&desc=1#tags/

Any 608.2.x based webkit browser (Safari on iOS 13.0-13.1.1) will be broken. Any 608.3.x based webkit browser (Safari Technical Preview 92) has the short term fix (the fix referenced in the bug report above). Any 609.x based webkit browser has the long term fix (webassembly interpreter).

While we are obviously all anxious for the short term fix, I'm actually pretty excited for the long term fix. That should help out a lot with memory for webassembly.

 

I can confirm iOS 13.2 beta resolves the issue!!!

 

Unfortunately in our case it has shown to be partially resolved. it can work, but it can also fail in the same way as well. hopefully the long term fix is implemented into ios 13.2 before the release.

 

If you're refreshing the page over and over (and maybe even just once) you will receive the error (same thing happens in 12.x). Safari does not release/garbage collect compiled code on refresh. 13.2 has been stable for us in initial testing (or at least as stable as 12.x).

One thing to note is the short term fix is not a robust solution. It requires the webassembly binary to be at least 10MB (uncompressed...so after gzip/brotli decompression) in size for the old safari wasm compiler to "kick in". So if your binary is like 9MB, my bet is it would still crash on 13.2 (try adding and referencing useless modules ).

 

After a long investigation, I've solved it. So iOS 13 is still working with asm.js
So the workaround is to change in ProjectSettings.asset:
webGLLinkerTarget: 1 to webGLLinkerTarget: 0

0 => asm.js
1 => wasm (default)
2 => asm.js + wasm

also worth to change
webGLMemorySize: 16 -> in my case webGLMemorySize: 128
But you need to try what works best for you.
Sure because it is not wasm but asm.js - it will work slower on older iPhones and Android phones. But so far, I think it is the only solution for Unity 2019.2

 

Thanks for all the solutions guys. We have tried the 13.2 beta and have noticed a substantial increase in loading times on our devices (some projects up to 5x), which is crazy. I guess we'll have to wait for the long-term solution and see how that goes. On android everything works as usual.

It also makes us reconsider this approach from a business point of view. Its a nightmare to think you'd have to tell your users not to update because it would render key features of your app useless.

Still very hyped about the potential and where it will take us, but clearly we are still far away of stable use of these type of web(view) features.

 

Have you tried outside a webview (we don't use webviews so I can't comment on any regressions there)? I find this a bit odd as the workaround in 13.2 is literally "if iOS and large wasm binary, use the old wasm compiler that was used in 12.x". It should be more or less the exact same behavior as 12.x. We have noticed no such loading regressions for 13.2.

 

How would you recommend approaching this outside a webview. We are developing in React Native, the only logical course was the webview. We have done multiple tests and somehow the loading time has increased. On our android devices the loading time is still the same, so the difference between the two are very apparent now (IOS taking much longer to load than the Android devices, which used to be around the same).

We haven't really been able to explain either, but it definitely is an IOS 13.2 beta issue. We will definitely conduct some more tests and see if we can somehow revert on of our test-devices back to IOS 12 and do side by side comparison.

Appreciate the reply Kognito

 

Hi together,
Are there any news?
We are also on the business point of view.
We also told our clients that they should not update from 12.x to 13.x . But thats not a solution.

In addition https://beta.unity3d.com/jonas/AngryBots/ is working on 13.x .
I know it is older.
But this application uses far more memory than ours.
Can not be something changed today in Unity so that it works again like in the demo or will be more tolerant towards aggresive Ram Management from Apple.

 

Hi @d_grass
As you said "We also told our clients that they should not update from 12.x to 13.x" => It not a solution because I think that clients will always use the last version.
Have you tried iOS version 13.2?

 

@nbkhanhdhgd

Yes we tried 13.2 and it is not working.
On 12.2 it is working fine.

 

Did they fixed it on 13.3?

 

I tried wasm with 13.3 and it's still not working correctly. So I forced to use asm for 13.x and wasm for 12.7-13

 

How big (file size) is your binary?

 

Somehow the problem is related to the Physics-Package.
If you reach some project complexity the Physics-Package will lead to the problem on iOS and the RAM management with WebGL.
We have disabled the Physics-Package in the PackageManager -> Built-in Packages and implemented some workarounds for Raycasts and other dependencies. Now it is working on iOS 13.
It is not a problem with file sizes or memory usage size. More how much memory in which time is requested. And the Physics-Package is somehow related to this.

@Unity This should be somehow testet and fixed.
or
@Apple Make your Webkit more tolerant again.

 

@d_grass that sounds strange but not impossible. Just curious, how large is your binary(wasm) file without any compression and without the Physics package. Another question: how did you manage to implement workarounds for the heavy usage of RaycastHits and Colliders in other built-in packages like ugui?

 

Physics is huge (we don't use it). I think it increases our binary by like 70% or something crazy. The "problem" is 100% memory usage related though. The browser will use (a lot) of memory when compiling a wasm binary. On iOS our "problem" is the compiler can easily run out of memory in practice. Adding physics (and a massive amount of code for the compiler to parse, process, and optimize) significantly makes this a larger challenge. However...some good news on the horizon: https://webkit.org/blog/9672/release-notes-for-safari-technology-preview-97/. The long awaited webassembly interpreter has finally landed in webkit. Our compiler woes may become significantly easier in the near future.

Btw, you do not need to use physics for ugui (well Unity had a regression in 2019.2, but versions before and after do not require physics). I *highly* recommend removing physics if you can.

 

I see... Lucky us, we're using 2019.2 as our current stable version . But I will give it a try with an upgrade to 2019.3 and remove the Physics package. Although we actually use the Colliders and RaycastHits a lot and to implement this ourselves would take some significant effort, I think. Did someone else try this?

 

Can you contact me about the resources in a store?(drag number https://assetstore.unity.com/packages/templates/packs/drag-number-151083 ) email : da625125312@gmail.com
Much appreciated!

 

@bogdan-serbanescu We developed a GraphicsRaycaster which checks against faces of a mesh and not colliders.
It does take more performance but we use it for simple clicking of objects which is not done in every frame.

Our build size is now 51MB and with Physics-Package it was 63MB. But i dont know anymore what it has taken on memory during runtime.

 

Hey just wanted to share some great news, I did some experiments testing out current Safari (no wasm interpreter) vs Safari TP (wasm interpreter) and compared the wasm compiler memory usage using our Unity app:

Current Safari - 73.1MB
Safari TP - 21.8MB

For reference, arm64 (iOS) on webkit/Safari sets a hard limit of 128MB of memory for the compiler (it's 1GB on x64 fwiw). So you can see even with a Unity binary of ~11MB we are pretty close to the limit (and why a simple page refresh on iOS often causes it to crash...if memory isn't GC'd fast enough, two instances easily blows through the cap). I'd like to note obviously I ran this test on a desktop (x64) so the results will not be exactly the same as arm64, but I'd be shocked if we didn't see a similar drastic reduction.

I'm betting iOS 14 will significantly improve our situation with Unity webgl!

 

Hey Guys, I am having a same problem with my project. I was not able to run my build on iOS 13 versions. Now I have removed the physics package from my project now i am able to run my build on iPhone 11 but not in older versions like iPhone 6 and iPhone 6 plus. Size of my "Build.data.unityweb" file is around 25 MB. I there anything i can try to make it work on older iPhones?

 

How did you profile specifically the wasm compiler memory? I don't see anything specific in the Timelines tab from Safari tools. Or, are there any APIs for that?

 

In the mac terminal run: "vmmap [$PID of safari process]" (you can get the PID from the activity monitor). From there look for the category "JS JIT generated code". The value of "DIRTY SIZE" will tell you how much memory the webkit compiler is currently using.

 

I am having a really tough time with unity 2019.3 and iOS 13.3 in webassembly(ASM too). Would anyone be willing to share their build stats for projects that successfully run on iOS? Here are mine and I am getting an out of memory exception on iOS Safari:


Build Report
Uncompressed usage by category (Percentages based on user generated assets only):
Textures 12.2 mb 44.4%
Meshes 0.0 kb 0.0%
Animations 0.0 kb 0.0%
Sounds 0.0 kb 0.0%
Shaders 104.8 kb 0.4%
Other Assets 232.5 kb 0.8%
Levels 9.3 kb 0.0%
Scripts 1.6 mb 5.8%
Included DLLs 13.3 mb 48.5%
File headers 28.6 kb 0.1%
Total User Assets 27.4 mb 100.0%
Complete build size 49.4 mb

 

Well "good news, bad news" time on iOS 13.4 beta:

Bad news: They broke memory growth in 13.4 (already reported and fixed https://bugs.webkit.org/show_bug.cgi?id=207727 ... we'll see if it makes it in 13.4 final). I can confirm though disabling memory growth and setting a high static value (like the asm.js days) functions fine (PlayerSettings.WebGL.emscriptenArgs = " -s ALLOW_MEMORY_GROWTH=0 -s TOTAL_MEMORY=256MB".

Good (fantastic?) news: The reason memory growth is broken is because they finally implemented the interpreter!!! And guess what? Works GREAT!!! For all of you that wish you could reload/refresh the page over and over again, your prayers have been answered (I reloaded the page 10 times and our wasm app loaded every time...previously we'd be lucky if one page reload would work)! AND the loading times are improved too!

If they fix memory growth in 13.4 final, this will easily be a game changing release for us (and maybe even without memory growth!). And judging by the commit logs, webgl2 should be landing in webkit relatively soon (do I dare say by iOS 14?). 2020 is shaping up to be a great year for unity webgl!

 

@kognito1 That's awesome news! I'm a bit concerned about the memory growth thing. If they broke it, does that mean that we won't be able to grow memory in game or does it refer to the WASM compiler memory only?

 

i still cant to get the webgl working on any of my IOS mobile device . I tried with mac book / android phones / windows and etc works fine. but as for IOS mobile device the loading stuck at 90% even if i'm using Safari browser / chrome on Iphone X .. anyone have any updates or solution on this ?

 

The problem is generally not enough RAM on Apples mobile devices, and it is hard to patch this problem with software solutions. Apple are supposedly working on a fix, but I have my doubts they will make put much resources on this particular problem to make it work well as they do not seem to like advanced web content anyway but rather want to focus on their app store.

I think Unity is basically too heavy, and to make this kind of content work it is better to go for a more native approach using WebGL 1 and Javascript through an API such as Three.js. Then you will have a lot more detailed control of how system resources are being used, and the content will load much faster too.

 

13.4 beta 4 resolves the issue with memory growth! It's shaping up to be a great release. I highly recommend you guys download the beta and give it a try.

 

I confirm that. My WebAssembly build finally works in Safari since iOS 13.4 (March 24 update).

 

one question guys , based on recent updates.
are most recent iphones now able to run a 200-250MB wasm build ?

 

Anyone has idea about this?