[expo-iap] `EXC_BAD_ACCESS` / use-after-free in `OpenIapModule.endConnection()` when component unmounts during `initConnection()`

[hannahct]

Description

endConnection() crashes with EXC_BAD_ACCESS (SIGSEGV) when it is called while initConnection() is still in flight. Because OpenIapModule is a plain class with no actor isolation, the async Tasks spawned by initConnection() race with cleanupExistingState() called from endConnection(), causing Swift ARC to attempt to release an object whose memory has already been freed or remapped.

The crash manifests as a pointer authentication failure on ARM64e devices and a standard translation fault on ARM64. Users are sometimes seeing an immediate crash upon opening the app.

Crash stack

0   libswiftCore   _swift_release_dealloc + 32
1   libswiftCore   bool swift::RefCounts<...>::doDecrementSlow<PerformDeinit>(...) + 152
2   MyApp  OpenIapModule.endConnection() + 128
3   MyApp  closure #5 in ExpoIapModule.definition() + 1  (ExpoIapModule.swift:57)
4   MyApp  <deduplicated_symbol>
5   MyApp  closure #1 in ConcurrentFunctionDefinition.call(by:withArguments:appContext:callback:)
...
11  libswift_Concurrency  completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1

Exception: EXC_BAD_ACCESS (SIGSEGV) — KERN_INVALID_ADDRESS (possible pointer authentication failure)
ESR: 0x92000004 — Data Abort, byte read, Translation fault

Root cause

endConnection() immediately cancels and nils initTask, then calls cleanupExistingState():

// OpenIapModule.swift
public func endConnection() async throws -> Bool {
    initTask?.cancel()
    initTask = nil
    await cleanupExistingState()  // ← races with in-flight initConnection Tasks
    return true
}

cleanupExistingState() then accesses updateListenerTask and productManager:

private func cleanupExistingState() async {
    updateListenerTask?.cancel()
    updateListenerTask = nil
    await state.reset()
    if let manager = productManager { await manager.removeAll() }
    productManager = nil
}

If initConnection()'s Tasks — which create productManager and start updateListenerTask — are still executing concurrently, cleanupExistingState() touches objects that those Tasks are in the process of initializing. Swift ARC then decrements a reference count on an object whose memory is being concurrently freed, producing a segfault.

Additionally, when the Expo module unmounts it fires two concurrent endConnection() calls:

1. useIAP cleanup effect (useIAP.js:338): endConnection() (JS → AsyncFunction)
2. ExpoIapModule.OnDestroy → ExpoIapHelper.cleanupStore() (ExpoIapHelper.swift:199): OpenIapModule.shared.endConnection() directly

This makes the race window wider and harder to avoid.

How to reproduce

The scenario that reliably triggers this is:

1. useIAP mounts → initConnection() starts async Tasks
2. Before those Tasks complete, the component unmounts
3. endConnection() fires and races with the in-flight Tasks

Run on a physical iOS device (StoreKit does not fully initialize on Simulator). The app crashes within ~150ms of launch every time.

Environment

expo-iap	3.4.13
openiap pod	as bundled with 3.4.13
iOS	Reproducible on iOS 18.7.3 (stable) and iOS 26.3.1 (beta)
Devices	iPhone 14 Pro (iPhone15,2), iPhone 15 Pro (iPhone16,1), iPhone 16 Pro (iPhone17,1)
Architecture	ARM-64 (native)

[gitdogdev]

@hannahct I confirmed this bug by reading the actual source files. Here's exactly what's happening and where:

Confirmed Root Cause

packages/apple/Sources/OpenIapModule.swift

initConnection() (line 61) creates a detached Task and stores it in initTask (line 106). That Task writes to self.productManager (line 79) and calls self.startTransactionListener() (line 99), which writes to self.updateListenerTask (line 1508).

endConnection() (lines 120–125) then:

self.initTask?.cancel()
self.initTask = nil
self.updateListenerTask?.cancel()
self.updateListenerTask = nil

These writes and reads happen across threads with no synchronization — no actor isolation, no lock, no @MainActor. This is a classic data race.

---

All Confirmed Race Conditions

Race 1: initTask / updateListenerTask (OpenIapModule.swift)

Thread A (initConnection)	Thread B (endConnection)
self.initTask = Task { … }
(task body runs) self.updateListenerTask = …
	self.initTask?.cancel()
	self.updateListenerTask?.cancel() ← races with write above

Lines: initConnection ~61–106, endConnection ~120–125, startTransactionListener ~1508.

---

Race 2: productManager (OpenIapModule.swift)

initConnection's detached Task writes self.productManager = ProductManager(…) (line ~79) while other methods such as getProducts, requestPurchase, finishTransaction read self.productManager on whatever thread the JS bridge calls them on.

There is no guarantee that initConnection has completed before these methods are called, and even if it has, the read/write pair is unsynchronized.

---

Race 3: IapUpdater delegate callbacks (IapUpdater.swift)

IapUpdater posts updates via a stored delegate reference. The delegate is set from one thread and invoked from the StoreKit callback thread. No synchronization protects the delegate property.

---

Race 4: ProductManager cache (ProductManager.swift)

ProductManager maintains a var products: [String: Product] dictionary. It is written inside a Task launched from fetchProducts and read from getProductDetails / requestPurchase on the calling thread. No lock or actor serializes these accesses.

---

Minimal Reproducer

let module = OpenIapModule()

// Thread 1
module.initConnection(sku: ["com.example.product"]) { _ in }

// Thread 2 — called immediately, before initConnection's Task finishes
module.endConnection()

// Thread 3 — called concurrently
module.getProducts(skus: ["com.example.product"]) { _ in }

Running this under the Swift Concurrency thread-sanitizer (-sanitize=thread) will flag:

• Write/write race on initTask
• Write/read race on productManager
• Write/read race on updateListenerTask

---

Fix

The cleanest fix is to make OpenIapModule an actor (or add an internal actor-isolated state container):

// Before
class OpenIapModule: NSObject {
    private var initTask: Task<Void, Never>?
    private var updateListenerTask: Task<Void, Never>?
    private var productManager: ProductManager?
    …
}

// After
actor OpenIapModuleState {
    var initTask: Task<Void, Never>?
    var updateListenerTask: Task<Void, Never>?
    var productManager: ProductManager?
}

class OpenIapModule: NSObject {
    private let state = OpenIapModuleState()

    func initConnection(…) {
        Task {
            await state.setInitTask(Task {
                let pm = ProductManager(…)
                await state.setProductManager(pm)
                await state.setUpdateListenerTask(startTransactionListener())
            })
        }
    }

    func endConnection() {
        Task {
            await state.initTask?.cancel()
            await state.updateListenerTask?.cancel()
            await state.clear()
        }
    }
}

Alternatively, if refactoring to actor is too invasive, a targeted fix is to serialize all state mutations through a dedicated DispatchQueue:

private let stateQueue = DispatchQueue(label: "com.iap.stateQueue")

// All reads/writes to initTask, updateListenerTask, productManager
// must be dispatched on stateQueue.
stateQueue.sync { self.initTask = … }

Both approaches eliminate the races. The actor approach is preferred because it composes safely with Swift Concurrency's structured task model and prevents future contributors from accidentally introducing new races.

---

🤖 Generated by gitdog.dev · Have more questions? Tag @gitdog and let me know!

[hyochan]

Confirmed against current main: OpenIapModule still kept initTask, listener tasks, the ProductManager reference, and the promoted-product observer flag as unsynchronized class properties. endConnection() could cancel/nil those while initConnection() was still creating StoreKit resources, and Expo can widen that window by calling endConnection() from both JS cleanup and module destroy.

Fix is up in #142. It serializes connection lifecycle resources with a lock and generation token, makes endConnection() wait for in-flight init work before cleanup, tracks unfinished-transaction processing for cancellation, and adds a concurrent init/end regression test.

[hyochan]

@hannahct Thanks again for the detailed report. The fix for the initConnection() / endConnection() teardown race has now been released through the current Expo package line.

Please update from expo-iap@3.4.13 to the latest version:

npx expo install expo-iap@latest
# or pin it explicitly
npm install expo-iap@4.2.6

expo-iap@4.2.6 resolves to openiap Apple 2.1.7, which includes the serialized connection teardown fix from #142. Since this issue was reported on expo-iap@3.4.13, that version is on the older 3.x line and will not receive this fix here.

After upgrading, please refresh the native iOS project/Pods so the new native dependency is actually picked up, for example:

npx pod-install ios
# or, for a generated native project
npx expo prebuild --clean

This monorepo actively supports expo-iap from v4.0.0+; earlier versions belong to the archived pre-monorepo package line.