iPadOS 26.4+ significantly reduced per-app memory limit from 6GB to 3GB on 8GB iPad, breaking memory-intensive apps

You’ve written your post like a bug report, which suggests you’re in the wrong place. If you want Apple to take action here, I recommend that you file a bug about this. Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

We're seeing the same thing, but with additional nuances. I've filed a bug report FB22883960. The strange thing here is that os_proc_available_memory() shows there's plenty to take, but the app still crashes upon reaching a reduced limit. Moreover, I think, the system is not fully aware of the lowered limit, or there is sort of a bug with the limit itself, as if it had been lowered unintentionally.

Are you running out of virtual or physical memory? Because the symptoms you’ve described suggest that you’re hitting the virtual limit. Kevin has been talking to a different developer about that subtlety in this thread.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

We track consumed memory level got from TASK_VM_INFO.phys_footprint. The app crashes at ~1.26GB on iPads with 3GB of RAM. At the same time os_proc_available_memory() shows there's still about 580MB available memory. Our apps are Unity-based games, so JavaScriptCore is definitely not involved. Moreover, we see crashes only on iPadOS versions 26.4+. On earlier versions (e.g. iPadOS 18.7) our games don't crash or crash much less frequently at around 1.8GB consumed memory.

Is this an actual crash? Or are you being jetsammed?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I'm not sure if I can really distinct the event types by the log report (.ips) now due to regular log format changes... From my POV, it doesn't look like a jetsam event. It does not have anything from the documentation page you've mentioned. On the other hand the log we have doesn't look like a regular crash report either. It does contain the following though:

"exception" : {"codes":"0x0000000000000001, 0x00000000000000c0","rawCodes":[1,192],"type":"EXC_BAD_ACCESS","signal":"SIGSEGV","subtype":"KERN_INVALID_ADDRESS at 0x00000000000000c0"},
  "termination" : {"flags":0,"code":11,"namespace":"SIGNAL","indicator":"Segmentation fault: 11","byProc":"exc handler","byPid":599},
  "ktriageinfo" : "VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter\nVM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter\nVM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter\nVM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter\nVM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter\n",
  "vmregioninfo" : "0xc0 is not in any region....

Also, I've attached a pair of such logs to my FB mentioned earlier.

What you have there is a JSON crash report. The simplest way to get a human readable crash report from that is to save it to disk with the .ips extension and then Quick Look it in the Finder.

Having said that, just that small snippet is enough to see that this isn’t a jetsam event:

"termination" : {…,"code":11,"namespace":"SIGNAL","indicator":"Segmentation fault: 11",…},

Your app crashed due a memory exception. Now, that could be caused by a memory allocation failure, but you need some evidence before coming to that conclusion. I recommend that you start at the top with Diagnosing issues using crash reports and device logs.

Or if you want to post the crash report here, I’d be happy to take a look. Posting it is a bit tricky, and see Posting a Crash Report for specific advice on how to do that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

We have lots of different crashes that have callstacks of the crashing thread ending with memory allocation routines. They may be or may be not Unity-specific. We even do have JSC-related crashlog as I see it now (I believe it is Ads-related WebView content). In Organizer there is a pie-chart showing the OS version the crashes happen on. Some crashes have only 26.4 and 26.5 mentioned. The others may have earlier OS versions, while the percentage is still mostly in the freshest 26.4+26.5). Here are some examples from live users and screenshots with pie-charts:

Thanks for those crash reports.

All of them show signs of a third-party crash reporter — actually, a couple of different third-party crash reports — which is not great. The problem with third-party crash reporters is that they often fail to preserve the state of the Apple crash report, which makes it hard to trust what you see )-: I have a much more detailed explanation of this in Implementing Your Own Crash Reporter.

Having said that, this set of crash reports certainly suggest you’re running out of virtual address space. Lemme go through each one.

For FMOD.crash, consider this in the crash threading backtrace:

2 UnityFramework … MemoryManager::OutOfMemoryError(unsigned long, unsigned long, MemLabelId, char const*, int) + 640 (MemoryManager.cpp:1504)
3 UnityFramework … MemoryManager::Allocate(unsigned long, unsigned long, MemLabelId, AllocateOptions, char const*, int) + 384 (MemoryManager.cpp:1743)

It’s hard to be sure what’s going on here without knowing what MemoryManager::Allocate(…) does, but it’s a reasonable assumption that it’s called malloc, or something similar, got back NULL, and thus triggered this failure.

For JSC.crash, we see this:

Thread 63 name:
Thread 63 Crashed:
0 JavaScriptCore … pas_scavenger_notify_eligibility_if_needed + 348 (pas_scavenger.c:514)

You can actually see this code in the WebKit open source. Specifically, here’s the line that crashed:

result = pthread_create(&thread, NULL, scavenger_thread_main, NULL);
PAS_ASSERT(!result);

Note The line number in my link isn’t the same as the line number the crash report because I didn’t take the time to find the exact revision of JSC that shipped with iOS 26.5 (23F77).

In short, pthread_create failed and JSC trapped.

Now, pthread_create create can fail for a variety of reasons but one obvious one is that it tried to allocate memory and that failed.

In Network.crash, frame 18 of thread 74, the crashing thread, is this:

18 CoreFoundation … _CFRaiseMemoryException + 44 (NSException.m:969)
19 CoreFoundation … __CFReallocationFailed + 220 (CFBase.c:1112)
20 CoreFoundation … __CFSafelyReallocateImpl + 80 (CFBase.c:1130)
21 CoreFoundation … __CFDataGrow + 340 (CFData.c:579)
22 CoreFoundation … CFDataReplaceBytes + 364 (CFData.c:677)

That’s pretty clear: Someone tried to grow a CFData object and it failed to allocate the necessary memory.

For SceneLoading_TOP.crash, we can’t tell anything because the crashing thread, thread 38, isn’t in the crash report

WebView.crash seems to be the same as Network.crash.

So, yeah, there’s lots to suggest that this is your process running out of memory. However, it’s not running out of physical memory. If that happened, you’d see jetsam reports. Rather, it’s running out of virtual address space. This is causing malloc and friends to fail, which then triggers these crashes.

That means that your footprint measurements are irrelevant because footprint is a physical memory metric. Likewise for os_proc_available_memory.

Consider code like this:

while (true) {
    void * buf = malloc(1024 * 1024);
    assert(buf != NULL);
}

It rapidly consumes memory, right? But it doesn’t actually consume physical memory. If you run this code and monitored your app’s footprint, it’d hardly rise at all. That’s because malloc is allocating address space but you never touch any of that address space, so the OS never assigns any physical pages to it. So, the footprint might rise a little bit, because malloc allocates and touches some memory to keep track of all these allocations, but that rise is way less than the amount of memory you ‘allocated’.

So, you need to start investigating your virtual address space, that is:

• Whether your app is using more virtual address space for some reason.
• Or whether iPadOS is giving your less virtual address space to play with.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you for this thorough analysis. My bad providing you with the TOP crash without the crashing thread' stack. The top frames in the neighbouring crash reports are the same as in FMOD crash.

The MemoryAllocator thing there is Unity's entry point for Native allocators. Not sure if that would shed some light on the internals though.

So, you need to start investigating your virtual address space, that is:

• Whether your app is using more virtual address space for some reason.
• Or whether iPadOS is giving your less virtual address space to play with.

Doesn't the fact that it happens only on certain latest iPadOS versions prove than iPadOS is giving us less?

If you don't think so, then could you please describe any method of diagnosing virtual address space? The only thing I can think of is using VM Tracker instrument. But as we are not the Unity engine developers, we'll definitely fail in attributing VM regions.

The other option for us is using Extended Virtual Addressing Entitlement. I believe enabling it has some drawbacks, but don't know which ones.

Doesn't the fact that it happens only on certain latest iPadOS versions prove than iPadOS is giving us less?

It’s strong evidence, but it’s not conclusive. For example, if the suballocator was specific tuned to match the behaviour of the system allocator, and then the system allocator changed, that could result in memory fragmentation that only causes problems when that combination in play. So, my advice is to measure rather than that assume.

I believe enabling it has some drawbacks

The main drawback is that the kernel has to allocate more memory to keep track of your large address space.

OTOH, it’d be interesting datapoint. You could, for example, ship a beta release this with enabled and then compare the crash rate on that versus that of the previous beta. That would at least confirm that address space is the issue.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

So, jumping in here with a bit of new information, what's actually going on here:

So, yeah, there’s lots to suggest that this is your process running out of memory. However, it’s not running out of physical memory. If that happened, you’d see jetsam reports. Rather, it’s running out of virtual address space. This is causing malloc and friends to fail, which then triggers these crashes.

...is that the kernel is determining that your process has hit its address space limit, due to a complicated interaction of between two different changes. Part of the issue is that JavaScriptCore is reserving more address space than it should on lower memory devices (r.177567438). The corresponding WebKit bug on this is here. However, the other factor here is that the previous reservation was given its own vm-tag (r.174732430), substantially increasing the kernel’s "perception" (for lack of a better word) of address space usage. The interaction between those two bugs then reduced overall available address space.

Covering a few odds and ends, JavaScriptCore has come up a few times here. It's a necessary component because the system was already increasing your process’s address space allocation to accommodate its special requirements. This is what causes the difference in the two cases that the chart on this post shows.

In terms of when a fix will ship, I can confirm that addressing this is being given the highest priority and that the issue is not fixed in our most recent seed releases.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware