How can I correctly use expo-iao to purchase iOS subscriptions?

[konson-git]

I switched from react-native-iap to expo-iap, but I still don't understand how to use this library correctly. I'm sure I've read the documentation, but I haven't gotten what I want, so I have a few questions. I would be very grateful if someone could help me 🙏.

1. If I have multiple payment entry points, such as a guide page and a paywall page, should I use the onPurchaseSuccess callback of useIAP on each page to listen for successful subscriptions, or should I only implement it in a place like _layout.tsx?

2. How do I restore subscription purchases on iOS? I tried using getActiveSubscriptions and hasActiveSubscriptions methods, but neither retrieves a valid subscription record. The hasActiveSubscriptions method works, but I'm unsure if I should use it to restore subscription purchases.

[hyochan]

@konson-git Thanks for the question! Please check below!

1. Where to implement useIAP

You can use useIAP on any screen where you need purchase functionality:

// Paywall.tsx
function PaywallScreen() {
  const {requestPurchase} = useIAP({
    onPurchaseSuccess: (purchase) => {
      // Handle subscription activation
      updateUserSubscriptionStatus(purchase);
    },
    onPurchaseError: (error) => {
      // Handle errors
    }
  });

  // Purchase logic here
}

Note: useIAP automatically cleans up listeners when the component unmounts, so you don't need to manage it manually.

You can also implement listeners globally in _layout.tsx if you prefer centralized handling.

2. Restoring purchases on iOS

For subscriptions only

Use getActiveSubscriptions():

const {getActiveSubscriptions} = useIAP();

const restoreSubscriptions = async () => {
  const activeSubscriptions = await getActiveSubscriptions();
  // activeSubscriptions state is also updated automatically
};

For all purchases (subscriptions + consumables/non-consumables)

Use getAvailablePurchases():

const {getAvailablePurchases, availablePurchases} = useIAP();

const restoreAllPurchases = async () => {
  await getAvailablePurchases();
  // Check availablePurchases state for all restored items
};

Example implementation

See the example app for reference:

• available-purchases.tsx:141 - Loading both subscriptions and purchases
• purchase-flow.tsx:680 - Restore button implementation

[konson-git]

Thank you so much for your reply, it was very helpful!

However, there seems to be something wrong with restoring subscriptions in my code.
In the handleRestorePurchases method, I called three methods simultaneously: hasActiveSubscriptions, getActiveSubscriptions, and getAvailablePurchases. The specific code and return values ​​are as follows:

const handleRestorePurchases = useCallback(async () => {
  const hasActiveSubs = await hasActiveSubscriptions();
  await getActiveSubscriptions();
  await getAvailablePurchases();

  console.log('hasActiveSubs', hasActiveSubs); // result: true
  console.log('activeSubscriptions', activeSubscriptions); // result: []
  console.log('availablePurchases', availablePurchases); // result: []

}, [hasActiveSubscriptions, getActiveSubscriptions, getAvailablePurchases, activeSubscriptions, availablePurchases])

And I'm sure I just subscribed.
hope to get your answer, thank you.🙏

[hyochan]

@konson-git The issue you're experiencing is related to React state update timing. When you call the methods and immediately log the state variables, you're seeing the old values captured in the closure, not the updated ones.

The getActiveSubscriptions() method returns the active subscriptions array, so use the returned value instead of reading the state immediately:

const handleRestorePurchases = useCallback(async () => {
  const hasActiveSubs = await hasActiveSubscriptions();
  const activeSubs = await getActiveSubscriptions(); // ✅ Use the return value
  await getAvailablePurchases();

  console.log('hasActiveSubs', hasActiveSubs);
  console.log('activeSubscriptions from return', activeSubs); // ✅ This will show the data
  
  // The state will also be updated, but asynchronously
}, [hasActiveSubscriptions, getActiveSubscriptions, getAvailablePurchases]);

[WillyReyno]

I'm currently working on adding the ability to restore purchases to my app and found this discussion. I have a similar issue as konson-git where I can't log the restored purchases.

@hyochan I tried your above code, here's what I'm getting from the two console logs:

hasActiveSubs true
activeSubscriptions from return undefined

When I checked the code for getActiveSubscriptions there's no indication that it should return an active subscriptions array, instead it returns a void promise:

 getActiveSubscriptions: (subscriptionIds?: string[]) => Promise<void>;

When double-checking the getActiveSubscriptionsInternal function, it's also clear that it's not returning anything, it's simply calls setActiveSubscriptions and nothing else.

const getActiveSubscriptionsInternal = useCallback(
    async (subscriptionIds?: string[]): Promise<void> => {
      try {
        const result = await getActiveSubscriptions(subscriptionIds);
        setActiveSubscriptions(result);
      } catch (error) {
        ExpoIapConsole.error('Error getting active subscriptions:', error);
        // Preserve existing state on error
      }
    },
    [],
  );

I also tried the code from your documentation, availablePurchases is empty the first time I call restorePurchases(), but is properly listing purchases on the second call.

[hyochan]

useIAP is designed to work with React state, not return values. I've updated the code and documentation to clarify this.

Correct Usage

❌ Wrong - Reading state immediately after calling the method

const {getActiveSubscriptions, activeSubscriptions} = useIAP();

const handleRestore = async () => {
  await getActiveSubscriptions();
  console.log(activeSubscriptions); // ❌ May show old/empty state (React state update timing)
};

✅ Correct - Use useEffect to react to state changes

const {getActiveSubscriptions, activeSubscriptions} = useIAP();

useEffect(() => {
  if (activeSubscriptions.length > 0) {
    console.log('Active subscriptions:', activeSubscriptions);
  }
}, [activeSubscriptions]); // React to state changes

const handleRestore = async () => {
  await getActiveSubscriptions(); // State will update, triggering useEffect
};

✅ Alternative - Use root API for immediate return values

import {getActiveSubscriptions} from 'expo-iap';

const handleRestore = async () => {
  const activeSubs = await getActiveSubscriptions();
  console.log('Active subscriptions:', activeSubs); // ✅ Immediate value
};

Why This Happens

React state updates are asynchronous. When you call getActiveSubscriptions(), it updates the state, but you won't see the new value until the next render cycle. This is why:

• First call: activeSubscriptions is empty (old state)
• Second call: activeSubscriptions has data (state from first call)

Use useEffect to subscribe to state changes, or use the root API if you need immediate values.

---

Note: Only hasActiveSubscriptions() returns a value in the hook (boolean). All other methods like fetchProducts, getAvailablePurchases, getActiveSubscriptions return Promise<void> and update state asynchronously.

[Navipro70]

Hello @hyochan I've read all the answers, and now migrating from v2 to v3 and want to rewrite the whole code with useIAP hook as your doc mention it's a recommended way. But I got stuck with misleading useIAP usage hook, so as I understood from the thread - we can use it for any specific purchase in certain payment screen, but as I know we need to have minimum 1 global listener because backend will send us renewals and other sub events which we must process.

So also if we will have 2+ useIAP listeners - they will race and for example global will handle purchase first and finish and local (paywall) listener won't handle purchase and user will stay on Paywall. My point - to make clear world usage example how to handle purchases correctly with navigation flow and why 2 listeners should work

[hyochan]

@Navipro70 Your concern about race conditions with multiple useIAP listeners is valid.

The Issue

Each useIAP instance registers its own independent purchaseUpdatedListener. When a purchase completes:

1. All listeners receive the same purchase event
2. The first listener to call finishTransaction() completes the transaction
3. Other listeners may receive an already-finished or invalid transaction state

Recommended Pattern

Use a single useIAP in your top-level container (e.g., _layout.tsx):

// _layout.tsx
export default function RootLayout() {
  const {
    products,
    subscriptions,
    requestPurchase,
    fetchProducts,
  } = useIAP({
    onPurchaseSuccess: (purchase) => {
      // Centralized purchase handling
    },
    onPurchaseError: (error) => {
      // Centralized error handling
    },
  });

  return (
    <Stack>
      {/* Child screens access IAP data via props or navigation params */}
    </Stack>
  );
}

Pass the necessary IAP state and methods down to child screens via props, navigation params, or a simple context if needed. The key point is to have only one useIAP instance registering the purchase listener.

[Navipro70]

@hyochan
Hey, thank you for your reply!

As I see in source code of useIAP.ts, this hook uses local states and initialize lots at the mounting. I think using it in several places not a best practice even with single onPurchaseSuccess at top-level

Maybe to fix that it will be better to rewrite it with React Context Provider, so we can initialize useIAP at the top-level and then use single data and methods to manage subscriptions. What do you think?

[hyochan]

@Navipro70 That's exactly what I'm recommending - call useIAP once at top-level and pass props down. You don't need a Context Provider for that.

Context Provider wouldn't solve any re-render issues either - it can actually make them worse since all consumers re-render when context value changes.

The library intentionally stays lightweight without forcing a specific state management pattern. If you prefer Context, you can wrap useIAP yourself in ~10 lines of code.

[Navipro70]

Clear answer, thank you