[iOS] Screen with Qonversion imported crashes

[XChikuX]

I added several new subscription tiers to android and apple recently and I was surprised to find that my subscription screen on iOS was crashing after.

Android seemed to be fine, so I suspected it was Qonversion. I use exactly 2 packages that have a native layer react-native-pager-view and react-native-qonversion. Adding this info just in case there is a problem with the interop.

My Subscription page was working flawlessly on 10.1.1 with one subscription and one lifetime offering.

So it is an issue introduced between 10.2.0 and latest. Although I suspect it is in the 10.3.x versions

I am attempting a new build with the older version again. Will keep you posted. Even if I messed up my Apple IAP. I don't think Qonversion should crash like this.

I am unable to debug further, due to the fact that I am on windows, However
I sent this build to the apple review team and got back these crash logs:

crashlog-D881916C-DEDE-4DB2-905D-97CBE5FCAE8E.txt
crashlog-2E5E4218-C8CB-4D78-BDD1-CC30E6F05845.txt
crashlog-89EE632D-48D9-4F7E-968F-A8E93AAF2B2D.txt
crashlog-D917DE16-B8D7-4151-A2E9-1DC2F26433FE.txt
crashlog-DE379446-7808-4632-82D5-400FF12074B5.txt
crashlog-FAD24B65-D0D8-4D41-9F10-C51D8ACA832C.txt
crashlog-02E17AD3-189D-4FE2-B477-75C0EA95F16C.txt
crashlog-D835FB4E-9A1A-4A8E-9024-C53B7A0398A4.txt

Qonversion: latest
Expo: SDK 54
iOS: 18.7.4

[XChikuX]

Some AI Debugging. It may help...

Summary of Crash Patterns

---

Crash Type 1 — SIGABRT on com.meta.react.turbomodulemanager.queue

This is the primary crash and the one most likely tied to react-native-qonversion. The faulting thread is always com.meta.react.turbomodulemanager.queue and the call stack is identical across these logs:

pthread_kill
  → abort
    → demangling_terminate_handler
      → _objc_terminate
        → std::terminate
          → __cxa_rethrow
            → objc_exception_rethrow      ← ❗ Key frame
              → invocation function for block in 
                facebook::react::ObjCTurboModule::performVoidMethodInvocation(...)

What is happening:
Qonversion's native iOS TurboModule method (an async void method, likely something like purchaseProduct or checkEntitlements) throws an NSException internally. React Native's RCTTurboModule.mm catches that exception and calls throw convertNSExceptionToJSError(...) — but because the method is async, there is nothing on the call stack that can catch a C++ exception. This causes std::terminate → SIGABRT.

This is a known React Native New Architecture bug in RCTTurboModule.mm (tracked in facebook/react-native#54859 and fixed in RN 0.79.0-rc.3+ via PR #50193). The fix makes the exception re-throw conditional: only rethrow for sync TurboModule methods, not async ones.

---

Crash Type 2 — EXC_BAD_ACCESS (SIGSEGV) on the Main Thread

These are crashes at address 0x0000000000000018 — a null/near-null pointer dereference:

EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x18
  → -[RCTComponentViewFactory createComponentViewWithComponentHandle:]
    → -[RCTComponentViewRegistry dequeueComponentViewWithComponentHandle:tag:]
      → facebook::react::MountingCoordinator::pullTransaction(...)
        → -[RCTMountingManager performTransaction:]

What is happening:
When Qonversion's async callback attempts to update state (e.g., an entitlement result triggers a re-render of the subscription screen), it initiates a React Native Fabric mounting transaction on the JS thread. However, a component view descriptor has already been unmounted or its native component handle is unregistered/nil — so RCTComponentViewFactory dereferences a null pointer trying to create/dequeue a native view. This is a race condition between Qonversion's async callback resolving and the component unmounting.

---

Fix Recommendations

Short-term: Guard against unmounted component updates (fixes Crash Type 2)

Wrap your Qonversion callback in an isMounted ref:

const isMounted = useRef(true);

useEffect(() => {
  return () => { isMounted.current = false; };
}, []);

const handlePurchase = async () => {
  const result = await Qonversion.purchaseProduct(product);
  if (!isMounted.current) return; // ← guard
  setEntitlement(result);
};

Short-term: Wrap Qonversion calls in try/catch (contains Crash Type 1)

try {
  await Qonversion.checkEntitlements();
} catch (e) {
  console.warn('Qonversion error:', e);
}

This won't fully prevent the native NSException, but at the JS level, it prevents unhandled rejection chains that can compound the crash.

Medium-term: Upgrade React Native (fixes Crash Type 1 at the root)

The RCTTurboModule.mm async void rethrow bug is fixed in RN ≥ 0.79.0-rc.3 (backported to 0.76, 0.77, 0.78). Upgrading will stop the SIGABRT from async TurboModule exceptions entirely.

Medium-term: Patch RCTTurboModule.mm directly (if you can't upgrade yet)

Apply the fix from the React Native core team:

// In RCTTurboModule.mm — find performVoidMethodInvocation
if (isSync) {
  @try {
    [inv invokeWithTarget:strongModule];
  } @catch (NSException *exception) {
    throw convertNSExceptionToJSError(runtime, exception);
  } @finally {
    [retainedObjectsForInvocation removeAllObjects];
  }
} else {
  @try {
    [inv invokeWithTarget:strongModule];
  } @finally {  // ← no @catch, no rethrow for async
    [retainedObjectsForInvocation removeAllObjects];
  }
}

[XChikuX]

Build on 10.1.1 of Qonversion is also failing. This is definitely from the RN Turbo Modules side.

However, we should keep this open so that.

Qonversion may add @try/@catch guards around calls to the Swift implementation layer. Adding defensive exception handling in the bridge would prevent NSExceptions from reaching RCTTurboModule.mm's crash-prone handler — regardless of whether React Native fixes the upstream bug.

[XChikuX]

Hey @suriksarkisyan. This issue has been open for quite sometime and is a real blocker for my project. Could we please take a look?

[NickSxti]

Hi @XChikuX, thank you for the detailed report and crash analysis!

We've investigated this and confirmed your findings:

1. This is a known React Native New Architecture bug in RCTTurboModule.mm where async void TurboModule methods rethrow NSExceptions as C++ exceptions on a GCD background queue with no catch handler, leading to std::terminate → SIGABRT.
2. Our iOS native layer currently lacks @try/@catch guards.
   We'll add @try/@catch exception handling in the bridge layer to prevent NSExceptions from reaching performVoidMethodInvocation.
   This will cover both async void and promise-based methods.

In the meantime, as a workaround, you can try:

• Switching to the Old Architecture (newArchEnabled: false) if feasible for your project
• Patching RCTTurboModule.mm locally to replace the throw with RCTLogError in performVoidMethodInvocation (as described in the upstream PR)
  We'll update this issue when the fix is released.

[github-actions]

This issue is stale because it has been open 7 days with no activity. Remove stale label or comment or this will be closed in 5 days.