Hello 
I noticed recently one of our devices was crashing quite a bit, due to memory, when i check in that device, i saw that the Gigacage stuff for IOS Webview did allocate 1Go of memory, which is ■■■■ big already, but more concerning, that allocation did stay, even after the webview was closed / destroyed, we have some modifications of webview in the engine, is it something that you know of, or maybe our internal modifications keeps that stuff alive for some reason ? Also, do you know if there is a way to prevent the webview of usage that 1Go of memory, or is it tied to the ios browser ?
[Attachment Removed]
Steps to Reproduce[Attachment Removed]
Forgot to mention we did get around this issue for now by using the extended memories options of IOS, but that would be great if there is a way to prevent that monstruous allocation alltogether
[Attachment Removed]
Hi Alex,
Do you have a repro project or usage pattern that recreates this memory usage scenario?
Best regards.
[Attachment Removed]
I suspect this is something quite recent ios side when we use webkit, but we observed it on an ipad9, running ios 26, just using the webview (and maybe load a webpage) and a mem profling in xcode will show the allocation, that did actually cause our app to crash quite a bit lately, mostly on ipad9 devices, but that may be innacurate regarding the usage ratio, i’m not sure why the Gigacage allocation is not going away after we close the webview tho, but we have some modifications in intern around the webview, so this might be a reason why
[Attachment Removed]
oh also to note, the device was in developer mode, but seeing the number of crash we observe, i wouldn’t expect it to be part of the repro
[Attachment Removed]
Hi Alex,
I wouldn’t expect the device being in developer to be a major contributor to the crash. Are you spawning the webview via a WebBrowserWidget or is this a custom UIWebView integration?
Best regards.
[Attachment Removed]
We are using the WebBrowserWidget, we use IPC as well, is that something that you never experienced ? even with recents os versions ?
[Attachment Removed]
Hi Alex,
Are you seeing this behaviour across devices running iOS 16 or just the iPad 9th generation mentioned above?
Best regards.
[Attachment Removed]
I didn’t check other devices for now, but i observed it specifically on that device, running iOS 26 tho, not sure this behavior was affecting other devices, but i will guess so, at least an Iphone SE 2 (or 3) was having issues as well, that got resolved with the extended virtual memory
[Attachment Removed]
Hi Alex,
It may be worth integrating the following WebKit related leak changes:
- CL 44665440 (2025/08) — “fixing WKWebView-related memory leaks in ApplePlatformWebBrowser” (the removeAllScriptMessageHandlers / removeAllUserScripts cleanup)
- CL 44129706 (2025/07) — iOS web browser Obj-C wrapper released on shutdown
- CL 44076742 (2025/07) — “Fix some memory leaks in the iOS web browser”
And see if that clears up the Gigacage allocations.
Best regards.
[Attachment Removed]
Part of this is remembering stuff you did fix previously following another post of mine ^^ but they are already integrated sadly, we are running engine 5.7, i’m not sure why the Gigacage memory allocation would be leaking to be honest, if that will be an implementation bug or an apple issue, but the simple fact that the webview could allocate that 1Go of virtual memory and never release it is a concern, and something you learn the hard way when you get a crash feast ^^ i didn’t look if other devices / others operating system versions was having the same issue, but on the one that have this issue, if that’s tie to an os version or devices, i think we should consider forcing the extended virtual memory on theses, as it can easily lead to crash (in the best world, that allocation, even if big, would go away when the webview is down and for most that will be fine tho), but i have a question, are you able to detect the same issue on your side on any device / ios version ? This could be as well the resulting of some custom stuff we integrated in our engine, and if so that would be more a me-issue that yours
[Attachment Removed]
Hi Alex,
We’d be happy to look at it closer on local devices. Are you in a position to provide a small repro project that exhibits the issue on your end?
Best regards.
[Attachment Removed]