[Bug] EXC_BAD_ACCESS Fatal Crash in expo-iap ExpoIapModule

[m-szczepanek]

Library

expo-iap

Library version

expo-iap 3.4.9

Affected platform

iOS

Store

Onside (expo-iap only)

Environment

React Native

OS:
iOS 26.6
iOS 26.5.2
iOS 26.5
iOS 18.6.2

Devices:
iPhone 13 Pro Max
iPhone 14 Pro Max
iPhone 16 Pro Max
iPhone 15
iPhone 16

What happened?

App fatal crash after IAP for some users

Expected behavior

No fatal iOS crashes after IAP

Reproduction steps

After IAP purchase

Logs or stack trace

Crash signature

Sentry Log:

EXC_BAD_ACCESS KERN_INVALID_ADDRESS
mechanism: mach  |  handled: no  |  level: fatal  |  origin: ios (native)
Stack:
  closure in ExpoIapModule.definition   ← expo-iap
  ExpoIapHelper.setupStore
  swift::RefCounts<T>::doDecrementSlow  ← Swift ARC decrement
  _swift_release_dealloc
  swift_deallocClassInstance            ← crash: accessing freed object
  objc_destructInstance

doDecrementSlow + swift_deallocClassInstance + KERN_INVALID_ADDRESS is the classic Swift ARC use-after-free fingerprint: an object is being accessed after its memory has been reclaimed.

Possible cause of issue:

@MainActor
public final class ExpoIapModule: Module {
    nonisolated public func definition() -> ModuleDefinition {
        OnCreate {
            Task { @MainActor in          // ← captures `self` STRONGLY
                ExpoIapHelper.setupStore(module: self)
            }
        }
        OnDestroy {
            Task { @MainActor in          // ← captures `self` STRONGLY
                await ExpoIapHelper.cleanupStore()
            }
        }
    }
}

Additional context

No response

[hyochan]

I traced this through the reported 3.4.9 source and the current monorepo implementation.

A strong capture inside Task does not by itself cause use-after-free; it keeps the module alive until the task finishes. However, the lifecycle code did have a concrete replacement race: ExpoIapHelper owns process-wide listener tokens, while OnCreate and OnDestroy schedule unstructured tasks. A stale module teardown could therefore run after a replacement module installed its listeners, clear the replacement state, and race its shared connection startup.

#335 scopes listener teardown to the generation that installed it, makes replacement initialization wait for pending connection cleanup, and avoids retaining standard or Onside modules through the stored lifecycle definitions. It adds regression coverage and passes iOS Simulator builds with both standard StoreKit and OnsideKit 0.7.5.

Fix is up in #335.

The reported expo-iap 3.4.9 predates this monorepo supported Expo line. Please retest with the current supported release after the fix lands. If the crash persists, a fully symbolicated Sentry stack and the Expo SDK version will help distinguish any remaining native SDK fault.

Note: This repository (OpenIAP monorepo) handles development for all framework libraries from the versions listed below. For earlier versions, refer to the archived individual repositories.

• react-native-iap v15.0.0+
• expo-iap v4.0.0+
• flutter_inapp_purchase v9.0.0+
• godot-iap v2.0.0+
• kmp-iap v2.0.0+

[hyochan]

expo-iap 5.3.1 is now published with the serialized iOS lifecycle cleanup from #335. Please retry the affected purchase flow with 5.3.1. If the crash persists, please share your Expo SDK version and a fully symbolicated Sentry stack so we can distinguish any remaining native SDK fault.