iOS 16 simulator/runtime crash caused by std::pmr usage in BoundedPriorityQueue.hpp

[joluet]

iOS 16 simulator/runtime crash caused by std::pmr usage in BoundedPriorityQueue.hpp

Environment

• react-native-audio-api: 0.12.2 (also reproduced on nightly)
• Expo SDK: 54
• React Native: 0.81.x
• Xcode: 26.3
• iOS simulator runtime: iOS 16.4
• Architecture: arm64

Crash

App crashes immediately at launch on iOS 16 simulator with:

txt dyld: Symbol not found: __ZNSt3__13pmr15memory_resourceD2Ev  Referenced from: MyAppName.debug.dylib  Expected in: .../iOS 16.4.simruntime/.../usr/lib/libc++.1.dylib 

Demangled:

txt std::__1::pmr::memory_resource::~memory_resource() 

This is a dyld launch crash before JS executes.

Investigation

Initially I suspected FFmpeg / bundled static libs (related to #987), but even after using:

 disableFFmpeg: true, 
 disableStaticExternalLibs: true, 

the crash still occurred.

The actual source appears to be:

common/cpp/audioapi/utils/BoundedPriorityQueue.hpp 

which currently uses:

#include <memory_resource>  std::pmr::multiset std::pmr::monotonic_buffer_resource std::pmr::unsynchronized_pool_resource 

Workaround / Patch

Replacing the PMR containers/resources with standard STL containers fixes the issue completely on iOS 16 simulator.

react-native-audio-api+0.12.2.patch

After this patch:

• app launches correctly on iOS 16 simulator
• no dyld crash
• no need to disable FFmpeg/static external libs

Question

Is std::pmr intended to be supported on iOS 15/16 runtimes?

It looks like current builds require newer libc++ runtime support than what is available in iOS 16 runtimes.

Would you consider:

• removing PMR usage,
• gating it behind newer deployment targets,
• or providing a fallback STL implementation for older iOS runtimes?

[alissoncunha]

+1 — confirming this in production on iOS 15.x (real devices, not just simulator)

We hit the exact same dyld Symbol missing crash at app launch on iOS 15.x and 16.x devices after bumping react-native-audio-api from 0.9.3 to 0.12.2 in our React Native app (Expo SDK 55, RN 0.81, Xcode 26.x, ~85k MAU).

Evidence

Comparing Mach-O symbol tables (nm) of our production App Store binaries:

Build	PMR symbols undefined
4.6.5 (with audio-api@0.9.3)	0
4.6.6 (with audio-api@0.12.2)	6

The 6 undefined symbols in 4.6.6 map 1:1 to the PMR usage in BoundedPriorityQueue.hpp:

__ZNSt3__13pmr15memory_resourceD2Ev                   → ~memory_resource()
__ZNSt3__13pmr20null_memory_resourceEv                → null_memory_resource()
__ZNSt3__13pmr28unsynchronized_pool_resource7releaseEv → release()
__ZNSt3__13pmr28unsynchronized_pool_resourceC1ERK*    → ctor
__ZTVNSt3__13pmr25monotonic_buffer_resourceE          → vtable monotonic_buffer_resource
__ZTVNSt3__13pmr28unsynchronized_pool_resourceE       → vtable unsynchronized_pool_resource

Reproduces on:

• iPhone 8 iOS 15.7 (real device, QA)
• iPhone 8 iOS 16.7 (real device, QA)
• iPhone 7 iOS 15.8.8 (customer report — App Store actually started serving the previous version 4.6.5 instead of 4.6.6, since the App Store detects the incompatible binary)
• iOS 15.5 simulator (matches your repro environment)

Request

Would it be possible to:

• Land @joluet's patch (or similar PMR removal/gating) and cut a 0.12.3 / 0.13.0 patch release?
• Add a CI smoke job that builds and launches the example app on an iOS 15.x simulator — this would have caught both this issue and iOS 26 AVAudioSession constants used without availability guards in v0.12.x break iOS builds with deployment targets <26 #1049 before release.

Happy to test a pre-release if helpful. Thanks for the great library otherwise!

[mdydek]

We would like to not exclude pmr containers from the build, I'm more a fan of "providing a fallback STL implementation for older iOS runtimes". Probably will come back in a few days with PR, you are also welcome to make contribution with this implementations :)