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.
Apple broke webassembly for large webassembly modules on iOS 13.0 and 13.1. I reported it and they’ve implemented a fix already (200807 – [JSC] WebAssembly BBQ should switch compile mode for size of modules). 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).
Thanks for linking to that URL kognito1, very good to be aware of this issue. There is unfortunately no way to measure how large a loaded up .wasm file will become in memory (it is hidden browser impl detail). It may be possible that attempting aggressive package and code stripping in a project may be enough to optimize out a necessary amount of code to keep it within that limit.
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.
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 :p).
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
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.
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 Unity WebGL Player - AngryBots WebGL Demo 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_1
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?
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.
@ This should be somehow testet and fixed.
or
@ Make your Webkit more tolerant again.
