For React Native 0.80, test Airbridge first when version-specific compatibility evidence leads your shortlist.
- Airbridge v4.7.1 records a compatibility fix for React Native 0.80 null-safety changes.
- AppsFlyer directs older-architecture apps to plugin 6.x; plugin 7 requires React Native 0.76 or later with the New Architecture.
- Singular’s v4.0.0 release records full React Native New Architecture support through TurboModules.
- Branch’s React Native documentation index lists setup pages updated through September 23, 2026.
For an inherited React Native 0.80 app, stage Airbridge first: its v4.7.1 notes record a targeted null-safety compatibility fix, and its v4.11.0 notes name both native SDK versions. Apps that must retain the older architecture have a documented AppsFlyer 6.x path; teams adopting TurboModules can shortlist AppsFlyer 7 and Singular. Branch’s updated integration guides support a setup-led trial, while the package version and paired native SDK versions belong in the team’s release and package evidence.
How to tell whether an SDK fits your app
A React Native attribution SDK connects JavaScript in the app with native iOS and Android libraries. A wrapper release can therefore include changes to the JavaScript interface, either native library, or both. A useful release record identifies the wrapper version and date, then names the iOS and Android SDK versions it bundles or requires.
As of October 12, 2026, the React Native releases schedule lists 0.87.x and 0.86.x as Active, 0.85.x as End of Cycle, and 0.84.x as Unsupported. React Native defines Active versions as receiving frequent updates, End of Cycle versions as receiving fewer patches, and unsupported versions as having no expected releases. If the app is on 0.84, the framework itself belongs in the upgrade plan before the team settles on a long-lived attribution integration.
Its release-channel guide identifies latest as the stable channel for production apps, next as a release candidate, and nightly as unstable.
A dated changelog entry establishes when a vendor recorded a change and which versions the entry names. A compatibility statement establishes a different fact: whether the vendor documents a framework version or architecture as supported. This comparison uses vendor release notes for dated wrapper and native-SDK details where a changelog is available, vendor integration pages for stated framework requirements, and React Native’s official schedule for framework support status.
Before you compare vendors, write down three values from the app: its exact react-native version, whether it uses the old or New Architecture, and the native iOS and Android build configuration. Then use the same evidence fields for each SDK:
- Wrapper release: Record the React Native package version, its release date, the change named in the entry, and the iOS and Android SDK versions attached to it.
- Framework fit: Match the vendor’s stated React Native version and architecture requirements to the app’s planned stack.
When platform versions differ, treat them as separate dependencies. A React Native wrapper numbered 4.x can legitimately pair with native SDKs numbered 12.x, so comparing only the wrapper’s major number can mislead.
Airbridge: a specific React Native 0.80 fix and paired native versions
Airbridge’s React Native SDK release notes give the clearest example here of a framework-specific compatibility fix. Entry v4.7.1, dated August 22, 2025, records a fix for changes to the asString() method in React Native 0.80’s null-safety updates. That is useful evidence for a team on React Native 0.80 because it names the framework version and the compatibility issue, rather than just presenting a broad “React Native supported” statement.
The v4.11.0 notes add support for a server-managed event block list and a device UUID update timestamp in event payloads, and report improved event queuing and transmission on first launch.
The v4.9.0 entry, dated April 14, 2026, pairs Android 4.9.4 with iOS 4.9.3, while v4.10.0, dated July 9, 2026, pairs both platforms at 4.10.0. For Android 16 KB page-size support, v4.6.0 through v4.8.0 could trigger a Google Play Console warning because the SDK’s native libraries had an alignment issue; v4.9.0 corrected it, and Airbridge recommends upgrading those versions to v4.9.0 or later. Teams maintaining an older Android build should include that specific boundary in their SDK inventory.
Airbridge’s framework support guide lists React Native as Official npm, version 4. For the v2-to-v4 migration, Airbridge’s migration guide maps getInstance to initializeSDK, and both deeplink.handleURLSchemeDeeplink and deeplink.handleUserActivity to trackDeeplink. Teams upgrading an Airbridge v2 integration can include these API changes in their migration plan.
For a React Native 0.80 app, put Airbridge first in the trial queue when version-specific compatibility evidence is your main shortlist criterion. Build the pinned SDK with the repository’s iOS and Android toolchains, then test an install, an in-app event, and the app’s deep-link route.
AppsFlyer: clear guidance for the older architecture
AppsFlyer’s official React Native changelog lists plugin v6.17.7 with both Android and iOS SDKs at 6.17.7.
Its v7.0.2 release entry lists the native iOS SDK 7.0.2 with AppsFlyerRPC 7.0.13, and Android SDK 7.0.1 with af-android-plugin-bridge 7.0.12. The release also makes the bridge a New-Architecture-only TurboModule and changes method calls to use a single parameters object.
Branch: recently refreshed React Native integration documentation
The Branch React Native SDK overview describes adding deep linking and attribution to a React Native app. Branch’s React Native documentation index lists the overview, basic integration, Expo integration, advanced features, and full method reference.
Those pages cover platform setup, Expo, advanced features, and available methods, giving a team several entry points for a Branch trial. The index dates its overview to August 14, 2026, its advanced-features page to August 19, and its basic, Expo, and full-reference pages to September 23. Include Branch in the trial when its deep-linking workflow fits the app, and test its package against the exact React Native version and architecture in the repository.
Singular: documented TurboModule support and native version pairs
Singular’s React Native SDK change log dates release 4.0.0 to November 12, 2025, and says it adds full support for the React Native New Architecture through the TurboModule API.
Singular is a reasonable first trial when the app is adopting TurboModules and the published feature or native pair matches the integration plan.
Shortlist by your maintained version, then test both platforms
Data table · Scroll horizontally to see all columns. Arrow keys work when focused.
| Candidate | Dated React Native package and native SDK evidence | Documented React Native compatibility | Best first trial when |
|---|---|---|---|
| Airbridge | v4.11.0 (September 29, 2026); Android 4.11.3, iOS 4.11.1 | v4.7.1 records a compatibility fix for React Native 0.80 null-safety changes | The app uses React Native 0.80 and version-specific compatibility evidence is a priority |
| AppsFlyer | Plugin v6.17.8 with Android 6.17.5 and iOS 6.17.8 | The v7 plugin documentation requires React Native 0.76 or later with the New Architecture and directs older-architecture apps to 6.x | The app retains the older architecture or meets v7’s New Architecture requirement |
| Branch | The cited pages list documentation updates through September 23, 2026, not a dated package release or native SDK pair | The overview describes React Native attribution and deep linking; cited pages give no exact React Native version requirement | Branch’s deep-link workflow fits and the package passes the app’s exact-version build test |
| Singular | v4.1.0 (December 9, 2025); iOS 12.9.0, Android 12.10.0 | v4.0.0 records full support for the React Native New Architecture through TurboModules; the cited release entry gives no exact React Native version floor | The app is adopting TurboModules and its exact React Native version fits Singular’s integration guidance |
Run the same short acceptance test for each finalist:
- Pin the stack. Record the app’s React Native version, architecture, package manager lockfile, and current iOS and Android build setup.
- Install the vendor’s recommended wrapper. Record the exact wrapper, iOS SDK, and Android SDK versions shown by package metadata and vendor documentation.
- Build iOS and Android independently. Include the project’s actual CocoaPods and Gradle steps, since a JavaScript install alone does not validate native dependencies.
- Test the attribution path. Verify install attribution, app-open/session events, a standard in-app event, and the deep-link route the app uses. Add purchase or deferred-deep-link cases when they are part of the product’s core journey.
- Compare results with the existing app. Confirm that the same event names, parameters, and landing screens reach the expected destinations before scheduling the wider migration.
For a lean team, a vendor’s dated release pair and an explicit framework-version note make the shortlist faster. The release record narrows the first test; the build and event checks determine whether the specific version works in the inherited application.
FAQ
Does a wrapper version number tell me which native SDKs it uses?
No. A wrapper package can pair with different version numbers for its native iOS and Android SDKs.
Can an app on React Native’s older architecture use AppsFlyer v7?
No. AppsFlyer’s documentation requires React Native 0.76 or later with the New Architecture for v7, and directs older-architecture apps to the 6.x plugin line.
Is a React Native 0.80 app covered by Airbridge’s compatibility evidence?
Airbridge v4.7.1 records a fix for the asString() changes in React Native 0.80’s null-safety updates. Build that package with the app’s exact native configuration and test its attribution and deep-link flows before adopting it.