promotedProductListenerIOS and getPromotedProductIOS both fail to fire on cold start

[zhangsn]

Bug Report

Description

When a user taps a promoted in-app product in the App Store and the app is cold started (not running in background), neither promotedProductListenerIOS callback nor getPromotedProductIOS() return any product — the callback is never triggered and getPromotedProductIOS() returns null.

The promotedProductListenerIOS callback does fire correctly when the app is resumed from background.

Steps to Reproduce

1. Set up a promoted in-app purchase product in App Store Connect.
2. Use a StoreKit configuration file or a direct App Store promoted product link (itms-apps://...?action=purchaseIntent&productIdentifier=xxx) to simulate a promoted product tap.
3. Ensure the app is fully terminated (cold start scenario).
4. Tap the promoted product link.
5. Observe that neither onPromotedProductIOS (via useIAP) nor promotedProductListenerIOS fires, and getPromotedProductIOS() returns null.

Code Sample

// None of these work on cold start:

// Approach 1 - useIAP hook callback
useIAP({
  onPromotedProductIOS: (product) => {
    console.log('never called on cold start', product);
  },
});

// Approach 2 - standalone listener
useEffect(() => {
  const subscription = promotedProductListenerIOS((product) => {
    console.log('never called on cold start', product);
  });
  return () => subscription.remove();
}, []);

// Approach 3 - polling after mount
useEffect(() => {
  (async () => {
    const product = await getPromotedProductIOS();
    console.log('always null on cold start', product); // null
  })();
}, []);

Expected Behavior

At least one of the above APIs should reliably deliver the promoted product info when the app is cold-started from a promoted product tap in the App Store.

Environment

expo-iap version	4.2.4
Expo SDK	~54
React Native	0.79+
Platform	iOS
Device	Physical device
Xcode	16+

---

[gitdogbot]

@zhangsn ## Root Cause: Cold-Start Promoted Product Not Captured

I read packages/apple/Sources/OpenIapModule.swift and found the exact issue.

What the code does

In performInitConnection() (lines 1410–1418), the SKPaymentQueue observer is registered lazily, only when initConnection() is called:

SKPaymentQueue.default().add(self)

This means if iOS presents a promoted in-app purchase (via SKPaymentQueue.default().delegate / paymentQueue(_:shouldAddStorePayment:for:)) before the app calls initConnection(), the observer is not yet registered and the transaction is silently dropped.

The specific flow that fails

1. User taps "Buy" on the App Store product page (promoted IAP).
2. iOS launches (or foregrounds) the app and immediately calls paymentQueue(_:shouldAddStorePayment:for:).
3. The React Native JS bundle has not yet loaded, so initConnection() has not been called.
4. Because SKPaymentQueue.default().add(self) hasn't run yet, OpenIapModule is not an observer.
5. The delegate method is never fired, the payment is never continued, and the purchase is lost.

---

Evidence in the Code

performInitConnection() — observer registered too late

// packages/apple/Sources/OpenIapModule.swift  lines 1410–1418
@objc public func performInitConnection(
    withOptions options: [String: Any]?,
    resolve: @escaping RCTPromiseResolveBlock,
    reject: @escaping RCTPromiseRejectBlock
) {
    // ...
    SKPaymentQueue.default().add(self)   // ← only happens here
    resolve(nil)
}

paymentQueue(_:shouldAddStorePayment:for:) — never reached on cold start

// packages/apple/Sources/OpenIapModule.swift  lines ~1480–1495
public func paymentQueue(
    _ queue: SKPaymentQueue,
    shouldAddStorePayment payment: SKPayment,
    for product: SKProduct
) -> Bool {
    // Store the payment and emit an event so JS can decide
    promotedProduct = product
    promotedPayment = payment
    sendEvent(withName: IapEvent.promotedProduct.rawValue, body: product.productIdentifier)
    return false   // deferred — JS must call getPromotedProduct + buyProduct
}

Because the observer was never added, this method is never invoked on a cold-start promoted purchase.

---

Fix

Option A — Register the observer at module init time (minimal change)

Move SKPaymentQueue.default().add(self) from performInitConnection() into the module's init / setup so the observer is registered as soon as the native module is instantiated, which happens well before JS loads.

// In the module's initializer or +load equivalent
override init() {
    super.init()
    SKPaymentQueue.default().add(self)   // register early
}

Then in performInitConnection(), guard against double-registration:

@objc public func performInitConnection(...) {
    // Observer already added in init(); nothing to do here for the queue.
    // Keep the rest of the setup (product request caches, etc.)
    resolve(nil)
}

Note: You must also call SKPaymentQueue.default().remove(self) in deinit / invalidate to avoid a dangling observer.

Option B — Cache the promoted payment and replay it after initConnection() (safer for deferred-purchase flow)

Keep the lazy registration and add an early AppDelegate-level hook that stores the promoted payment before the module is ready, then replays it once initConnection() fires.

Step 1 — AppDelegate.swift

// AppDelegate.swift
import StoreKit

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate, SKPaymentTransactionObserver {

    var pendingPromotedPayment: SKPayment?
    var pendingPromotedProduct: SKProduct?

    func application(_ application: UIApplication,
                     didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        SKPaymentQueue.default().add(self)   // register ASAP
        // ... rest of setup
        return true
    }

    // Capture the promoted purchase before RN is ready
    func paymentQueue(_ queue: SKPaymentQueue,
                      shouldAddStorePayment payment: SKPayment,
                      for product: SKProduct) -> Bool {
        pendingPromotedPayment = payment
        pendingPromotedProduct = product
        // Return false — we will resume it manually via OpenIapModule
        return false
    }

    func paymentQueueRestoreCompletedTransactionsFinished(_ queue: SKPaymentQueue) {}
    func paymentQueue(_ queue: SKPaymentQueue, updatedTransactions transactions: [SKPaymentTransaction]) {}
}

Step 2 — Replay inside performInitConnection()

@objc public func performInitConnection(...) {
    SKPaymentQueue.default().add(self)

    // Replay any promoted purchase that arrived before JS was ready
    if let appDelegate = UIApplication.shared.delegate as? AppDelegate,
       let product = appDelegate.pendingPromotedProduct,
       let payment = appDelegate.pendingPromotedPayment {
        promotedProduct = product
        promotedPayment = payment
        appDelegate.pendingPromotedPayment = nil
        appDelegate.pendingPromotedProduct = nil
        sendEvent(withName: IapEvent.promotedProduct.rawValue, body: product.productIdentifier)
    }

    resolve(nil)
}

This way JS receives the iap-promoted-product event immediately after calling initConnection(), exactly as it would for a warm-start promoted purchase.

---

Recommended Approach

Option B is the safer production fix because:

• It preserves the existing deferred-purchase contract that JS already handles.
• It does not change when SKPaymentQueue observers are active for normal purchases.
• It survives edge cases where the module is torn down and re-created (e.g., RN dev reloads).

Option A alone is simpler but can cause duplicate observer registrations if initConnection() is called more than once without a matching endConnection().

---

Testing the Fix

1. Unit test — Mock SKPaymentQueue and assert that paymentQueue(_:shouldAddStorePayment:for:) is invoked and promotedProduct / promotedPayment are set when the observer is registered before the delegate fires.
2. Integration test — Use the StoreKit Configuration file in Xcode (*.storekit) with the "Interrupted Purchases" scenario to simulate a promoted IAP on cold start.
3. Manual test — On a real device, use the itms-services:// deep-link trick:

   itms-services://?action=purchaseIntent&bundleId=YOUR_BUNDLE_ID&productIdentifier=YOUR_PRODUCT_ID
   

   Force-quit the app first, tap the link, and verify the iap-promoted-product event fires in JS after initConnection().

---

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

[hyochan]

Resolved in PR #144

The fix registers the iOS promoted purchase observer during native module launch, so cold-start App Store promoted IAP intents are captured before JS calls initConnection, and pending promoted products are replayed to promotedProductListenerIOS/getPromotedProductIOS.

Verification:

• Reproduced and validated the flow with the expo-iap example app on a physical iPad.
• Installed/launched the app with bundle ID dev.hyo.martie and promoted product ID dev.hyo.martie.premium.
• Fully terminated the app, then opened the promoted IAP purchase-intent URL from the iPad browser.
• Confirmed the app cold-started and the example received the promoted IAP event.
• Verified the fix with local Apple Swift tests, expo-iap typecheck/tests, docs build, example tests, and SDK parity audit.
• Confirmed PR fix(ios): handle promoted iap cold start #144 CI is green, including Expo lint/test, iOS tests, docs tests, and SDK parity.

Once the next versions are released, please upgrade and retest with the new packages. Expected patch releases are openiap-apple 2.1.7 and expo-iap 4.2.7. Thanks again for the clear reproduction.