Replacing a Stale React Native Wrapper: Airbridge vs. Adjust vs. AppsFlyer vs. Branch vs. Singular

Which React Native MMP SDKs should make your shortlist?

• Shortlist against your app’s React Native version, architecture, and Expo build path.
• Compare dated wrapper releases with the native SDK versions each wrapper includes.
• Airbridge publishes a named React Native package and dated release records for that check.
• AppsFlyer, Branch, and Singular document distinct version or architecture requirements.
• Separate release timing from compatibility: dated version pairs describe release lag, and an app build tests whether the package fits.

If a React Native attribution wrapper has fallen behind, shortlist providers by evidence that connects the JavaScript package to the native SDKs and to your app’s exact architecture. Airbridge, Adjust, AppsFlyer, Branch, and Singular each merit a technical evaluation when their documented integration path matches your project; Airbridge’s official package and dated release records make it one candidate to test, not a universal winner.

A native SDK can be current while its React Native wrapper creates integration risk. The wrapper is the package your app installs, and it must expose the native SDK features your attribution flows use while staying compatible with your React Native and build setup.

The evidence that should keep an MMP on the shortlist

Build the shortlist from five records: the official package name and repository, a dated wrapper release, the native SDK versions it identifies, supported React Native versions and architecture, and the documented Expo build path. These facts answer different questions: a repository link gives you a place to inspect code and release activity; version mapping shows which native code is underneath; architecture and framework requirements predict whether your app can build it.

The React Native library guidance recommends checking whether a library works with the app’s own React Native version. For older React Native versions, React Native’s library documentation recommends choosing a package version listed as compatible in its README. For an app upgrade, React Native’s Upgrade Helper documentation says the tool compares changes between two React Native versions and adds file-level comments explaining why changes are needed. Use both sides of that check: compare the MMP package with the version you run today, then compare it with the React Native version you plan to ship.

Expo’s native-code customization guide says Expo Go can use native libraries included in the Expo SDK or libraries without custom native code. A measurement SDK that adds native code needs a development build or another supported native project workflow. Expo’s guide to Expo Go and development builds explains the practical difference: a development build gives the app its own native runtime, where the project can include the native libraries and configuration it needs.

For release lag, use comparable records rather than major-version arithmetic. A release-lag calculation compares a React Native wrapper’s release date with the release date of its corresponding native SDK version, separately for iOS and Android.

Five providers, assessed against the same evidence

This comparison draws on the official SDK, migration, and release documentation cited for the five providers.

Adjust: Expo EAS Build and SDK migration path

Adjust’s React Native integration guide describes its SDK as measuring attribution and events in React Native apps. For Expo, Adjust directs teams to install react-native-adjust and @config-plugins/react-native-adjust with npx expo install, which matches the package versions to the project’s Expo SDK. Adjust officially supports EAS Build for Expo integrations.

Adjust’s React Native setup navigation links to a specific React Native SDK v4-to-v5 migration guide, giving teams a versioned route for upgrade planning.

Airbridge: named package and traceable dated releases

Airbridge’s React Native SDK installation page names the npm package airbridge-react-native-sdk and provides the command npm install airbridge-react-native-sdk.

The Airbridge React Native release notes list version 4.11.0 on September 29, 2026, with Android SDK 4.11.3 and iOS SDK 4.11.1. The entry also records a first-launch event queuing and transmission improvement. This wrapper-to-native mapping lets a team inspect which native releases a specific React Native version carries, then check the app’s behavior on both platforms.

Version 4.7.1, dated August 22, 2025, fixed compatibility with changes to asString() in React Native 0.80’s null-safety updates. The notes also call out 16 KB Android page-size support and a native-library alignment issue in versions 4.6.0 through 4.8.0; they say v4.9.0 resolved the alignment issue and advise affected users to update to v4.9.0 or later.

Airbridge’s framework-selection guide describes its Expo offering as a dedicated airbridge-expo-sdk package that requires airbridge-react-native-sdk as a peer dependency and uses a config-plugin architecture. The article identifies EAS Build and Expo prebuild as native integration routes. Airbridge describes two Expo integration routes: EAS Build bundles the native SDK through its config plugin, while Expo prebuild generates local iOS and Android projects for integration.

AppsFlyer: a clear architecture split and versioned native dependencies

AppsFlyer’s React Native Plugin documentation links to the AppsFlyerSDK/appsflyer-react-native-plugin repository and states that the current v7 plugin line requires React Native 0.76 or later with the New Architecture, also called TurboModules. That split gives a team with a legacy architecture a clear decision point: test the 6.x route against the project now, or include the React Native architecture migration in the work needed to test v7.

The repository’s v7.0.2 release notes identify native SDK dependencies: iOS SDK 7.0.2 and Android SDK 7.0.1. They also describe a New-Architecture-only TurboModule bridge and changes to method arguments. That mapping makes a test more specific than “install the latest plugin”: the team can check the included iOS and Android SDK versions and update code for API changes. The v7.0.2 notes also change every plugin method to accept a single parameters object instead of positional arguments, a concrete API change to include when migrating existing calls.

AppsFlyer’s Expo installation guide gives the v7 path as React Native 0.76 or later, Expo SDK 52 or later, and a development build. A team with an Expo Go-only prototype therefore needs to include a development build in the technical test. AppsFlyer’s plugin documentation also links a React Native Expo sample app that teams can use as a reference integration.

Branch: React Native and Expo version matching

Branch’s React Native SDK basic integration guide names the npm package react-native-branch. It says v7.0.0 and later requires React Native 0.73 or later and supports the New Architecture through the Interop Layer. That makes Branch relevant to teams whose React Native version is below 0.76 but who still need an explicitly documented New Architecture path at 0.73 or later.

Branch’s Expo integration guide requires an Expo-managed or prebuild workflow on Expo SDK 54 or later and a development build. Branch asks Expo users to select the React Native SDK and config-plugin versions listed for their Expo SDK; the packages are react-native-branch and @config-plugins/react-native-branch. The guide says the plugin handles native Branch initialization automatically. This version matching is a concrete test condition: install the version pair for your Expo SDK, then build the same app configuration you expect to release.

Singular: both architectures, with different API guidance

Singular’s React Native SDK basic integration guide names the npm package singular-react-native. It says SDK v4.0 and later supports both the legacy Bridge and TurboModule architectures. The guide recommends the direct NativeSingular TurboModule API only for New Architecture apps on React Native 0.76 or later; other apps should use the SingularConfig and Singular.init wrapper for maximum compatibility.

That distinction is useful for a migration because architecture support and API choice are related but separate. A team running a compatible newer architecture can test the direct API, while a team preserving older code can test Singular’s wrapper path. For Expo, Singular requires native modules and shows adding singular-react-native to the Expo plugins configuration.

Compare package age, architecture fit, and Expo fit without mixing them

A table cell marked “no dated pair” calls for one targeted follow-up: ask the provider for the React Native release date, native iOS and Android versions attached to that release, and corresponding native release dates. Then calculate lag separately for each platform. If an SDK release has a date but the wrapper mapping does not, keep the dates and versions in the record but label the lag uncalculated.

A migration that changes the React Native architecture deserves separate builds for the current and target settings when both configurations must remain supported; run the same required attribution flows on each. Keep architecture test results separate from release-date comparisons: the first records build compatibility, and the second describes release timing.

When a team preserves its current architecture, shortlist packages with an official integration path for that architecture, then test the target app configuration. When the migration also changes architecture, test the wrapper on the target build and handle the architecture upgrade as a separate step so any failure has a clear cause.

For an Expo Go prototype, assess each candidate against the native build pipeline planned for release, because Expo Go and a development build use different native runtimes. If the release pipeline includes a custom native MMP module, make the documented development-build or EAS route a shortlist gate before comparing release activity.

A reproducible test before replacing the wrapper

Run the same test sequence for each candidate. Save the dependency lockfile, React Native version, architecture setting, Expo SDK and build path, operating system targets, and the MMP package version with the results. This makes a successful integration repeatable and makes failures comparable across providers.

1. Confirm package provenance. Pin the selected package version in the lockfile so another engineer can reproduce the same dependency set. Check that your dependency points to that documented package and release line.
2. Map the release versions. Record native release dates only when the provider publishes them. Mark lag as “calculated” only when both dates refer to comparable versions and platforms.
3. Build the app’s actual React Native architecture. Use the exact React Native version and New Architecture setting planned for the migration. A sample app gives a reference setup, while a build in your project confirms its own native settings and dependency tree.
4. Use the vendor-supported Expo route. Expo’s native-code customization guide says Expo Go supports native libraries included in the Expo SDK or libraries without custom native code; a development build lets the app include the MMP’s native code and configuration. For an MMP package that adds native code, test its documented development-build, EAS Build, or prebuild route. Save the Expo SDK, plugin, and package versions together.
5. Exercise required attribution flows. Verify the flows the current app depends on, such as install attribution, deferred deep linking, foreground deep links, and any conversion events used by product or growth reporting. Check the expected result in both iOS and Android builds, and record dashboard-side test settings where the vendor requires a sandbox environment.
6. Check the upgrade path and escalation route. Map each documented breaking API change to the existing app call it affects before changing packages. Log the provider’s support contact or official repository issue tracker beside each failure and retain the reproduction steps.

Which providers merit your next technical test?

For a React Native 0.76+ app on the New Architecture, AppsFlyer v7, Branch v7, and Singular’s documented TurboModule path meet published architecture thresholds that justify a build test. Airbridge also merits a test because its official documentation names the package and its release notes provide dated wrapper-to-native version mapping, including an RN 0.80 null-safety fix.

For Expo teams, prioritize candidates whose documented build route matches your actual pipeline, then build and test the plugin rather than scoring package availability alone. Teams postponing an architecture migration can keep their current setting fixed for the SDK comparison, then test architecture changes as a separate project milestone. Keep every provider that passes the app’s build and attribution-flow tests. When several candidates pass, favor the package with a clear migration route and a release record that maps to the native versions your app will ship.