React Native 0.81.5+ support?

[norenz92]

Hi,

We're planning to upgrade to React Native 0.81.5+ but react-native-exponea-sdk is currently the only package blocking our upgrade.

Is there a timeline for RN 0.81.5+ support?

Thanks!

[frenic]

The real problem here is their dependency strategy that really wastes our time. The real problem is that we cannot even upgrade from 0.81.4 to 0.81.5 to resolve this issue. You need to bump your peer dependency now and revise your dependency strategy!

[witeone-br]

Hi @frenic and @norenz92, thank you for reaching out! At this point in time, we are unable to provide a specific timeline on when the update could be done. An analysis of the impact of the update will be conducted and a resolution will be proposed afterwards.

[galinski-n]

@witeone-br any updates yet? RN 0.84.x is set to be released in the next week or so, so it would be nice to support something more recent.

[diaz9557]

Does this SDK supports React native 0.83.1 ?
Is it even worth trying integrating or do i have to downgrade my React native version to 0.81.4 ?

[witeone-br]

Hi guys, sorry for a late reply, the delivery of the support of newer version is planned for the end of March.

[frenic]

Was 2.7.0 the release for the end of March you were talking about? We got a 0.81.6 bump that we asked for 3 months ago when 0.81 was still supported. So that ship has sailed a long time ago. You're creating yourself, and all of us developers who have a management that unfortunately signed with you, a huge technical dept here by bumping the React Native peer dependency every 3-4 major upgrade. This happens over and over and over again. This madness has to stop.

[bloomreach-podborsky]

Hi @frenic, 👋

Thank you for your message.

I'm sorry we're causing troubles.

We're in the final testing phase of a major rewrite of the React Native SDK for the TurboModules Architecture to be able to support 0.83+. As the change is quite significant in the SDK, we need to treat it with care.

We hope to deliver the new version by the end of March / early April 2026.

[galinski-n]

@bloomreach-podborsky @witeone-br any update on this?

[bloomreach-podborsky]

Hi @galinski-n, 👋

We're in the final testing stage for the React Native SDK for the TurboModules Architecture.

We aim to deliver the new version in the upcoming days.

[frenic]

Great, for React Native 0.85 i hope?

[nialldbarber]

@bloomreach-podborsky great to hear the turbo modules rewrite is nearly ready. One question- will this release also relax the peer dependency range for react native? The tight pinning to specific patch versions is what causes the recurring upgrade bottleneck, which I think is separate from the architecture compatibility itself? Most libraries don't do this afaik, this feels too conservative.

https://reactnative.dev/versions this library is already not up to date with the supported RN versions.

[frenic]

Finally! So I thought. It appears the 3.0.0 is useless. React Native is bumped to 0.83.0. Not even 0.83.5. Two major versions behind. This is so frustrating!

[galinski-n]

being strictly tied to a version that came out 4+ months ago is incredibly frustrating when we've been waiting so long for this. and 0.83.x is nearly end of life. @bloomreach-podborsky when can we expect 0.84.x compatibility? hopefully before 0.87.x comes out?

[nialldbarber]

Why does this SDK pin to exact RN patch versions? @bloomreach-podborsky could you explain the rationale behind this? From a consumer perspective, it creates a few serious problems:

1. The SDK seems to be perpetually out of date. RN ships patch releases regularly. By the time you release an update adding support for e.g. 0.81.4, 0.81.5 is already out. Consumers are always waiting for you to "catch up" to a version that's already available.
2. It blocks upgrades across entire projects. As the OP noted, this SDK becomes the single blocker preventing an RN upgrade. For teams with many dependencies, one package pinning to an exact patch version holds everything back.
3. It's not how the RN ecosystem works. The vast majority of RN libraries use semver peer dependency ranges (e.g. "react-native": ">=0.71"). Patch releases within a minor version are backwards-compatible by definition, that's what semver means. If the SDK genuinely breaks on a patch bump, that points to a fragile integration with RN internals that should be addressed, not papered over with version pinning.