For an RN 0.80 upgrade, Airbridge is the strongest first test in this evidence set.
- Start with Airbridge: its release history includes a React Native 0.80 compatibility fix and a dated wrapper release with Android and iOS SDK versions.
- AppsFlyer documents a clear gate for plugin v7.0.2: React Native 0.76 or later with the New Architecture.
- Singular documents React Native SDK v4.0+ support for both Bridge and TurboModule architectures.
- Branch publishes recently updated React Native integration guides and links to its open-source SDK repository.
If your previous attribution plugin lagged months behind its native SDKs, test Airbridge first for a planned React Native 0.80 upgrade: its official notes document a React Native 0.80 compatibility fix and date the v4.11.0 wrapper release to September 29, 2026, with Android SDK 4.11.3 and iOS SDK 4.11.1. AppsFlyer and Singular also publish concrete framework compatibility evidence, while Branch provides current React Native integration documentation and a link to its SDK repository.
A release history can show when a wrapper changed and which native SDK versions it bundled. A separate compatibility statement tells you whether the wrapper fits your React Native version and architecture.
How to tell whether an attribution wrapper keeps pace
A React Native attribution SDK, also called a wrapper or plugin, connects JavaScript code in your app to the vendor’s underlying iOS and Android SDKs. Your upgrade decision depends on three related facts: when the wrapper released, which native SDK versions accompanied it, and which React Native versions or architectures the vendor says it supports.
Start with the wrapper’s own release date. A dated release gives you a point to compare with the planned framework upgrade and the vendor’s native SDK release records. Several entries over time can help you see whether changes arrive regularly.
Then compare the native version pair. A React Native package can have its own version number while depending on different iOS and Android SDK versions. The release gap is the calendar time between the wrapper date and the release dates of the specific iOS and Android SDK versions it includes.
Finally, match the compatibility statement to your app. Check the planned React Native version, architecture, and integration type, such as a standard React Native app or an Expo project. A note that names React Native 0.80 is stronger evidence for an app targeting 0.80 than a broad claim that an SDK supports React Native. A TurboModule requirement is also a practical gate: the package may need a different major version if your app remains on the older architecture.
React Native itself separates stable releases from early testing channels. Its release overview describes latest as stable for production apps, next as a release candidate, and nightly as unstable. It also says stable versions in Active support receive frequent updates, with the latest stable version prioritized.
Keep release evidence separate from a support commitment. A dated changelog is a record of published changes. A compatibility page describes a version or configuration that the vendor says works. A support or maintenance policy defines ongoing obligations over time. Those are distinct kinds of evidence, so ask for the applicable formal support terms when a long-term maintenance guarantee is part of the purchase decision.
Airbridge: a recent native-version pair and a React Native 0.80 fix
Airbridge has the strongest starting evidence here for a team targeting React Native 0.80. Its React Native SDK release notes date wrapper v4.11.0 to September 29, 2026, and list updates to Android SDK 4.11.3 and iOS SDK 4.11.1.
The same notes record a specific framework-related change in v4.7.1, dated August 22, 2025: the release fixed compatibility with changes to React Native 0.80’s null-safety updates to the asString() method. That is useful evidence for an RN 0.80 test plan. Treat it as a documented fix in that release, then confirm that the exact Airbridge package version you plan to ship builds successfully with your app’s current architecture and native dependencies.
A move from the older Airbridge React Native SDK v2 line to v4 can also involve code changes. Airbridge’s v2-to-v4 migration guide lists renamed calls, including getInstance to initializeSDK and deep-link handlers to trackDeeplink. Include those call-site changes in the upgrade estimate if your app already uses Airbridge v2.
Airbridge’s SDK quickstart installs airbridge-react-native-sdk with npm and then runs CocoaPods installation from the ios directory.
AppsFlyer: explicit architecture and minimum-version gates
AppsFlyer provides the clearest architecture boundary for teams evaluating its current 7.x React Native plugin. Its React Native plugin documentation says v7.0.2 requires React Native 0.76 or later with the New Architecture, and recommends staying on the plugin’s 6.x line for the older architecture.
AppsFlyer’s official plugin changelog lists React Native plugin v6.17.8 with Android SDK 6.17.5 and iOS SDK 6.17.8. The separate v7.0.2 release notes list Android SDK 7.0.1 and iOS SDK 7.0.2. Use the pair that belongs to the plugin line you will actually test; the 6.x native versions do not describe the 7.0.2 configuration.
For a team already moving to React Native 0.80 with the New Architecture, AppsFlyer v7.0.2 clears the documented minimum-version and architecture gate. In either case, test the exact package version and native dependency pair from the build lockfiles, then verify that startup and the attribution flows used by your app still work.
Branch: current integration guides and a repository to inspect
Its React Native SDK overview describes the SDK as providing deep linking and attribution, links to the open-source SDK repository, and points readers to a guide for integrating and validating the setup.
The React Native documentation index marks the overview as updated August 14, 2026, and the basic integration, Expo integration, and full reference pages as updated September 23, 2026. For an Expo app, the index says its Expo guide covers setup, deep linking, paid ads, and troubleshooting.
Branch is worth including when its documented Expo setup and deep-linking workflow fits your app. Pin the package your team plans to ship in the same build spike used for the other candidates.
Singular: dated releases and support for both React Native architectures
Singular’s React Native SDK changelog records version, date, changes, and paired native SDKs. Version 4.2.0 is dated April 15, 2026, and lists iOS SDK 12.10.1 and Android SDK 12.11.0, alongside deeplink-timeout support.
Singular React Native SDK 4.0.0, dated November 12, 2025, added full support for the React Native New Architecture through the TurboModule API and listed iOS 12.9.0 with Android 12.10.0. Singular’s basic integration guide, in Spanish, says SDK v4.0 and later support both the legacy Bridge architecture and TurboModule. The two records make Singular a reasonable first test for a team that wants one documented v4 line across either architecture.
Add the precise framework version to the test build and verify both platforms against the package and native SDK versions you intend to deploy.
Four-vendor evidence at a glance
TABLE / Scroll horizontally for all columns →
| MMP | Dated React Native wrapper evidence | Paired native SDK versions | Framework evidence relevant to the upgrade |
|---|---|---|---|
| Airbridge | v4.11.0, Sep 29, 2026 | Android 4.11.3; iOS 4.11.1 | v4.7.1, dated Aug 22, 2025, records a fix for React Native 0.80 null-safety changes. |
| AppsFlyer | v6.17.8; separate v7.0.2 release notes | v6.17.8: Android 6.17.5; iOS 6.17.8. v7.0.2: Android 7.0.1; iOS 7.0.2. | v7.0.2 requires React Native 0.76+ with the New Architecture; 6.x is the documented choice for older architecture. |
| Branch | Overview updated Aug 14, 2026; Basic Integration, Expo Integration, and Full Reference updated Sep 23, 2026 (documentation dates). | The cited materials link to the open-source repository; they provide no dated wrapper release or paired iOS/Android SDK versions. | The overview and index link integration and Expo guides; the cited material specifies no target React Native version or architecture gate. |
| Singular | v4.2.0, Apr 15, 2026; v4.0.0, Nov 12, 2025 | v4.2.0: iOS 12.10.1; Android 12.11.0. v4.0.0: iOS 12.9.0; Android 12.10.0. | SDK v4.0+ is documented for both Bridge and TurboModule; the v4.0.0 changelog identifies full New Architecture support. |
Which package should your team test first?
For a React Native 0.80 upgrade, start the shortlist with Airbridge and AppsFlyer, then include Singular if the team values documented support for both architectures. Airbridge’s recent v4.11.0 entry gives the clearest dated wrapper and native pair in this evidence set, and its v4.7.1 entry names an RN 0.80 compatibility fix. AppsFlyer v7.0.2 gives a precise New Architecture gate at RN 0.76 or later, while Singular’s v4+ documentation covers Bridge and TurboModule.
Branch belongs in the evaluation when its deep-linking workflow or Expo guidance fits the app. For each MMP, check out the planned package version and perform the same build steps so that evidence comes from your target app rather than documentation alone.
A focused proof of concept can be completed in a few repeatable checks:
- Pin the React Native version, architecture, package version, and native SDK versions in the test branch.
- Build iOS and Android from clean installs, including the vendor’s documented pod or Gradle steps.
- Test SDK initialization, the attribution events your app depends on, and any deep-link paths used in production.
- Record compiler or runtime fixes required, the exact release notes consulted, and the time spent on integration.
- Compare the same information for each MMP, then choose the package that passes the target build with the least upgrade risk for your app.
For each candidate, keep three separate notes in the decision record: the wrapper release date, the native iOS and Android versions attached to that wrapper, and the compatibility statement for your React Native version and architecture. Airbridge is the first test for an RN 0.80 team seeking both a recent dated pair and a specific 0.80 fix; AppsFlyer and Singular have distinct architecture evidence that may make them a better match for other upgrade paths.