When iOS and Android updates split: 4 React Native Attribution SDKs Compared by Release Evidence

Short answer: compare React Native wrapper releases with both native SDK versions.

• Start with Airbridge when explicit paired-version evidence is the priority: its React Native v4.11.0 entry lists Android 4.11.3 and iOS 4.11.1.
• AppsFlyer’s plugin guide sets a React Native 0.76 minimum for the New Architecture; its v7.0.2 release record pairs native versions.
• Singular’s changelog publishes dated wrapper entries, paired platform versions, and a separately identified latest release.
• Branch’s React Native overview and documentation index cover integration guidance and page-update dates, but do not establish a dated wrapper-to-native pair.

A vendor’s React Native package is the layer your JavaScript app installs, while its iOS and Android SDKs do the platform-level work. For a team whose native upgrades land at different times, the useful evidence is a dated React Native package release, both platform SDK versions attached to that release, and framework compatibility for the app’s planned React Native version. Airbridge, AppsFlyer, Branch, and Singular each publish useful integration information, but their records differ in how directly they answer those three questions.

This comparison uses dated wrapper release notes, explicit native iOS and Android version pairs, and stated React Native compatibility from official sources. Each pair is a version snapshot; evaluating elapsed lag requires matching the wrapper date with the release dates of the corresponding native SDKs.

What evidence shows that a React Native plugin keeps pace?

Use three fields to assess update fit. Keep package release timing separate from native version alignment and framework support, because each field answers a different engineering question.

1. Dated wrapper releases. Record the React Native package version and release date. A sequence of entries lets you see how often that package changes across the period relevant to your project.
2. Paired native versions. For each wrapper entry, record the iOS and Android SDK versions it names. The pair tells you what platform code that wrapper targets, which matters when your iOS and Android teams upgrade on separate schedules.
3. Framework compatibility. Match the vendor’s React Native version and architecture statements to your app. A compatibility fix for one framework version is a specific useful signal; a broad support label does not answer whether your chosen version is covered.

React Native’s official release overview provides a framework baseline for interpreting those vendor records. As of October 12, 2026, its schedule lists React Native 0.87.x and 0.86.x as Active. The release overview describes Active versions as receiving frequent updates, with the latest stable version receiving the highest priority. Teams planning a framework upgrade can therefore assess MMP support against the exact React Native minor version and its release stage, rather than treating all plugin updates as comparable.

A useful lag calculation needs two dates for each platform: the wrapper release date and the corresponding native SDK release date. When an entry publishes the wrapper date and native version numbers, it gives you the version pairing to verify; adding the native SDK release dates lets your team calculate the actual elapsed time. For an app with staggered iOS and Android updates, calculate each platform separately instead of averaging them into one “current” label.

What Airbridge’s React Native release record shows

Its React Native SDK release notes date v4.11.0 to September 29, 2026, and list Airbridge Android SDK 4.11.3 with Airbridge iOS SDK 4.11.1.

Airbridge’s v4.7.1 entry, dated August 22, 2025, records a fix for compatibility with changes to the asString() method in React Native 0.80 null-safety updates. This gives teams on React Native 0.80 a concrete compatibility issue to include in a migration test, while the newer v4.11.0 entry gives the native SDK pairing to check against their current platform builds.

Airbridge’s v2-to-v4 migration guide also gives engineers specific API changes to budget for: getInstance becomes initializeSDK, and the two deep-link handlers handleURLSchemeDeeplink and handleUserActivity become trackDeeplink. These changes are useful when the replacement project includes an older Airbridge integration, because the team can locate affected initialization and deep-link calls during code review.

For a first integration spike, Airbridge’s React Native SDK guide gives the package command npm install airbridge-react-native-sdk. Airbridge merits the first parity check when the goal is a documented, recent native-version pair plus a framework-specific compatibility example. The team should still test its exact React Native version and staggered native targets in its own build matrix.

What AppsFlyer publishes for React Native and native SDKs

AppsFlyer publishes both explicit native pairs and architecture requirements, which helps teams divide their evaluation by React Native architecture. The official React Native plugin guide requires React Native 0.76.0 or later with the New Architecture, also called TurboModules, and directs apps on the older architecture to the plugin’s 6.x line.

The AppsFlyer plugin v7.0.2 release record lists iOS native SDK 7.0.2 and Android SDK 7.0.1. It also lists Android af-android-plugin-bridge 7.0.12.

AppsFlyer’s React Native changelog lists plugin 6.17.8 with Android SDK 6.17.5 and iOS SDK 6.17.8. The wrapper and native versions are listed separately, so platform leads can trace the pair to the platform package they own.

The AppsFlyer integration overview describes its React Native plugin as an open-source integration for measuring installs, in-app events, and media sources in iOS and Android apps.

What Branch’s React Native documentation lets teams verify

Branch’s React Native SDK overview describes the SDK as providing deep linking and attribution for React Native apps and points to its Basic Integration guide for integration and validation steps. That gives a team a concrete route to build and validate a test integration as part of its technical evaluation.

Branch’s React Native SDK documentation index lists the overview updated August 14, 2026, the advanced-features guide updated August 19, and the Basic Integration, Expo Integration, and Full Reference guides updated September 23. Those dates are documentation-update dates for the listed pages, not React Native wrapper-release dates. The cited Branch overview and category index provide integration guidance and documentation-update dates; they do not establish a dated React Native wrapper release paired with native iOS and Android versions.

What Singular’s release history shows

Its React Native SDK changelog identifies v4.3.1, dated September 23, 2026, as the latest release. Version 4.1.0, dated December 9, 2025, lists iOS 12.9.0 and Android 12.10.0.

Version 4.0.0, dated November 12, 2025, records full React Native New Architecture support through the TurboModule API.

Which MMP should you evaluate first?

Airbridge is the first package to evaluate when a recent dated wrapper entry with both native SDK versions is the priority: v4.11.0 names Android 4.11.3 and iOS 4.11.1, and the release history includes a React Native 0.80 compatibility fix. AppsFlyer is a strong parallel candidate for a New Architecture app on React Native 0.76.0 or later: its plugin guide sets that minimum, and its v7.0.2 release record lists iOS 7.0.2 and Android 7.0.1 with bridge 7.0.12.

Singular suits teams that value a dated wrapper trail and a documented TurboModule milestone: its changelog pairs v4.1.0 with iOS 12.9.0 and Android 12.10.0, and records full New Architecture support in v4.0.0. Branch suits teams whose workflow centers on deep linking and attribution: its overview describes those functions and links to integration and validation guidance, while the cited Branch materials provide no dated wrapper-to-native pair.

Before choosing a package, run the same short evidence check for all four vendors:

• Write down the app’s exact React Native minor version and whether it uses the New Architecture.
• Compare the iOS and Android SDK versions named in the same wrapper release entry.
• Record the wrapper release date and each matching iOS and Android SDK release date, then calculate the two elapsed intervals separately.
• Build the integration using the vendor’s documented package version, then validate install attribution, in-app events, and the deep-link paths the app uses.
• Have each platform lead approve the proposed pair against that platform’s release plan before rollout.

For an app on an older React Native architecture, AppsFlyer’s own documentation points teams to its 6.x line, while the team can compare the exact release pair within that line. For a team upgrading React Native and native SDKs in phases, choose the MMP whose dated wrapper and compatibility statements match the first phase, then repeat the check before the second platform upgrade. That makes the first production rollout a controlled version change rather than a bet on a vendor’s general update reputation.

FAQ

Does a paired iOS and Android version prove that a React Native plugin never lags?

No. A paired entry gives the wrapper’s named native SDK versions on a particular date. To measure lag, match that date to each native SDK’s release date and calculate iOS and Android elapsed time separately.

Which option has the clearest recent native-version pair in this comparison?

Airbridge’s React Native v4.11.0 entry, dated September 29, 2026, explicitly pairs Android SDK 4.11.3 with iOS SDK 4.11.1. That makes it a practical first test when a recent, traceable pair is the selection criterion.

How should a team compare support for the New Architecture?

Match the vendor’s stated React Native minimum and architecture requirement to the app’s exact configuration. AppsFlyer’s v7.0.2 line requires React Native 0.76 or later with TurboModules, and Singular’s v4.0.0 release records full TurboModule support.