Hello, We are investigating an issue where our iOS app, running as a “Designed for iPad” app on an Apple Silicon Mac, is terminated when it is suspended in the background. Environment OS: macOS 27.0.1 Hardware: Apple Silicon Mac App type: An iOS/iPadOS app running on Mac, rather than a separately developed macOS app The app uses Core Image’s CIContext to generate some image effects Steps to reproduce Launch the app on Mac and start playing a podcast. Move the app to the background. Start playback on another device. Our app’s cross-device playback coordination pauses playback on the Mac. After a short period, the Mac app is terminated. We have also observed similar termination after visiting a screen that uses Core Image image effects. Actual result The debugger reports: Terminated due to signal 9 RunningBoard logs indicate that the app was terminated with code 0xDEAD10CC because it was suspended while holding a disallowed shared file lock. The file identified in the log is: /var/folders/.../C/app.podcast.cosmos/app.podcast.cosmos/com.apple.metal/archiveUsage.db/lock.mdb The relevant log message includes: suspended while holding a shared file lock Investigation so far Using breakpoints on open and openat, we captured a call stack corresponding to: App creates a CIContext → Core Image CI::MetalContext → Metal recordBinaryArchiveUsage → archiveUsage.db/lock.mdb is opened We also tried: CIContext(options: [.useSoftwareRenderer: true]) However, in our test environment, we still observed Metal initialization and access to the relevant cache files. This option did not avoid the issue. For the gradient-mask generation code we had identified, we replaced the Core Image implementation with a CPU implementation using CGContext and CGGradient, avoiding CIContext creation on that path. After repeatedly testing the same reproduction steps, we could no longer reproduce the termination in that scenario. This suggests a connection to the Metal cache file lock accessed during Core Image initialization. However, we have not established the exact lifetime or internal owner of the lock, and we have not confirmed a thread deadlock. Questions Is this a known issue involving Core Image/Metal and suspension of iOS apps running on macOS 27.0.1? Why would a system-managed Metal cache file lock cause the app to be terminated with 0xDEAD10CC when suspended? Is there a recommended context configuration, resource cleanup procedure, or lifecycle handling approach that allows us to continue using Core Image safely in this environment?