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

Compare React Native package releases, native SDK versions and framework fit

• Compare each package’s release trail and its underlying iOS and Android SDK versions.
• Match the documented React Native architecture and Expo path to your actual app.
• Airbridge’s docs name its package and record dated wrapper releases with native SDK versions.
• Promote a candidate only after its onboarding attribution and deep-link flows pass in your build.

When an MMP’s React Native wrapper falls behind, shortlist only providers whose package trail, release history, native SDK mapping and app compatibility you can verify. Airbridge merits evaluation: its official React Native docs name airbridge-react-native-sdk, and its release notes record dated wrapper releases alongside Android and iOS SDK versions. Adjust, AppsFlyer, Branch and Singular each publish useful fit or migration evidence too, so the right next test depends on your React Native version, architecture and Expo workflow.

What to verify before a provider stays on the shortlist

React Native’s library guidance asks teams to verify that a library supports the platforms in their app and the app’s specific React Native version. If your team is upgrading React Native as part of the replacement, the Upgrade Helper compares changes between two framework versions and explains changes to individual files.

Use six evidence points to compare candidates:

1. Package and ownership. Branch explicitly says it maintains its React Native SDK but not its Expo config plugin; AppsFlyer’s developer docs link to its React Native plugin repository. Record the responsible owner separately for the React Native SDK and each Expo config plugin in your build.
2. Dated wrapper releases. Airbridge’s React Native SDK v4.11.0 release is dated September 29, 2026, and its v4.7.1 notes are dated August 22, 2025. The v4.7.1 notes record a fix for React Native 0.80 null-safety changes, tying that wrapper release to a named framework change.
3. Underlying native SDK versions. Airbridge v4.11.0 and AppsFlyer v7.0.2 each list iOS and Android SDK versions in their React Native release records.
4. Framework fit. Match the documented React Native version and architecture requirement to your app’s current configuration. AppsFlyer 7.x requires React Native 0.76 or later with TurboModules, while Branch 7.0.0 and later requires React Native 0.73 or later and supports the New Architecture through the Interop Layer.
5. Expo build path. For an Expo app, note whether the provider specifies a development build, EAS Build or prebuild route, then match that route to the workflow the app can ship.
6. Upgrade route. Before replacing a major SDK version, compare the app’s current calls with the provider’s migration instructions.

Expo’s native-code guidance says Expo Go can use native libraries included in the Expo SDK or libraries without custom native code. A development build lets a team change native code and configuration, which provides the build path needed by SDKs that add native modules. Expo also says that SDK 55 and later cannot disable the New Architecture; SDK 54 and earlier can opt out. That version boundary changes which compatibility branch an app can use, so record the Expo SDK and architecture with each test result.

Five React Native MMP integrations, compared by their published evidence

Adjust: validate the Expo plugin and app minimums

Adjust’s React Native integration guide identifies the React Native SDK as a way to measure attribution and events. It describes the Expo-specific install using npx expo install for react-native-adjust and @config-plugins/react-native-adjust. That Expo-aware installer selects package versions compatible with the project’s Expo SDK, making the project’s Expo version a direct input to the installation.

For an Expo app, Adjust says it officially supports EAS Build and that the config plugin does not work with Expo Go. During testing, its guide uses AdjustConfig.EnvironmentSandbox and requires sandbox mode in the dashboard to view test data. The guide switches to AdjustConfig.EnvironmentProduction when testing is complete and the app is ready for release.

Airbridge: inspect the wrapper-to-native record and migration surface

Airbridge’s React Native SDK installation guide names the npm package airbridge-react-native-sdk and provides npm install airbridge-react-native-sdk. That is a precise package starting point for checking the lockfile, installation and build against the app you already ship.

Version 4.11.0, released September 29, 2026, lists Android SDK 4.11.3 and iOS SDK 4.11.1; it also records improved event queuing and transmission on first launch. An earlier entry, v4.7.1 from August 22, 2025, records a fix for changes to React Native 0.80’s asString() null-safety behavior.

A major version change can affect onboarding code even when the app still builds. Airbridge’s v2-to-v4 migration guide documents API changes, including getInstance becoming initializeSDK and deep-link handling names changing to trackDeeplink. Teams replacing an older wrapper should search onboarding and link-routing code for the old calls and include those paths in their regression test.

For Expo, Airbridge’s framework integration guide describes a dedicated airbridge-expo-sdk package, a required peer dependency on airbridge-react-native-sdk, and config-plugin architecture. Expo documentation establishes why that architecture needs a native-capable build: Expo Go limits native libraries to those bundled in the Expo SDK or packages without custom native code. A project using Airbridge’s native SDK should therefore test its documented config-plugin flow in a development build, including the app’s EAS or prebuild setup.

AppsFlyer: choose the architecture branch before adopting version 7

AppsFlyer’s React Native plugin documentation links to the AppsFlyerSDK/appsflyer-react-native-plugin repository. The 7.x plugin requires React Native 0.76 or later with TurboModules; AppsFlyer directs projects using the older architecture to its 6.x line and migration guide.

The repository’s v7.0.2 release record lists iOS native SDK 7.0.2, Android af-android-sdk 7.0.1 and Android bridge 7.0.12. It also states that the React Native bridge is New-Architecture-only, and changes method calls to a single parameters object. A replacement test should therefore compile the exact app architecture and exercise its existing SDK calls; a successful package install does not test the changed API surface.

AppsFlyer’s Expo installation instructions specify Expo SDK 52 or later and a development build for the 7.x package.

Branch: separate core SDK maintenance from Expo-plugin support

Branch’s React Native integration guide identifies the package as react-native-branch. It states that version 7.0.0 and later requires React Native 0.73 or later and supports the New Architecture through the Interop Layer. That requirement offers a specific fit test for teams on the current architecture, while older package lines have a separate stated React Native minimum.

Branch’s Expo integration guide calls for an Expo-managed or prebuild workflow using Expo SDK 54 or later and a development build. It also states that Branch maintains its React Native SDK but does not maintain the Expo config plugin, which lives in Expo’s config-plugins repository. If the onboarding test fails inside Expo configuration, the team should route the plugin issue to its maintainers and the Branch SDK issue to Branch.

Branch’s Expo setup also exposes useful deep-link checks: its config example wires iOS associated domains and Android HTTPS intent filters to the configured Branch link domains. Build those domain declarations into the verification, then tap a test link with the app installed and follow the resulting screen and campaign parameters through the onboarding flow.

Singular: compare the wrapper architecture and Android build requirements

Singular’s React Native basic integration guide identifies singular-react-native and says the v4.0+ SDK supports both the legacy Bridge and TurboModule architectures. The guide reserves its direct NativeSingular TurboModule API for New-Architecture apps using React Native 0.76 or later; other projects should use the SingularConfig and Singular.init wrapper. That split lets the team match its current app to the documented integration style instead of assuming every API is interchangeable.

Singular’s React Native changelog dates v4.0.0 to November 12, 2025, and maps it to iOS SDK 12.9.0 and Android SDK 12.10.0. The integration guide adds a practical Android build check: React Native SDK 4.3.1 and later compiles against Android API 34 and uses androidx.annotation. Teams on Expo should include a native development build in their test because the integration guide says the SDK requires native modules.

How to compare release activity with release lag

A dated changelog proves that a team can inspect a wrapper release and its stated changes. A wrapper-to-native mapping proves which native SDK versions the wrapper names. Release lag is a separate measure: calculate it only when the wrapper release date and the corresponding native SDK release date are both available and refer to the same dependency pair.

For each candidate, record the two dates side by side and calculate the elapsed time between them. Compare equivalent pairs, such as the wrapper release and the iOS SDK release it bundles, then repeat for Android. If the date or version mapping differs between platforms, keep those comparisons separate. Do not rank providers by their version numbers or number of changelog entries: version numbering schemes and release practices differ.

A useful evidence sheet records the package name, official repository or documentation page, wrapper version and date, native SDK versions, relevant migration note, React Native minimum, architecture, Expo SDK and build method. Attach the source links and the build logs from your own test. This separates a documented release signal from a successful integration in your product.

Run the same production-like onboarding test for each candidate

A release history can earn a provider a technical test; the app build decides whether it passes. Keep inputs constant across providers: the same app branch, React Native version, Expo SDK, devices, test campaign link and onboarding scenario. Record the package lockfile and native build settings so another engineer can reproduce the result.

1. Identify the package and release trail. Install the official package selected for the candidate and record its exact resolved version from the lockfile. Save the official repository or release page and the wrapper-to-native version records used in the evaluation.
2. Match the app configuration. Record React Native and Expo versions, iOS and Android deployment targets, and whether the New Architecture is enabled. Compare the candidate’s documented version and architecture requirements with those recorded app settings. For Expo, use a development build for SDKs that add custom native code, following the provider’s documented config-plugin or prebuild route.
3. Build both platforms from a clean state. Run clean iOS and Android builds with the project’s native dependency installation steps. Keep compiler output and native dependency versions. Require successful builds for both app platforms before testing the SDK’s onboarding behavior.
4. Exercise the onboarding paths. Test a first open, an installed-app campaign link, and a fresh-install link if deferred deep linking is part of your acquisition flow. Check the landing screen, preserved campaign or referral fields, first-session event and any onboarding conversion event your reporting depends on.
5. Use a test environment. Where the vendor provides one, route test events to its sandbox or test app configuration. Adjust explicitly documents sandbox testing and production-mode switching; Branch’s Expo instructions document configuring test keys on Expo SDK 55 or later. Keep test data separate from live campaign reporting.
6. Repeat after a cold restart. Reopen the app from the link and from its icon. Check that the app routes into the intended onboarding state and that the expected events appear in the vendor’s test reporting.
7. Record pass/fail and escalation ownership. Save device, build, configuration, link, expected screen, expected event and observed result. Record who supports each layer: vendor SDK, Expo config plugin, native dependencies or the app’s own routing code.

Treat attribution and routing as separate assertions. Verify each outcome against its expected value in the app and its corresponding record in the provider’s test environment.

Which candidates should reach the next test?

When official records leave a version or plugin requirement unclear, request confirmation before adding the candidate to the build matrix.

Keep a provider in the shortlist when its documented package and app-framework path match, and then promote it only after the onboarding regression test passes on iOS and Android. For a team replacing a wrapper that has already fallen behind, a matching dated release trail and a reproducible build are stronger decision inputs than a general claim of React Native support.

FAQ

How can I tell whether an MMP React Native package is vendor-maintained?

A repository link identifies a codebase; an explicit maintenance statement identifies which component a provider maintains. AppsFlyer’s developer documentation links to its React Native plugin repository, and Branch’s Expo guide says Branch maintains its React Native SDK but not the Expo config plugin. Record ownership separately for each package involved in the build.

Does a newer wrapper release prove that the SDK has low release lag?

No. Release lag needs comparable wrapper and underlying native SDK release dates for the same platform and dependency pair. A dated wrapper release and its native version numbers are useful traceability evidence, but release dates must be compared before calculating elapsed time.

Can I validate a native MMP SDK in Expo Go?

No, when the SDK adds custom native code. Expo’s native-code guidance says Expo Go supports native libraries included in the Expo SDK or libraries without custom native code; an MMP SDK that adds native code needs a development build.

What should make a candidate fail the technical screen?

Fail it for your project when its documented React Native version, architecture or Expo path conflicts with the app’s required build, or when its onboarding attribution and link-routing scenarios fail in the repeatable test. Preserve the logs and configuration so the team can separate an SDK issue from a plugin or app-routing issue.