Adding App Store Promoted In-App Purchases to a Rork App

Receiving the deferred purchase with react-native-iap

A standard Rork app is generated as React Native (Expo), so the practical approach is to bring a native module like react-native-iap into a development build. With promoted IAPs, the key is registering the purchase listener as early as possible during startup. If listener registration is late, you'll drop the event that arrives on a cold launch.

// promotedPurchase.ts — call this at the very start of app launch
import {
  initConnection,
  getPromotedProductIOS,
  requestPurchaseOnPromotedProductIOS,
  promotedProductListenerIOS,
} from 'react-native-iap';
 
// Let the readiness check be injected from outside
type ReadyCheck = () => boolean;
 
let pendingPromoted = false;
 
export async function setupPromotedPurchase(isReady: ReadyCheck) {
  await initConnection();
 
  // Fires when a promoted purchase arrives from the App Store
  promotedProductListenerIOS(async () => {
    pendingPromoted = true;
    await tryConsumePromoted(isReady);
  });
 
  // Guard against an event that already arrived on cold launch
  const promoted = await getPromotedProductIOS();
  if (promoted) {
    pendingPromoted = true;
    await tryConsumePromoted(isReady);
  }
}
 
// Run the purchase if ready; otherwise keep it held and return
export async function tryConsumePromoted(isReady: ReadyCheck) {
  if (!pendingPromoted) return;
  if (!isReady()) return; // keep holding if login/init is incomplete
 
  pendingPromoted = false;
  await requestPurchaseOnPromotedProductIOS();
}

The point is to make tryConsumePromoted callable from two places: once when the event arrives, and once "the moment you become ready." Calling the same function after login or after onboarding lets a held purchase resume naturally at that point.

// Resume a held purchase when login completes
async function onLoginSuccess() {
  await tryConsumePromoted(() => true);
}

The "ready" definition that holds it all together

This is the core of the design. How you define "ready" shapes the user's experience. What I settled on in practice was proceeding only when all three of these conditions are met.

Keeping the event in pendingPromoted until all three are met was the most reliable way to avoid drops. That said, holding state only in memory means it's gone if the app crashes. Calling getPromotedProductIOS once at startup as a second line of defense covers the cold-launch drop.

With Rork Max (native Swift), receive it via StoreKit 2

Because Rork Max generates native Swift apps, you can receive these through StoreKit 2's PurchaseIntent — a more direct async sequence that waits for purchase intents.

import StoreKit
 
// Start the observation task right after launch
func observePromotedPurchases() {
    Task.detached {
        for await intent in PurchaseIntent.intents {
            await handlePromoted(intent.product)
        }
    }
}
 
func handlePromoted(_ product: Product) async {
    // Wait until ready (e.g., login resolved)
    await AppReadiness.shared.waitUntilReady()
    do {
        let result = try await product.purchase()
        await fulfill(result) // grant entitlement
    } catch {
        // Don't swallow network errors or cancellations — record them
        Telemetry.log("promoted_purchase_failed", error)
    }
}

The StoreKit 1 "return false to defer" behavior of shouldAddStorePayment is replaced in StoreKit 2 by a straightforward wait: receive the intent, then wait until ready. Rork Max generates the scaffolding of this observation task, but what goes inside waitUntilReady and how you record failures is the part you finish yourself.

Points that tend to get flagged in review and measurement

Promoted IAPs are inspected during App Store review too. From what I've hit or heard, these are the easy places to stumble.

• Avoid inserting your own paywall after the tap. Apple expects the buyer to purchase the item they chose on the product page. Wedging a custom upsell screen in between can mismatch the intended product and become a rejection reason
• Don't fully block purchases for signed-out users. During review that can read as "can't purchase." Letting a guest buy and binding it to an account later is the safer escape hatch
• Measurement rides the same path as a normal in-app purchase, but tagging whether the entry point was the promoted slot lets you evaluate the product-page conversion later. I attach source: "promoted" to the purchase-complete event and view it separately from regular paywall purchases

As a revenue path, the promoted IAP occupies a unique spot: a purchase touchpoint before the app is opened. You can't pitch as freely as an in-app paywall, but its value is carrying the buying intent of the moment someone lands on your product page from search all the way through to after install. As long as you build the hold-and-resume design carefully, it becomes a quiet revenue route with few drops. I hope it helps with your own implementation.