I'm investigating an intermittent crash in an iOS audio app when launching it through an Inter-App Audio (IAA) host Audiobus and AUM. The crash occurs during the host connection/startup process. The app begins initializing its audio engine, successfully creates and registers an ABAudioSenderPort, starts its output audio unit, and then crashes. Crash details Crash Report Exception: EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x50 Backtrace: #0 _dispatch_sync_f #1 caulk::concurrent::details::dispatch_receiver::~dispatch_receiver #2 std::__1::__shared_weak_count::__release_shared #3 caulk::concurrent::messenger::~messenger #4 CADeprecated::CAAutoDelete<caulk::concurrent::messenger>::set #5 AURemoteIO::IPC_Uninitialize #6 AURemoteIO::IPC_Uninitialize #7 AUWrappedOutputUnit::AUUninitialize #8 _XUninitialize #9 IPCAudioUnit_server #10 dispatch_mig_server #11 _dispatch_client_callout #12 _dispatch_continuation_pop #13 _dispatch_source_latch_and_call #14 _dispatch_source_invoke #15 _dispatch_lane_serial_drain #16 _dispatch_lane_invoke #17 _dispatch_root_queue_drain_deferred_wlh #18 _dispatch_workloop_worker_thread #19 _pthread_wqthread Repro: Quit Audiobus completely. Relaunch Audiobus. Launch the app from Audiobus. The app begins initialization, but crashes during or shortly after the initial host connection. Interestingly, if Audiobus remains open and I attempt to launch the app again, the crash doesn't appear to occur. Reloading the app via AUM is also reproducing the crash. A number of other apps are able to launch via Audiobus, so I think it must be how we are initialising our engine, but I haven't been able to find where we are going wrong. The app configures its audio session as follows: Category: AVAudioSessionCategoryPlayback Mode: AVAudioSessionModeDefault Preferred sample rate: 48000 Hz Preferred I/O buffer duration: approximately 5.3 ms Reported buffer size: 256 frames Input channels: 0 Output channels: 2 Audio-unit initialization The engine creates and initializes its audio unit successfully: AudioComponentInstanceNew: status = 0 AudioUnitInitialize: status = 0 AudioOutputUnitStart: status = 0 The app then creates an ABAudioSenderPort, configures its client format, and registers it with ABAudiobusController. These operations also complete successfully. The engine's RemoteIO audio unit and the sender port's audio unit are separate instances. I haven't yet worked out which instance is being uninitialized when the crash occurs. This seems to be happening across multiple iPhone and iPad models, back to at least iOS 17, and my test environment, Xcode 26.6 and iPadOS 26.5.2. Questions Has anyone encountered this caulk::concurrent::messenger::~messenger / AURemoteIO::IPC_Uninitialize crash when using IAA, Audiobus, AUM? Could this indicate a race or invalid lifecycle transition in Apple's RemoteIO/IAA IPC implementation? Are there known requirements concerning the order of audio-unit initialization, sender-port registration, host connection, and uninitialization that could explain this behavior? What additional diagnostics would help determine which audio-unit instance is being uninitialized and what triggers the failure? Any suggestions or reports of similar behavior would be greatly appreciated.

When running a SwiftUI DocumentGroup app on macOS designed for iPad, onDisappear is not called when closing a document, and deinit of state objects owned by a ContentView is not invoked. This behavior works as expected on iPad. @main struct MyApp: App { var body: some Scene { DocumentGroup(newDocument: MyDocument()) { file in ContentView(document: file.$document) .onDisappear { print("This isn't called on macOS Designed For iPad, but is on iPad when closing a document.") } } } } It is my understanding that for a macOS designed for iPad these lifecycle events would behave the same - otherwise there appears to be no way to detect if a document has closed on macOS.

I’ve been trying to set up a UIDocument and override writeContents(...). This works correctly in older projects, but I haven’t been able to get it working in my new iOS 26 app using Swift 6. To troubleshoot, I tested the Particles demo and successfully overrode writeContents there. However, as soon as I switch that project to iOS 26 and Swift 6, calling save; which triggers writeContents, causes the same crash. override public func writeContents( _ data: Any, to url: URL, for _: UIDocument.SaveOperation, originalContentsURL _: URL?, ) throws { ... } Thread 10 Queue : UIDocument File Access (serial)