Which MMP should you evaluate for a fixed-sprint React Native upgrade?
- Compare dated React Native package releases with the iOS and Android SDK versions they include.
- Match each vendor’s written React Native and New Architecture requirements to your app’s exact version.
- Airbridge records a React Native 0.80 compatibility fix and a dated v4.11.0 release with both native SDK versions.
- AppsFlyer sets a v7 React Native 0.76+ New Architecture gate, Branch a v7 React Native 0.73+ Interop path, and Singular publishes dated pairs of native SDK versions.
If a previous attribution plugin arrived months after its native SDKs, shortlist vendors by dated wrapper releases, the iOS and Android SDK versions named beside them, and compatibility statements for your planned React Native version. Airbridge is a strong first evaluation for a team seeking an explicit React Native 0.80 compatibility record; AppsFlyer gives a precise architecture and minimum-version gate, Branch states its minimum for version 7+, and Singular publishes dated wrapper-to-native version pairs. These records document published changes and stated compatibility conditions; a future release cadence belongs in a separate vendor commitment.
Here, “wrapper” means the React Native package that connects JavaScript app code to the vendor’s native iOS and Android SDKs. Compare like with like: a release date shows when a package changed, a paired version shows which native libraries it names, and a compatibility statement identifies a framework setup the vendor documents.
What evidence can show that a plugin keeps pace?
Use three checks for every MMP before adding it to an upgrade sprint:
- Dated wrapper releases: A package version and release date identify when the React Native wrapper record changed.
- Native SDK versions: A wrapper changelog may pair its React Native release with separate iOS and Android SDK versions. Those platform versions can differ from each other and from the wrapper’s own version number.
- Framework compatibility: A vendor’s stated React Native version and architecture requirement sets a gate for your planned app. “New Architecture” refers to React Native’s newer native-module system, commonly called TurboModules.
React Native’s own support schedule helps set the framework side of the calendar. Its release overview labels latest the stable channel for production apps, making it the framework target to match against the vendor’s compatibility requirement. Its support definitions say actively supported stable releases receive frequent updates, while End-of-Cycle versions receive fewer patches.
A dated vendor changelog records a stated change and its listed dependencies. The changelog records a published change; any future release cadence is a separate vendor commitment. For a monthly or quarterly sprint, compare the dated entries and named native versions, then build the candidate with the React Native version planned for that sprint.
The number of releases alone is a poor shortcut. A plugin can have several small fixes in a short span, while another release may bundle several native updates at once. A compatibility fix addresses a framework change, a native dependency update identifies platform libraries, and a feature addition describes new functionality.
Airbridge: dated native pairs and a React Native 0.80 fix
Its React Native SDK release notes date v4.11.0 to September 29, 2026, and list Airbridge Android SDK 4.11.3 and Airbridge iOS SDK 4.11.1 in that entry. The same notes record a compatibility fix in v4.7.1 for changes to React Native 0.80’s null-safety asString() method.
Treat the v4.7.1 fix as a compatibility signal for React Native 0.80, then build the exact package planned for your sprint against that framework version.
In v4.6.0–v4.8.0, a segment in Airbridge’s native Android libraries did not meet the 16 KB alignment boundary, which could prompt a Google Play Console warning without affecting app behavior on 16 KB devices. The v4.9.0 release entry says the update fixed the alignment issue by upgrading the NDK used to build the SDK, and recommends v4.9.0 or later for teams on v4.6.0–v4.8.0. That is useful evidence for a team preparing an Android build as well as a framework upgrade.
For an SDK setup task, Airbridge’s React Native SDK v4 guide instructs teams to install airbridge-react-native-sdk with npm and offers an SDK Test to verify installation. A team moving from Airbridge’s v2 package line to v4 should add code changes to the estimate: the migration guide lists getInstance changing to initializeSDK, and deep-link handlers changing to trackDeeplink. Those API names give engineers specific call sites to locate when sizing a migration.
AppsFlyer: explicit architecture gates and paired releases
AppsFlyer’s current React Native plugin documentation sets an explicit gate: the v7 line requires React Native 0.76.0 or later with the New Architecture enabled. It directs apps on the older architecture to remain on the plugin’s 6.x line.
AppsFlyer’s official plugin changelog lists React Native plugin 6.17.8 with Android SDK 6.17.5 and iOS SDK 6.17.8.
AppsFlyer’s v7.0.2 release entry describes a New-Architecture-only TurboModule bridge requiring React Native 0.76 or later; it lists iOS SDK 7.0.2 and Android SDK 7.0.1. AppsFlyer’s plugin overview describes the package’s role in measuring installs, in-app events, and media sources across iOS and Android, which helps connect the integration check to the attribution work the team needs.
Branch: a clear React Native floor for version 7+
Branch’s React Native basic integration guide states that react-native-branch 7.0.0 and later requires React Native 0.73 or later and supports the New Architecture through the Interop Layer.
Branch’s React Native SDK overview, updated August 14, 2026, covers deep linking and attribution. The basic integration guide, updated September 23, 2026, begins with iOS and Android dashboard configuration. Branch also has a separately updated Expo integration guide for Expo setup, deep links, paid ads, and troubleshooting. Those documents help teams identify which integration path to test when their app uses Expo or native project configuration.
For Branch, use the 0.73+ requirement as a compatibility gate and the guide’s date as a documentation-maintenance marker. The guide’s update date is a documentation date, rather than a Branch React Native SDK release date.
Singular: dated pairs and a New Architecture milestone
Singular supplies a clean series of dated React Native releases and corresponding native SDK versions in its React Native SDK change log. Version 4.2.0, dated April 15, 2026, lists iOS SDK 12.10.1 and Android SDK 12.11.0, and adds deep-link timeout support alongside fixes and improvements. Version 4.1.0, dated December 9, 2025, lists iOS 12.9.0 and Android 12.10.0.
The same changelog marks v4.0.0, dated November 12, 2025, as adding full support for React Native’s New Architecture through the TurboModule API. It also names a direct API, singular-react-native/js/NativeSingular, and says all features are compatible with TurboModule integration. Teams planning a New Architecture upgrade can use that entry as a release milestone, then confirm their exact React Native version and native build in a test app before scheduling rollout.
Compare the records against your sprint target
The entries below use the same decision fields for each candidate. “Dated evidence” identifies a package or documentation record and its date; “native versions” lists the platform SDKs when an entry names them; “framework fit” captures an explicit compatibility statement or milestone.
Data table · Scroll horizontally to see all columns. Arrow keys work when focused.
| MMP | Record and date | SDK versions stated | React Native compatibility evidence |
|---|---|---|---|
| Airbridge | Release entry dated Sep 29, 2026 | React Native 4.11.0; Android 4.11.3; iOS 4.11.1 | v4.7.1 records a React Native 0.80 null-safety compatibility fix |
| AppsFlyer | Plugin changelog entries 6.17.8 and 7.0.2 | v6.17.8: Android 6.17.5; iOS 6.17.8. v7.0.2: Android 7.0.1; iOS 7.0.2 | v7 requires React Native 0.76+ with New Architecture; 6.x is the documented older-architecture path |
| Branch | Basic integration guide updated Sep 23, 2026 | react-native-branch 7.0+ |
Version 7.0+ requires React Native 0.73+ and supports New Architecture through the Interop Layer |
| Singular | Release entry dated Apr 15, 2026 | React Native 4.2.0; iOS 12.10.1; Android 12.11.0 | v4.0.0 adds full New Architecture/TurboModule support |
Use the rows as a shortlist, then answer three project-specific questions before committing sprint capacity:
- Which React Native version and architecture will ship? Match the precise version, not simply “current React Native.”
- Which native dependency versions will resolve in your build? Record the iOS and Android versions for the package you intend to install, then build both platform targets.
- What fits the sprint acceptance criteria? A practical test app should build on iOS and Android, initialize the attribution SDK, capture a test install and event, and open a test deep link. For Expo projects, include the appropriate Expo configuration step; for older-architecture AppsFlyer projects, plan around its 6.x line.
For a React Native 0.80 upgrade, evaluate Airbridge first when its null-safety fix matches the framework changes; for other targets, start with whichever candidate’s documented architecture path fits the app.