I'm experiencing an issue where the App Group shared container appears to be recreated (with a new creation date) during an app update, resulting in complete loss of locally stored data. Background My app uses UserDefaults, Realm, Core Data, and CloudKit, with all local data stored in the App Group container (FileManager.containerURL(forSecurityApplicationGroupIdentifier:)). The app has been available since 2016 and has a stable user base. Starting last year, I began receiving occasional reports from users saying all their data in the app had disappeared. To investigate, I added diagnostic logging that detects when an existing user's data appears to have been reset — specifically by checking the App Group container's file system creation date, and the existence and values of expected files. What the diagnostics revealed When the issue occurs, I observe the following: The App Group container has a recent creation date, far newer than the user's first launch date The Core Data store file's creation date is also immediately after the App Group container's recreation date I write the same values to both standard UserDefaults and the App Group version (UserDefaults(suiteName:)). Only the App Group version is reset — the standard side retains historical data The standard side still holds firstLaunchDate, initialVersion, and launchCount, confirming this is not a fresh install Here is a sample diagnostic log from an affected user: appGroupContainerCreationDate: 2026-03-30T18:44:10Z firstLaunchDate: 2025/01/05 4:00 initialVersion: 10.8.0 currentAppVersion: 10.14.14 previousVersion: 10.10.0 launchCount: 44 availableStorageMB: 46646 The container creation date (2026-03-30) is clearly inconsistent with the user's first launch date (2025-01-05) and launch count (44). The container creation date is obtained with the following code: let appGroupURL = FileManager.default.containerURL( forSecurityApplicationGroupIdentifier: "group.xxx.xxx" )! let attributes = try? FileManager.default.attributesOfItem(atPath: appGroupURL.path) let containerCreationDate = attributes?[.creationDate] as? Date Scale and pattern Reports began increasing in late November last year Over 85% of affected cases are on iOS 26 Most affected devices have plenty of available storage (46GB+ in the example above) This is likely occurring during a normal app update (not a fresh install or device restore) Ruled-out hypotheses Not a fresh install — firstLaunchDate, initialVersion, and launchCount are preserved in standard UserDefaults Not a storage issue — affected users typically have tens of GBs of free space, making it unlikely that iOS purged the data due to low storage Not an app-side code change — the App Group identifier and entitlements have not been changed Not triggered by silent notifications, background tasks, or widget activity — these processes do write to the App Group container, but the recreation does not appear to occur immediately after any of these operations Questions Has anyone else observed App Group containers being recreated (new creation date, empty contents) during a standard app update? Is there a known iOS behavior or bug that could cause this, particularly on iOS 26? Are there any recommended mitigations? Any insight would be greatly appreciated. This is a data loss issue affecting real users, and I'd like to understand whether this is an iOS-level problem or something I should be handling differently on my end.

I'm encountering a null pointer dereference crash pointing to the internals of CFNetwork library code on iOS. I'm spawning URLSessionTasks at a decently fast rate (~1-5 per second), with the goal being to generate application layer network traffic. I can reliably encounter this crash pointing to NetConnection::dequeue right after a new task has been spawned and had the resume method called. I suspect that this is perhaps a race condition or some delegate/session object lifecycle bug. The crash appears to be more easily reproduced with a higher rate of spawning URLSessionTasks. I've included the JSON crash file, the lldb stack trace, and the source code of my URLSession(Task) usage. urlsession_stuff_stacktrace.txt urlsession_stuff_source.txt urlsession_crash_report.txt

We probably triggered a bug within Rosetta: https://github.com/docker/desktop-feedback/issues/230

I am facing an intermittent problem where iPhones are failing to pair/connect with Xcode under Xcode -> Windows -> Devices and Simulators. This happens when more than one web content filters are present, for instance, I have my web content filter (FilterSockets true, FilterGrade Firewall) and there is also Sentinel One web content filter with same configuration. Note: We are not blocking any flow from remoted / remotepairingd / core device service / MDRemoteServiceSupport etc processes. But they do get paused and resumed at times for our internal traffic verification logic. So, we are trying to understand what impact our content filter may be having on this iPhone Pairing?? If we stop either one of the filters the problem goes away. I have tracked the network traffic to the phone, and it seems to be using a ethernet interface (en5/en10) over the USB-C cable. I can see endpoints like this: localEndpoint = fe80::7:afff:fea1:edb8%en5.54442 remoteEndpoint = fe80::7:afff:fea1:ed47%en5.49813 I also see remoted process has the below ports open : sudo lsof -nP -iTCP -iUDP | grep remoted remoted 376 root 4u IPv6 0xce4a89bddba37bce 0t0 TCP [fe80:15::7:afff:fea1:edb8]:57395->[fe80:15::7:afff:fea1:ed47]:58783 (ESTABLISHED) remoted 376 root 6u IPv6 0xf20811f6922613c7 0t0 TCP [fe80:15::7:afff:fea1:edb8]:57396 (LISTEN) remoted 376 root 7u IPv6 0x2c393a52251fcc56 0t0 TCP [fe80:15::7:afff:fea1:edb8]:57397 (LISTEN) remoted 376 root 8u IPv6 0xcb9c311b0ec1d6a0 0t0 TCP [fd6e:8a96:a57d::2]:57398 (LISTEN) remoted 376 root 9u IPv6 0xc582859e0623fe4e 0t0 TCP [fd6e:8a96:a57d::2]:57399 (LISTEN) remoted 376 root 10u IPv6 0x2f7d9cee24a44c5b 0t0 TCP [fd6e:8a96:a57d::2]:57400->[fd6e:8a96:a57d::1]:60448 (ESTABLISHED) remoted 376 root 11u IPv6 0xbdb7003643659de 0t0 TCP [fd07:2e7e:2a83::2]:57419 (LISTEN) remoted 376 root 12u IPv6 0x569a5b649ff8f957 0t0 TCP [fd07:2e7e:2a83::2]:57420 (LISTEN) remoted 376 root 13u IPv6 0xa034657978a7da29 0t0 TCP [fd07:2e7e:2a83::2]:57421->[fd07:2e7e:2a83::1]:61729 (ESTABLISHED) But due to the dynamic nature of port and IPs used we are not able to decide on an effective early bypass NEFilterRule. We don't want to use a very broad bypass criteria like all link local IPs etc. Any help will be greatly appreciated.

Inquiry) Inquiry Regarding USB Network Connectivity Between an iPad (Wi‑Fi Model) and an Embedded Linux Device An embedded device (OS: Linux) is connected to an iPad (Wi‑Fi model) using a USB‑C cable. The ipheth driver is installed on the embedded device, and the iPad is recognized correctly. A web server is running on the embedded device. To launch a browser on the iPad and access the web server running on the embedded device via a USB network connection. Based on our verification, the iPad is not assigned an IP address, and therefore communication with the web server on the embedded device is not possible. We would appreciate it if you could provide guidance on the following questions. We would like to assign an IP address to the iPad (Wi‑Fi Model) so that it can communicate with the embedded device over a USB network connection. Is there a way to achieve this through the standard settings on the iPad? If this cannot be achieved through settings alone, are there any existing applications that provide this functionality? If no such application currently exists, is it technically possible to develop an application that enables this capability on iPadOS? Information) The USB‑C port on the embedded device is fixed in HOST mode. The embedded device operates as the USB host, and the iPad operates as a USB device. When a cellular model iPad is connected and “Personal Hotspot” is enabled, an IP address is assigned via DHCP, and we have confirmed that the web server can be accessed from the iPad’s browser. We are investigating whether a similar solution is possible with a Wi‑Fi model iPad.

Hello, How does macOS handle coexistence between multiple Transparent Proxy providers from different vendors if their network rules overlap and one provider modifies the traffic? Thank you in advance!

Hello, Is it possible for a Network Extension (running in its sandbox) to act as a client for an XPC service hosted by a Launch Daemon (e.g., to offload data processing)? Are there any specific sandbox restrictions or entitlement requirements for this type of XPC communication? Thank you in advance!

I'm building a freediving app for Apple Watch Ultra using the shallow depth entitlement (com.apple.developer.submerged-shallow-depth-and-pressure). My app uses WKExtendedRuntimeSession with the underwater-depth background mode, and it works correctly — the session starts, Water Lock activates automatically, and Crown hold water ejection ends the session as expected. However, the app does not appear in Settings > General > Auto-Launch > When Submerged on the watch. Other third-party apps (including one that hasn't been updated in ~2 years and presumably only has the shallow entitlement) do appear in this list. My configuration: WKBackgroundModes: ["underwater-depth", "workout-processing"] WKSupportsAutomaticDepthLaunch: true (Boolean, in watch app Info.plist) Entitlement verified in both the signed binary and provisioning profile watchOS 26.3, Apple Watch Ultra 2 Tested with: development build, TestFlight, and direct Xcode deploy. Watch restarted after each. The app does not appear in any case. The documentation at https://aninterestingwebsite.com/documentation/coremotion/accessing-submersion-data states: "Adding the underwater-depth Background Mode capability also adds your app to the list of apps that the system can autolaunch when the wearer submerges the watch." Does auto-depth-launch require the full depth entitlement (com.apple.developer.submerged-depth-and-pressure), or should the shallow entitlement be sufficient? Is there an additional step required for the app to appear in the When Submerged list? Any guidance appreciated.

I've been able to run this sample project with the PIRServer. But the urls are still not blocked. https://aninterestingwebsite.com/documentation/networkextension/filtering-traffic-by-url https://github.com/apple/pir-service-example I got this on the log Received filter status change: <FilterStatus: 'running'>

Hi everyone, I’m currently developing an iOS app using React Native and implementing consumable In-App Purchases (IAP). I'm facing an issue where getProducts returns an empty array without any error messages when testing on a TestFlight build. I have already completed the following setup: Agreements, Tax, and Banking: All forms are signed and the status is "Active" in App Store Connect. Product Configuration: The Consumable product is created in App Store Connect with the status "Ready to Submit". App Store Connect Integration: The product is correctly linked under the "In-App Purchases and Subscriptions" section of the App version. Xcode Capability: The "In-App Purchase" capability has been added to the project. Implementation: The Product ID in my React Native code (using react-native-iap) matches the ID in App Store Connect exactly. Despite these steps, the product list remains empty. Are there any hidden requirements or specific configurations for TestFlight that I might have missed? Any guidance would be greatly appreciated. Thanks!

I have a few feasibility questions regarding health data processing on iOS, related to HealthKit and system capabilities: Background Health Data Collection Can an iOS app continuously collect and process health data in the background, including: Collecting health data from the Health app while the device is locked or in sleep mode Triggering user notifications when anomalies are detected in health data processing Are there any technical limitations? Do these capabilities require specific enterprise qualifications or additional fees? 2. Emergency Contacts Integration Can an app write or modify the system’s built-in Emergency Contacts (Medical ID)? If a user updates Emergency Contacts in iOS Settings, can the app receive a change notification or access the updated data? 3. Automated Alerting for Health Metrics Beyond Apple’s fall detection, can abnormal health metrics (heart rate, irregular rhythm, blood oxygen, etc.) trigger automated alerts such as SMS to preset emergency contacts—without requiring the user to manually open the app or only receive on-device notifications? This is a feasibility inquiry about API and system behavior, not a bug report. Any official guidance or documentation references would be greatly appreciated.

Hello, I am starting work on adding AlarmKit to an existing project. During testing, I ran into an issue that if I hit Deny during the authorization request, I can't find any way to turn the alarm back on in settings. The only way I can get an authorization request again is by uninstalling the app and installing it again. I would like to be able to prompt my users where they can turn the Alarm back on if they accidentally hit Deny. Am I just not seeing the settings to change this somewhere?

Shouldn't it be supported? Also is there a way to disable spotlight indexing on a mounted folder? mds_stores is going wild on fskit volumes. mount -o nobrowse -t passthrough ~/Downloads ~/mnt alexf@MacBook-Pro-3 build % mount file:///Users/alexf/Downloads/ on /Users/alexf/mnt (passthrough, local, nodev, nosuid, noowners, noatime, fskit, mounted by alexf)```

We are trying to determine whether a third-party DriverKit HID dext can seize or intercept raw HID input reports from an external mouse through any top case–related path in the HID stack. Our dext is based on IOUserHIDEventDriver, and the goal is to receive raw input reports before they are translated into higher-level pointer events. Apple’s public HIDDriverKit documentation describes IOUserHIDEventDriver as the driver object responsible for dispatching pointer, digitizer, scrolling, and related HID-originated events, but it is not clear to us whether any “top case” path is actually exposed or supported for third-party matching in DriverKit. What we want to clarify is specifically about external mouse devices, not the built-in trackpad itself. Questions: Is there any officially supported way for a third-party DriverKit HID dext to bind through a top case–related path and receive raw HID input reports from an external mouse? Is “top case” something that third-party DriverKit drivers can meaningfully target for matching/attachment, or is it only an internal Apple implementation detail? If such a path exists, can it be used to seize raw reports before they are converted into higher-level pointer events? If not, what is the officially supported boundary for third-party DriverKit access to raw reports from external mouse-class HID devices? To be clear, we are not asking about synthesizing pointer events. We are asking whether a third-party DriverKit dext can directly observe or seize the original HID input reports from an external mouse by attaching through any top case–related portion of the HID stack. If “top case” is not a public DriverKit concept that third parties can target, confirmation of that would also be very helpful.

Environment Xcode 26.5 beta iOS 26.5 beta Using AccessorySetupKit + AccessoryTransportExtension framework Three extensions: AccessoryTransportAppExtension, AccessoryTransportSecurityExtension, AccessoryDataProviderExtension Background Everything worked correctly on iOS 26.4 beta. All three extensions shared the entitlement com.apple.developer.accessory-transport-extension, and the system launched them as expected. After upgrading to iOS 26.5 beta (both Xcode and device), the app compiles and runs, the accessory pairs and connects successfully (state = authorized, BLE connected, notification forwarding = allow), but none of the extensions are launched by the system. Investigation Captured system Console logs from the device and found these errors from deviceaccessd: error deviceaccessd ### Extension 'com.huami.NotificationForwardingDemo.AccessoryDataProviderExtension' is missing entitlement: com.apple.developer.accessory-data-provider for com.apple.accessory-data-provider error deviceaccessd ### Extension 'com.huami.NotificationForwardingDemo.AccessoryTransportSecurityExtension' is missing entitlement: com.apple.developer.accessory-transport-security for com.apple.accessory-transport-security It appears that iOS 26.5 now requires per-extension-type entitlements instead of the shared one. On iOS 26.4, all three extensions used com.apple.developer.accessory-transport-extension and it worked. On iOS 26.5, deviceaccessd now expects com.apple.developer.accessory-transport-security for the security extension and com.apple.developer.accessory-data-provider for the data provider extension. The transport app extension did not report an error, so it may still accept the old entitlement. Attempted Fix Changed the entitlement keys in the .entitlements files to match what deviceaccessd expects. Xcode fails to build with: ▎ Entitlement com.apple.developer.accessory-data-provider not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. Root Cause Checked Apple Developer Portal — only one capability is available: "Accessory Transport Extension", which maps to com.apple.developer.accessory-transport-extension. There are no separate capability options for the new entitlements. The iOS 26.5 beta system requires new per-extension-type entitlements, but the provisioning system does not yet support them. This makes it impossible to build a working AccessoryTransport app on iOS 26.5 beta. Request Please either add the new entitlement capabilities (com.apple.developer.accessory-transport-security, com.apple.developer.accessory-data-provider) to the Apple Developer Portal, or restore backward compatibility with com.apple.developer.accessory-transport-extension in deviceaccessd.

We are trying to intercept raw reports from the built-in MacBook haptic trackpad using a DriverKit IOUserHIDEventDriver dext. Our dext installs and activates successfully: OSSystemExtensionRequest finishes with result 0 systemextensionsctl list shows the dext as activated enabled the dext is embedded correctly in the app bundle However, it never attaches to the built-in trackpad IOHIDInterface. ioreg shows the built-in trackpad interface still matched only by Apple’s HID dext. We also observed that Apple’s own HID dext appears to use com.apple.developer.driverkit.builtin, while that entitlement is not available in our provisioning profile. Our dext specifically relies on: IOUserHIDEventDriver::handleReport(...) SetProperties() with kIOHIDEventDriverHandlesReport Questions: Is com.apple.developer.driverkit.builtin required for a third-party IOUserHIDEventDriver to match a built-in internal trackpad IOHIDInterface? Is that entitlement public/requestable, or Apple-internal only? At what stage is it enforced: activation, personality matching, provider attach, or before Start()? If builtin is not available to third parties, is there any officially supported way to receive raw reports from the built-in MacBook trackpad in DriverKit? Our conclusion so far is that activation succeeds, but provider binding to the built-in trackpad fails due to built-in-only authorization/matching.

We're seeing a sporadic crash (~2-3% of spawns) when launching a large Mach-O binary via posix_spawn(). The crash happens inside libsystem_malloc.dylib during __malloc_init, before any application code runs. The process never reaches main(). Environment: macOS 26.3.1 (25D2128), Apple Silicon (ARM64) Crash signature BUG IN LIBMALLOC: pointer range initial reservation failed, Abort Cause 3 #0 libsystem_malloc.dylib: xzm_main_malloc_zone_init_range_groups.cold.1 #1 libsystem_malloc.dylib: xzm_main_malloc_zone_init_range_groups #2 libsystem_malloc.dylib: xzm_main_malloc_zone_create #3 libsystem_malloc.dylib: __malloc_init #4 libSystem.B.dylib: libSystem_initializer #5 dyld: dyld4::Loader::findAndRunAllInitializers The binary It's a Chromium component-build test binary (browser_tests): ~1.5 GiB on disk, 5.54 GiB total VA footprint (__TEXT 517 MiB, __LINKEDIT 1.04 GiB, __PAGEZERO 4 GiB) Links 527 dylibs via @rpath All images span ~16.4 GiB of VA when loaded A simple loop that spawns this binary 200 times via posix_spawn() reliably shows 2-5 crashes. Spawning /bin/cat 1000 times produces zero failures. Investigation We did extensive analysis to understand the root cause: ASLR is irrelevant. We disabled ASLR using _POSIX_SPAWN_DISABLE_ASLR (flag 0x0100) and the failure rate is unchanged (~2% with or without). With ASLR disabled, the library addresses are identical across all crashes, confirming the VA layout itself isn't the problem. Plenty of free VA space is available. We compared the memory layout of crashing processes (from crash reports) with successful ones (via vmmap): In successful spawns, XZone places its MALLOC zones (SMALL, LARGE, metadata) in the large free regions after the loaded dylibs — for example at 0x784400000 and 0xD32000000, with 13-22 GiB contiguous free gaps available. In crashing processes, the same free regions exist (the image layout is identical), but xzm_main_malloc_zone_init_range_groups fails to reserve into them. Based on libmalloc/tests/memory_pressure.c, XZone needs 8 GiB for pointer ranges and 10 GiB for data ranges. The free gaps after the dylibs are far larger than this, yet the reservation sporadically fails. No workarounds exist. MallocNanoZone=0 has no effect (the crash is before zone configuration). The crash is entirely within system code. Questions Is this a known issue in XZone malloc on macOS 26.x? Is there any environment variable or entitlement that could work around this? Any guidance on what makes xzm_main_malloc_zone_init_range_groups fail non-deterministically when contiguous VA space is clearly available?

Note: This document is specifically focused on what happens after a DEXT has passed its initial code-signing checks. Code-signing issues are dealt with in other posts. Preliminary Guidance: Using and understanding DriverKit basically requires understanding IOKit, something which isn't entirely clear in our documentation. The good news here is that IOKit actually does have fairly good "foundational" documentation in the documentation archive. Here are a few of the documents I'd take a look at: IOKit Fundamentals IOKit Device Driver Design Guidelines Accessing Hardware From Applications Special mention to QA1075: "Making sense of IOKit error codes",, which I happened to notice today and which documents the IOReturn error format (which is a bit weird on first review). Those documents do not cover the full DEXT loading process, but they are the foundation of how all of this actually works. Understanding the IOKitPersonalities Dictionary The first thing to understand here is that the "IOKitPersonalities" is called that because it is in fact a fully valid "IOKitPersonalities" dictionary. That is, what the system actually uses that dictionary "for" is: Perform a standard IOKit match and load cycle in the kernel. The final driver in the kernel then uses the DEXT-specific data to launch and run your DEXT process outside the kernel. So, working through the critical keys in that dictionary: "IOProviderClass"-> This is the in-kernel class that your in-kernel driver loads "on top" of. The IOKit documentation and naming convention uses the term "Nub", but the naming convention is not consistent enough that it applies to all cases. "IOClass"-> This is the in-kernel class that your DEXT attaches to and works through. This is where things can become a bit confused, as some families work by: Routing all activity through the provider reference so that the DEXT-specific class does not matter (PCIDriverKit). Having the DEXT subclass a specific subclass which corresponds to a specific kernel driver (SCSIPeripheralsDriverKit). This distinction is described in the documentation, but it's easy to overlook if you don't understand what's going on. However, compare PCIDriverKit: "When the system loads your custom PCI driver, it passes an IOPCIDevice object as the provider to your driver. Use that object to read and write the configuration and memory of your PCI hardware." Versus SCSIPeripheralsDriverKit: Develop your driver by subclassing IOUserSCSIPeripheralDeviceType00 or IOUserSCSIPeripheralDeviceType05, depending on whether your device works with SCSI Block Commands (SBC) or SCSI Multimedia Commands (SMC), respectively. In your subclass, override all methods the framework declares as pure virtual. The reason these differences exist actually comes from the relationship and interactions between the DEXT families. Case in point, PCIDriverKit doesn't require a specific subclass because it wants SCSIControllerDriverKit DEXTs to be able to directly load "above" it. Note that the common mistake many developers make is leaving "IOUserService" in place when they should have specified a family-specific subclass (case 2 above). This is an undocumented implementation detail, but if there is a mismatch between your DEXT driver ("IOUserSCSIPeripheralDeviceType00") and your kernel driver ("IOUserService"), you end up trying to call unimplemented kernel methods. When a method is "missing" like that, the codegen system ends up handling that by returning kIOReturnUnsupported. One special case here is the "IOUserResources" provider. This class is the DEXT equivalent of "IOResources" in the kernel. In both cases, these classes exist as an attachment point for objects which don't otherwise have a provider. It's specifically used by the sample "Communicating between a DriverKit extension and a client app" to allow that sample to load on all hardware but is not something the vast majority of DEXT will use. Following on from that point, most DEXT should NOT include "IOMatchCategory". Quoting IOKit fundamentals: "Important: Any driver that declares IOResources as the value of its IOProviderClass key must also include in its personality the IOMatchCategory key and a private match category value. This prevents the driver from matching exclusively on the IOResources nub and thereby preventing other drivers from matching on it. It also prevents the driver from having to compete with all other drivers that need to match on IOResources. The value of the IOMatchCategory property should be identical to the value of the driver's IOClass property, which is the driver’s class name in reverse-DNS notation with underbars instead of dots, such as com_MyCompany_driver_MyDriver." The critical point here is that including IOMatchCategory does this: "This prevents the driver from matching exclusively on the IOResources nub and thereby preventing other drivers from matching on it." The problem here is that this is actually the exceptional case. For a typical DEXT, including IOMatchCategory means that a system driver will load "beside" their DEXT, then open the provider blocking DEXT access and breaking the DEXT. DEXT Launching The key point here is that the entire process above is the standard IOKit loading process used by all KEXT. Once that process finishes, what actually happens next is the DEXT-specific part of this process: IOUserServerName-> This key is the bundle ID of your DEXT, which the system uses to find your DEXT target. IOUserClass-> This is the name of the class the system instantiates after launching your DEXT. Note that this directly mimics how IOKit loading works. Keep in mind that the second, DEXT-specific, half of this process is the first point your actual code becomes relevant. Any issue before that point will ONLY be visible through kernel logging or possibly the IORegistry. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Hello all Synopsis: document based SwiftData app breaks document handling after first save due to internal error saving the -shm file. Long: i am working on a small document based SwiftData app for macOS. The UI works well as long as the document was not saved. After saving the document and reopening it, I get an error consistently in console: BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode unlinked while in use: /Users/vrunkel/Library/Containers/de.ecoobs.CurtailmentAnalyzer/Data/tmp/TemporaryItems/NSIRD_CurtailmentAnalyzer_mrXKMs/NewDocument/StoreContent-shm So somehow the -shm file is still referenced to NewDocument created when the app opens an untitled document and resides in the temporary folder. I have saved the document to my documents folder. After reopening and the above error deletion or addition of items crashes the app with a long backtrace to view updating: Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread. I am not creating any threads or do background work. If I do not save the document but work within the new untitled document no problems occur. Even closing the app and reopening the untitled new doc (happens automatically) all is fine. To rule out any influence of my existing view structure I have created the most simple test case - Xcode -> New Project -> macOS document based app configured to use SwiftData. Same behaviour. After saving a new document the addition/deletion of items causes the thread-induced crash and shows the error in console when opening the document. I am using latest versions of Xcode 15.0 and macOS 14.0 Any ideas? thx, volker

Hello. Our application performs encoding and decoding of large json files which sometimes may take up to 1,5GB of RAM memory. We understand that this may be a problem for devices with low RAM memory (3GB). But before iOS 26.4 we didn't have much occurrences (3 for the last 90 days). Starting from iOS 26.4 it started to crash a lot. Can the reason be that iOS 26.4 occupies more RAM memory so there is less memory left for our app? Or maybe starting from iOS 26.4 there is less RAM memory allocated per app? The crash message is Fatal error: failed to allocate 392 bytes of memory with alignment 8