Thank you for your reply. Let me clarify something I didn’t explain clearly earlier. When JSC is enabled with a relatively large allocated memory ranging from 2MB to 4MB, the usable memory available to our app becomes approximately 0.8GB (calculated as 1.8GB − 1GB occupied by JSC). When JSC is disabled, our app can utilize around 1.5GB of memory. Our application integrates multiple technologies including iOS native code, Flutter, Unity and Cocos, resulting in highly complex memory allocation behavior. The additional memory overhead introduced by JSC further aggravates our app’s memory pressure. This issue surfaced on iOS 26.4 and was not present on older OS versions. Is this a regression introduced by the new system release, and will it be fixed in future updates? Additionally, I would like to ask: Are there any approaches to limit the memory consumption of JSC? If we restrict JSC memory usage, will this have any impact on WKWebView? Our app needs to load web content and relies on WKWebView.

Thanks for your detailed analysis. First, to clarify our testing setup: we write and touch allocated memory after malloc, so the failures we encounter in production are not caused by pure untouched allocations exhausting virtual address space. We fully understand the distinction between virtual address space limits and physical memory constraints. On 3GB iOS devices, our app hits compound restrictions: linking JavaScriptCore expands the overall process virtual address space quota, yet JSC itself consumes nearly 1GB of that address space footprint. This large baseline reservation of JSC only becomes observable under Instruments memory profiling starting from iPadOS 26.4. Earlier OS releases did not expose this consumption in profiling tools. We also observed that this reserved size varies based on device physical RAM: it occupies roughly 1GB on 3GB devices, and expands to approximately 2GB on devices with larger memory capacity. We are continuing to complete verification on more hardware models. Without JSC linked, the app crashes at approximately 1.52GB memory consumption, which creates critical obstacles for core business workflows. Our project extensively performs 4MB and 8MB memory allocations. These allocation sizes fall into libmalloc’s high-fragmentation bucket, further lowering the effective crash threshold and worsening runtime stability. Unfortunately, we cannot remove JSC. Our core capabilities including JS bidirectional communication, resource rendering and dynamic business logic all depend on the JSC runtime. Even with JSC linked to unlock a higher virtual address limit, memory pressure remains severe on 3GB RAM hardware. A large group of users with these older devices continuously experience crashes, freezes, background Jetsam termination and loading failures. We have completed all feasible application-layer optimizations: adjusting allocation granularity, optimizing memory release paths and reducing resident memory. We have also evaluated building a custom allocator via bulk large allocations or low-level vm_allocate/mmap calls as you suggested. However, we recognize such improvements cannot fundamentally break through the hard system limits we have observed. Therefore we sincerely hope to obtain further official guidance: Tuning options for JavaScriptCore to cut its baseline virtual address reservation and runtime memory overhead; Recommended practices to mitigate libmalloc fragmentation for frequent 4MB/8MB allocations; Any available system-level memory scheduling advice for memory-heavy applications running on 3GB iOS devices.