fix(ios): avoid iOS 18+ libc++ symbol in makeException when built with Xcode 27

[huextrat]

Fixes #1652

Problem

When NitroModules is built with Xcode 27, the inline makeException helper in ios/utils/RuntimeError.hpp, emitted through the Swift C++ interop build (RuntimeError.swift), references std::exception_ptr::__from_native_exception_pointer(void*). That symbol only exists in the iOS 18+ system libc++, so any app that links NitroModules and still supports iOS < 18 aborts at launch in dyld:

Termination Reason: Namespace DYLD, Code 4, Symbol missing
Symbol not found: __ZNSt13exception_ptr31__from_native_exception_pointerEPv

With Xcode 27 now GA, this is a hard blocker for App Store releases of every app supporting iOS 16/17 (react-native-mmkv, etc.).

Fix

Replace std::make_exception_ptr with the throw/catch fallback, as suggested by @vnahornyi in #1652. It only needs std::current_exception, which links on every supported iOS version. Behaviour is identical: the returned exception_ptr still wraps a std::runtime_error carrying the message, so getExceptionMessage and localizedDescription are unaffected.

Validation

We have been shipping this exact change as a patch on react-native-nitro-modules@0.37.1 for about two weeks: app launches on iOS 16, iOS 17 and iOS 27, built with Xcode 27, no regressions observed.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
nitro-docs	Skipped		Sep 28, 2026 9:41am UTC

[jslok]

Came across this issue and verified the propsed patch works for us. Thanks!

[shellfly]

I'm using react-native-nitro-cookies and react-native-nitro-sound, both of which depend on this library. After applying the changes in this PR, I still got a similar error: Symbol not found: ___cxa_init_primary_exception.

I searched for other uses of std::make_exception_ptr and found it in cpp/core/Promise.cpp and cpp/core/Promise.hpp as well. I made the same changes there to replace std::make_exception_ptr, cleaned and rebuilt the app, and it now runs normally on iOS 17.

// reject(std::make_exception_ptr(std::runtime_error(message)));
try {
  throw std::runtime_error(message);
} catch (...) {
  reject(std::current_exception());
}

So it might be worth modifying these other two places as well in this PR.

Thanks for the code changes! They helped me identify and fix the remaining part of the problem on my side.