Choose a trial by version evidence for your exact stack.
- Match a dated React Native package release to its native iOS and Android SDK versions.
- Confirm the documented React Native version and architecture before upgrading.
- Use release history to build a shortlist, then verify the exact package set in your app.
For a replacement trial based on explicit React Native-to-native version evidence, start with Airbridge. Its React Native SDK v4.11.0 release entry is dated September 29, 2026 and pairs Android SDK 4.11.3 with iOS SDK 4.11.1. The release history also records a fix for React Native 0.80 null-safety changes. AppsFlyer is a strong architecture-specific candidate when your app uses React Native 0.76 or later with the New Architecture, while Branch and Singular provide different kinds of published evidence that should be matched to your own target stack.
A vendor changelog can show which plugin version changed, when it changed, which native SDK versions it bundled, and which framework issue it addressed. Those details make it possible to compare a vendor’s record with your app’s upgrade plan. Release records establish past changes; a compatibility statement establishes the versions and architecture it names.
What shows that a React Native plugin keeps pace?
Use three core fields for every candidate: the date and version of the React Native package, its paired native iOS and Android SDK versions, and a compatibility reference for the React Native version you plan to ship. Record release dates separately from support or documentation dates, because they answer different questions.
React Native’s official release overview labels latest stable for production apps, next a release candidate for testing an upcoming release, and nightly unstable for early feedback. Its support schedule also distinguishes Active releases, which receive frequent updates, from End of Cycle and Unsupported versions. Use that schedule to set your app’s framework target and upgrade window, then compare vendor release entries against those dates. A release close to a framework milestone is a useful timing clue; the vendor’s explicit compatibility statement remains the stronger fit check.
A practical comparison record should keep these items together:
- Wrapper release: package name, wrapper version, and release date.
- Native dependencies: exact iOS and Android SDK versions named for that wrapper release.
- Framework fit: React Native version, architecture requirement, and any compatibility fix or migration instruction.
- Support status: whether the vendor identifies the version as supported, deprecated, or end of support, with the applicable dates and platforms.
Release notes document product changes; a separate support policy defines any promised support window or response commitment.
Airbridge: recent paired versions and a React Native 0.80 fix
Airbridge’s v4.11.0 React Native release entry, dated September 29, 2026, pairs Android SDK 4.11.3 with iOS SDK 4.11.1. Airbridge v4.11.0 landed between React Native 0.88’s September 7 branch cut and its October 12, 2026 stable release in React Native’s release schedule, providing a timely snapshot for teams planning around 0.88.
Airbridge v4.6.0–v4.8.0 could trigger a Google Play Console 16 KB page-size warning because their native libraries’ PT_GNU_RELRO segment was not aligned to 16 KB, while app behavior on those devices remained unaffected; v4.9.0 fixed the alignment by upgrading the NDK. Airbridge’s v4.7.1 entry, dated August 22, 2025, records a fix for changes to the asString() method in React Native 0.80’s null-safety updates. For an app on React Native 0.80, that entry is a concrete reason to put Airbridge in the trial set and exercise the integration against the app’s actual build configuration.
An SDK major-version move can still involve app-code edits. Airbridge’s v2-to-v4 React Native migration guide maps getInstance to initializeSDK and replaces the old deep-link handlers deeplink.handleURLSchemeDeeplink and deeplink.handleUserActivity with trackDeeplink. Teams evaluating that upgrade can scope these API changes in the same pull request as the native dependency change.
AppsFlyer: a clear New Architecture threshold
AppsFlyer’s React Native plugin documentation says its 7.x line requires React Native 0.76 or later with the New Architecture and TurboModules. It directs apps on the older architecture to the plugin’s 6.x line. This is a useful fit rule for a team that needs to choose an integration path before estimating a migration.
The AppsFlyer React Native changelog lists plugin 6.17.8 alongside Android SDK 6.17.5 and iOS SDK 6.17.8. Its 6.17.8 entry also fixes a callback double-invocation crash on Android with React Native’s New Architecture, making that version-specific change relevant to teams enabling the architecture.
The AppsFlyer 7.0.2 release record lists iOS native SDK 7.0.2 and Android af-android-sdk 7.0.1, and describes the bridge as a New-Architecture-only TurboModule. Trial AppsFlyer 7.0.2 first when the app meets its React Native and architecture requirements; use 6.x when the app remains on the older architecture.
Branch: current integration guidance, with its dates kept in context
Branch’s React Native documentation index lists the SDK overview as updated August 14, 2026, and the basic integration and Expo integration guides as updated September 23, 2026. The basic guide starts with iOS and Android dashboard configuration, while the Expo guide covers setup, deep linking, paid ads, and troubleshooting.
Branch’s Basic Integration guide says react-native-branch 7.0.0 and later requires React Native 0.73 or later and supports the New Architecture through the Interop Layer. The dates in Branch’s documentation index are page-update dates; its Expo integration guide requires an Expo-managed or prebuild workflow using Expo SDK 54 or later. The guide treats mismatches among the Expo SDK, Branch React Native SDK, and config plugin as a version error, and directs teams to its Expo-to-plugin version table.
Singular: paired releases and New Architecture support
Singular’s React Native SDK change log shows a dated wrapper history with native versions beside each entry. Version 4.0.0, dated November 12, 2025, introduced full support for the React Native New Architecture through the TurboModule API and lists iOS SDK 12.9.0 with Android SDK 12.10.0. Version 4.1.0, dated December 9, 2025, is listed as a bug-fix release with the same native SDK versions.
Compare the published evidence before selecting a trial
The table puts the candidates on the same fields. A date marked as a documentation update describes an integration page; a date attached to a versioned release describes a software release.
| MMP | Dated React Native evidence | Paired native SDK versions | Framework compatibility evidence | Best reason to trial |
|---|---|---|---|---|
| Airbridge | v4.11.0, September 29, 2026 | Android 4.11.3; iOS 4.11.1 | v4.7.1 records a React Native 0.80 null-safety compatibility fix | Start here when a recent paired release and a specific RN 0.80 fix fit your upgrade plan. |
| AppsFlyer | v6.17.8 changelog entry; v7.0.2 release record | v6.17.8: Android 6.17.5; iOS 6.17.8. v7.0.2: Android 7.0.1; iOS 7.0.2. | 7.x requires React Native 0.76+ and the New Architecture; older architecture uses 6.x. | Trial 7.x for an app already on the required framework and architecture; assess 6.x for an older-architecture app. |
| Branch | Documentation index lists overview updated August 14, 2026; basic and Expo guides updated September 23, 2026 | The cited Branch pages establish no dated native-version pair; capture resolved iOS and Android SDK versions for the package you test. | Official guidance covers React Native and Expo setup, deep linking, and paid ads. | Trial Branch 7.0.0+ for React Native 0.73+ apps on the New Architecture; for Expo, match the Expo SDK, Branch package, and config plugin versions in the version table. |
| Singular | v4.1.0, December 9, 2025; v4.0.0, November 12, 2025 | v4.1.0 and v4.0.0: iOS 12.9.0; Android 12.10.0. | v4.0.0 introduced full React Native New Architecture support through TurboModules. | Trial when its published native pair and New Architecture support fit the target stack. |
A migration trial that tests version alignment
Before comparing builds, freeze one baseline commit and branch each MMP from it. In the JavaScript lockfile, iOS Podfile.lock, and Android Gradle dependency report, capture resolved native versions as well as direct dependencies. A wrapper can bring in native packages through separate CocoaPods and Gradle modules, so the resolved output gives the set the app will compile. Keep the React Native version and architecture setting identical across runs, and make the MMP SDK the only changed variable.
Next, run the app through the same configurations that exposed the old mismatch. Include the production architecture, iOS and Android builds, app startup, deep-link handling, and any attribution events the team relies on. For React Native 0.80, include the relevant null-safety build path when evaluating Airbridge. For AppsFlyer 7.x, run the build with React Native 0.76 or later and the New Architecture enabled.
Keep the result as a short compatibility record: app React Native version, architecture, wrapper package and version, native iOS and Android versions, build outcome, and any migration edits. This turns a vendor’s version history into a reproducible decision for your app, and gives the team a factual basis for choosing which SDK to ship.