Ahh, I see. I should have added that in the question, our results were based on values derived from this function: task_vm_info_data_t() with values in MB let usedMemoryMB = vmInfo.phys_footprint / (1024 * 1024) let virtualMemoryMB = vmInfo.virtual_size / (1024 * 1024) let swappedMemoryMB = vmInfo.compressed / (1024 * 1024) What I meant by "we've allocated 32GB" was values from .compressed and phys_footprint. From your previous answer, you have mentioned when os is pressured to allocate more memory, vm on iOS terminates apps instead.. Because vmInfo.compressed had the value of 32GB, we suspected disk swap was occuring, but that may not have been the case. Since we were writing patterned data during that test, the vm system could have been able to compress better. Nevertheless, thanks to you, we understand our testing strategy was misleading to our actual use-case. Our use-case would have been to see how much memory app might be able to handle during a 3d reconstruction phase which would mean handling more complicated data. Anyhow, thank you again for the help. Its helped us more understand the workings of an iOS system.

Hello @DTS Engineer , I sincerely appreciate your detailed response. It has helped tremendously to get a hold of how iOS might be handling memory allocations. I was able to find JetsamEvent files in which they held information about memory related logs during app crash. Please request for any other source that might help you. Following is the partial snippet of that log: { "states" : [ "active", "frontmost" ], "genCount" : 0, "purgeable" : 2, "rpages" : 856759, "physicalPages" : { "internal" : [ 15583, 840732 ] }, "mem_regions" : 408, "uuid" : "{{ uuid }}, "fds" : 50, "name" : "{{ Test App }}", "priority" : 100, "csTrustLevel" : 4, "cpuTime" : 5.742299, "freeze_skip_reason:" : "none", "age" : 517739576, "coalition" : 2140, "csFlags" : 570434309, "reason" : "vm-compressor-space-shortage", "pid" : 5235, "lifetimeMax" : 856764, "killDelta" : 1271598 }, And when I run the test app in release configuration on Xcode the app crashes with the following message: The app “{{ Test App }}” has been killed by the operating system because it is using too much memory. Domain: IDEDebugSessionErrorDomain Code: 11 Recovery Suggestion: Use a memory profiling tool to track the process memory usage. User Info: { DVTErrorCreationDateKey = "2025-03-24 04:42:36 +0000"; IDERunOperationFailingWorker = DBGLLDBLauncher; } -- Event Metadata: com.apple.dt.IDERunOperationWorkerFinished : { "device_identifier" = "00008112-001239143678A01E"; "device_isCoreDevice" = 1; "device_model" = "iPad14,5"; "device_osBuild" = "18.4 (22E5232a)"; "device_platform" = "com.apple.platform.iphoneos"; "device_thinningType" = "iPad14,5-B"; "dvt_coredevice_version" = "397.28"; "dvt_coresimulator_version" = "993.7"; "dvt_mobiledevice_version" = "1759.93.3"; "launchSession_schemeCommand" = Run; "launchSession_state" = 2; "launchSession_targetArch" = arm64; "operation_duration_ms" = 50332; "operation_errorCode" = 11; "operation_errorDomain" = IDEDebugSessionErrorDomain; "operation_errorWorker" = DBGLLDBLauncher; "operation_name" = IDERunOperationWorkerGroup; "param_debugger_attachToExtensions" = 0; "param_debugger_attachToXPC" = 1; "param_debugger_type" = 3; "param_destination_isProxy" = 0; "param_destination_platform" = "com.apple.platform.iphoneos"; "param_diag_113575882_enable" = 0; "param_diag_MainThreadChecker_stopOnIssue" = 0; "param_diag_MallocStackLogging_enableDuringAttach" = 0; "param_diag_MallocStackLogging_enableForXPC" = 1; "param_diag_allowLocationSimulation" = 1; "param_diag_checker_tpc_enable" = 1; "param_diag_gpu_frameCapture_enable" = 0; "param_diag_gpu_shaderValidation_enable" = 0; "param_diag_gpu_validation_enable" = 0; "param_diag_guardMalloc_enable" = 0; "param_diag_memoryGraphOnResourceException" = 0; "param_diag_mtc_enable" = 1; "param_diag_queueDebugging_enable" = 1; "param_diag_runtimeProfile_generate" = 0; "param_diag_sanitizer_asan_enable" = 0; "param_diag_sanitizer_tsan_enable" = 0; "param_diag_sanitizer_tsan_stopOnIssue" = 0; "param_diag_sanitizer_ubsan_enable" = 0; "param_diag_sanitizer_ubsan_stopOnIssue" = 0; "param_diag_showNonLocalizedStrings" = 0; "param_diag_viewDebugging_enabled" = 1; "param_diag_viewDebugging_insertDylibOnLaunch" = 1; "param_install_style" = 2; "param_launcher_UID" = 2; "param_launcher_allowDeviceSensorReplayData" = 0; "param_launcher_kind" = 0; "param_launcher_style" = 99; "param_launcher_substyle" = 0; "param_runnable_appExtensionHostRunMode" = 0; "param_runnable_productType" = "com.apple.product-type.application"; "param_structuredConsoleMode" = 1; "param_testing_launchedForTesting" = 0; "param_testing_suppressSimulatorApp" = 0; "param_testing_usingCLI" = 0; "sdk_canonicalName" = "iphoneos18.2"; "sdk_osVersion" = "18.2"; "sdk_variant" = iphoneos; } Seeing from the first log, 'vm-compressor-space-shortage' sounds like there might be some issue related to #2 of vm's failure points. Though I have tested several times both cranking up memory on launch and playing around the app some time, I'm not sure. For every case, we were allocating 1GB of memory each tick and have reached 15GB within 1~5 min mark since app launch. Also seeing how our code have changed since January when we first tested, we were calling memset(_, 0,), allocating same "patterned" data like you have said. This may have been the reason we were able to allocate so much memory, though reproducing was not possible on current iOS version(18.3). Anyhow, thank you for your support again.