[Mac Catalyst] EXC_BAD_ACCESS crash in audio device cleanup during room.disconnect()

[zook111]

Body:

Description

When calling room.disconnect() on Mac Catalyst, the app crashes with EXC_BAD_ACCESS in the WebRTC audio device
module. This does not occur on iOS - only Mac Catalyst.

Environment

• SDK Version: 2.10.1
• Platform: Mac Catalyst (iOS app running on Mac)
• macOS: Sequoia 15.x
• Xcode: 16.x

Crash Details

LiveKitWebRTC`___lldb_unnamed_symbol14016:
-> 0x104242384 <+0>: str xzr, [x0, #0x40]
0x104242388 <+4>: ret

worker_thread: EXC_BAD_ACCESS (code=1, address=0x40)

Console Output Before Crash

AudioHardware-mac-imp.cpp:773 AudioObjectGetPropertyData: no object with given ID 113
AVAEInternal.h:83 required condition is false: [AVAudioEngine.mm:1269:CheckCanPerformIO: (canPerformIO)]
AudioEngineDevice setVoiceProcessingEnabled error: (null)

Reproduction Steps

1. Run iOS app on Mac via Catalyst
2. Connect to a LiveKit room with audio
3. Start a voice session (microphone enabled)
4. Call room.disconnect() or end the session
5. App crashes immediately

Minimal Code

// Simple disconnect - crashes on Mac Catalyst
await room.disconnect()

What I've Tried

- Adding delays before/after disconnect (100ms to 1000ms)
- Disabling microphone before disconnect
- Clearing room references before disconnect
- Using setRecordingAlwaysPreparedMode(true)
- SDK versions 2.8.1 and 2.10.1

None of these workarounds prevent the crash.

Analysis

The crash appears to be in the WebRTC audio device module trying to access an aggregate audio device (ID 113) that
has already been destroyed. The worker_thread is still running when the audio device cleanup occurs, causing a
dangling pointer access at offset 0x40.

Expected Behavior

room.disconnect() should cleanly disconnect from the room on Mac Catalyst without crashing.

Workaround

Currently none - the only option is to disable Mac Catalyst support.

---

[hiroshihorie]

I will try to reproduce this one, thank you for the details.

[pblazej]

Probably sth related to mixing build configs like TARGET_OS_OSX && WEBRTC_IOS

[zook111]

Thanks @ArekPankowski - that makes sense. Is this something that can be fixed in an upcoming SDK release? We're
blocked on our Mac Catalyst release until this is resolved. Happy to test any fix.

[pblazej]

@zook111 I just scratched the surface here, we need to find the root cause (in between audio device and session management).