Good News: react-native-iap will Continue with NitroModule

[hyochan]

Hello React Native developers,

In the past #2754, I officially announced that I would no longer maintain react-native-iap and instead focus on expo-iap.
That decision was made for several reasons:

• New Architecture Support: At that time, Swift-based modules were not well supported, and Expo Modules offered a much easier path to adopt the New Architecture quickly.
• Ease of Maintenance: As I mentioned in the previous announcement, Expo Modules provide a far more productive developer experience, which allowed me to focus on building features instead of spending too much time on maintenance.
• Industry Direction: With Expo becoming the official framework, it seemed more future-proof to migrate the project fully to Expo Modules rather than keep maintaining a standalone React Native module.

---

However, things have changed recently. With the release of React Native 0.81, issues like #2981 made me rethink the situation. I realized that if a module doesn’t fully target React Native itself, it can cause real inconvenience for developers who rely on the native RN workflow.

At the same time, while working on another library, react-native-audio-recorder-player, I experimented with NitroModule and was very satisfied with the results. On top of that, seeing @mrousavy’s passionate and consistent work on NitroModule gave me confidence that it will be a solid and well-maintained foundation for years to come.

Because of this, I’ve decided to bring NitroModule support to react-native-iap starting from v14. This means that:

• react-native-iap will continue to be maintained alongside expo-iap.
• Developers can now choose whichever library best fits their workflow — whether it’s the Expo ecosystem (expo-iap) or a direct React Native integration (react-native-iap).
• Thanks to the recently announced Open IAP Specification, both libraries will share a seamless API surface, making migration between them straightforward and nearly effortless.

---

🚨 Bad News
Starting from v14, Amazon support will no longer be available.
The reason is simple: I don’t own any Fire OS devices, which makes it impossible to debug and properly maintain Amazon support going forward.

To be honest, I initially thought Fire OS was just Kindle, so I even bought one — only to realize it wasn’t the right device.

Definitely regretting that decision now 😔

---

I’d love to hear your feedback on this plan.
Your thoughts and opinions will help shape the future of both react-native-iap and expo-iap.

Thank you for your continued support!

[zeeshan-shabbir]

@hyochan Awesome, thanks for continuing the maintenance! Do you have an estimated release date for v14?

[hyochan]

@zeeshan-shabbir Thank you for your interest! Hopefully, I like to finish by next week

[Freddy03h]

Thank you very much for listening the community 🙌

I don't know well nitro-module, does that mean it'll be compatible with old architecture or only new one?
As I say in the discussion, I think it's ok to drop old arch, on a new major version, if it's too much work.

[hyochan]

@Freddy03h Nitromodule supports both New Arch and Old Arch - https://nitro.margelo.com/docs/entry-point

[mrousavy]

Nice!

[hyochan]

Finally done in https://github.com/hyochan/react-native-iap/releases/tag/14.0.0

[irekrog]

So from 14.0.0 does react-native-iap officially support the New Architecture? :)

[hyochan]

@irekrog Yes! Powered by Nitromodule from @mrousavy

[Ladeologun]

Good work @hyochan 👏 and thanks for continuing the maintenance of this library!

I also wanted to point out something I noticed in the official documentation site, the docs for the older versions are no longer accessible since they’ve been moved to the new NitroModule-based version. For those of us still on older versions, it makes it a bit difficult to reference the correct setup and APIs.

Would it be possible to include documentation for the older versions alongside the new one? That would really help developers who haven’t migrated yet

[elfstyle]

https://github.com/hyochan/react-native-iap/blob/7d63b3121f3271413966eac5a8d7293031243b49/docs/docs/migrate_to_13.0.0.mdx

[elfstyle]

https://github.com/hyochan/react-native-iap/blob/7d63b3121f3271413966eac5a8d7293031243b49/docs/docs/migrate_to_12.0.0.mdx

[diamont1001]

How about 'flushFailedPurchasesCachedAsPendingAndroid'

[hyochan]

In recent versions of react-native-iap, the method
flushFailedPurchasesCachedAsPendingAndroid has been removed.

Its original purpose — forcing Google Play Billing to clear failed purchases cached as pending —
is now handled by calling getAvailablePurchases() at startup:

const purchases = await getAvailablePurchases();

For each purchase in the result:

1. Call acknowledgePurchaseAndroid or consumePurchaseAndroid as appropriate.
2. Once processed, call finishTransaction.

This flow ensures that any pending transactions are surfaced and properly resolved,
without needing the old flush API.

[rokkoo]

Hi @hyochan,

Thank you for continuing to maintain the module! it’s a core component of many of our apps. I’m looking to upgrade to the latest version. Is there a guide or documentation outlining the changes needed to upgrade from v13?

The changelog url is broken https://react-native-iap.hyo.dev/blog/release-14-1-0

Thanks in advance!

[hyochan]

@rokkoo Sorry! The document has been moved to https://hyochan.github.io/react-native-iap!
Migration would be fairly easy if you understand the purchase flow and this will follow the specification in https://www.openiap.dev