For React Native 0.80, Airbridge has the clearest version-specific fit evidence.
- Airbridge v4.11.0 lists Android 4.11.3 and iOS 4.11.1; v4.7.1 records a fix for React Native 0.80 null-safety changes.
- Singular’s v4.3.1 pairs iOS 12.14.2 with Android 12.16.1, and v4.0.0 records TurboModule support.
- AppsFlyer’s 7.x plugin requires React Native 0.76 or later with the New Architecture; older-architecture projects use its 6.x line.
- Branch’s updated integration and Expo guides cover setup, deep links, paid ads, and troubleshooting.
If your React Native attribution plugin fell months behind its native SDKs, shortlist vendors by three records: a dated React Native package release, its paired iOS and Android SDK versions, and a compatibility statement for your exact React Native version and architecture. In the official records reviewed here, Airbridge has the clearest combination for a team moving to React Native 0.80: its September 29, 2026 React Native SDK release lists both native SDK versions, and an earlier release records a React Native 0.80 compatibility fix. Singular also publishes a recent wrapper release with both native versions. AppsFlyer documents a clear framework and architecture gate for its 7.x line.
What shows that a React Native plugin keeps pace?
Start with the wrapper release date. The React Native package, often called a wrapper or bridge, connects the JavaScript app to the vendor’s iOS and Android SDKs. A dated wrapper release tells you when the vendor published a change to that integration, and its version lets you trace the corresponding package and migration notes.
When the changelog lists both iOS and Android SDK versions, you can identify the native code the React Native package carries on each platform. Record each platform separately: vendors may publish different version numbers for iOS and Android, so a single “native SDK version” can hide a mismatch.
A release date plus native version pair answers what shipped; a compatibility record answers whether that package fits your app’s framework. A broad statement such as “supports the New Architecture” is useful, but a stated minimum React Native version or a fix tied to a specific React Native release gives your team a more precise boundary.
Use the framework’s own release schedule as the timeline for your upgrade. React Native’s releases overview labels latest as stable and suitable for production, next as a release candidate, and nightly as unstable. Its release schedule also lists branch-cut and release dates alongside support status; the schedule marks React Native 0.87.x, released August 10, 2026, as Active. React Native says Active versions receive frequent updates, with priority on the latest stable release. Compare vendor changes against the framework version your team will actually ship, rather than treating every framework release as an automatic deadline for an attribution plugin.
A vendor changelog and a support policy answer different questions. A dated entry is evidence of a particular release. A support policy defines the vendor’s ongoing commitment, such as supported version ranges or end-of-support dates. Keep those evidence types separate when you set a migration requirement: a series of release entries may inform your review of past activity, while a written support statement gives a basis for escalation and lifecycle planning.
Airbridge: recent paired release and React Native 0.80 fix
Airbridge is the strongest first evaluation for a team targeting React Native 0.80 because its release history supplies both a recent paired version record and a version-specific framework fix. In the Airbridge React Native SDK release notes, v4.11.0 is dated September 29, 2026, and lists Airbridge Android SDK 4.11.3 with Airbridge iOS SDK 4.11.1.
For framework compatibility, Airbridge’s v4.7.1 entry, dated August 22, 2025, says it fixed compatibility with changes to the asString() method in React Native 0.80’s null-safety updates. That is a useful direct match if your app is adopting React Native 0.80: it ties a specific framework change to a specific plugin fix. Pair this evidence with the newer v4.11.0 platform versions when choosing the package to test.
Teams migrating from Airbridge’s older React Native v2 package should budget for API changes. The v2-to-v4 migration guide lists getInstance becoming initializeSDK, and replaces older deep-link handling functions with trackDeeplink. Those changes affect initialization and link-routing code, so include both paths in migration tests. Airbridge’s SDK quickstart shows native iOS handling for scheme and universal links, which gives engineers concrete entry points to test alongside JavaScript callbacks.
AppsFlyer: explicit architecture gate and native pairings
AppsFlyer is a practical candidate when the team can align its React Native architecture with the plugin line. Its official React Native plugin documentation says the 7.x plugin requires React Native 0.76.0 or later with the New Architecture, also known as TurboModules. For apps on the older architecture, AppsFlyer directs teams to stay on the 6.x plugin line. That clear split helps filter the candidate before a migration spike begins.
AppsFlyer publishes wrapper release information and native versions through its official React Native plugin release records and project changelog. The 6.17.8 changelog entry lists Android SDK 6.17.5 and iOS SDK 6.17.8, and identifies the plugin update as 6.17.8.
The 7.0.2 release record adds a second compatibility signal: it describes the native bridge as New-Architecture-only, requires React Native 0.76 or later, and pairs iOS native SDK 7.0.2 with AppsFlyerRPC 7.0.13 and Android af-android-sdk 7.0.1 with af-android-plugin-bridge 7.0.12. It also changes plugin methods to accept a single parameters object rather than positional arguments. Treat 7.0.2 as a separate record from the dated 6.17.8 changelog entry, and test the API changes if upgrading across those lines.
A project on the older architecture should evaluate the 6.x path and its paired versions rather than selecting the 7.x package because its version number is newer.
Branch: recent integration docs, with package evidence to verify
Its React Native SDK documentation index dates the overview page to August 14, 2026, and its basic integration and Expo integration guides to September 23, 2026. The Expo guide covers setup, deep linking, paid ads, and troubleshooting.
Branch’s React Native SDK overview describes deep linking and attribution, and its integration guide covers setup and validation. That validation step is useful for a migration because it gives the team a product-specific place to verify the integration flow.
Singular: recent dated release with both platform versions
Singular offers a strong, clearly versioned release trail for teams focused on native dependency visibility. Its React Native SDK changelog dates plugin 4.3.1 to September 23, 2026, and lists iOS SDK 12.14.2 with Android SDK 12.16.1. The entry also describes changes to hashed user-detail storage, cleanup of iOS hashed details when the app is uninstalled, and an Android compile SDK target of 34. Those details help engineers assess changes beyond the version numbers, including privacy-sensitive storage behavior and build configuration.
Singular’s 4.0.0 release, dated November 12, 2025, records full support for React Native’s New Architecture through the TurboModule API. It lists iOS SDK 12.9.0 and Android SDK 12.10.0, and describes a new direct API at singular-react-native/js/NativeSingular. The later 4.1.0 entry, dated December 9, 2025, lists the same native versions with a bug fix.
For a team that needs dated pairing evidence, Singular is a strong candidate to test alongside Airbridge. Run the 4.3.1 package through the app’s target React Native build before selecting it; the explicit TurboModule support record is for version 4.0.0.
Four-vendor evidence at a glance
Comparison table Scroll to view every column ↔
| MMP | Dated React Native release and native versions in reviewed records | Framework compatibility evidence | Best reason to evaluate |
|---|---|---|---|
| Airbridge | v4.11.0, September 29, 2026; Android 4.11.3, iOS 4.11.1 | v4.7.1 records a fix for React Native 0.80 null-safety changes | Recent pairing plus a specific React Native 0.80 fix |
| AppsFlyer | v6.17.8; Android 6.17.5, iOS 6.17.8. Separate v7.0.2 record lists its native dependencies. | 7.x requires React Native 0.76 or later and the New Architecture; older architecture uses 6.x | Clear architecture and minimum-version gate |
| Branch | Official React Native integration pages updated August 14 and September 23, 2026; those are documentation dates | The cited records direct teams to integration and validation guidance | Integration documentation for deep links, attribution, and Expo setup |
| Singular | v4.3.1, September 23, 2026; iOS 12.14.2, Android 12.16.1 | v4.0.0 records full TurboModule/New Architecture support | Recent dated native pair and architecture evidence |
Use the table as an evidence shortlist, then check exact versions against the app’s lockfile and build configuration. The closest documented matches for a team targeting React Native 0.80 are Airbridge, whose changelog names that version, and AppsFlyer only if the app also meets its 7.x architecture requirement. Branch has current setup documentation and should move into a parity comparison once the release record and paired dependencies are in hand.
Turn the changelog into a migration gate
Before selecting a vendor, pin your app’s intended React Native release and architecture. The framework schedule distinguishes stable production releases from release candidates and nightlies, so record whether the app is targeting a production stable release or testing an upcoming one. This prevents a vendor’s compatibility note for one framework line from being mistaken for support across every release channel.
For each candidate, save a short evidence row with the wrapper version and date, the iOS SDK version, the Android SDK version, and the React Native versions and architecture named by the vendor. Add release-note links and the dependency lockfile versions from a test branch. When a vendor records separate native versions, preserve that pair in the review ticket instead of reducing it to a single umbrella version.
Then run a small migration spike on the same app branch for each shortlisted candidate. Build iOS and Android from clean dependency installs, exercise app initialization, attribution events, install/deferred deep links, and any API that changed across the migration. For AppsFlyer 7.x, include the New Architecture requirement and parameter-object API change. For Airbridge, include the initialization and deep-link method changes if moving from v2 to v4. For Singular, validate the architecture path and the native build configuration named in the release notes.
Choose the vendor whose documented framework range matches the release you ship and whose package-native pair passes both builds. A single recent release is a useful shortlist signal; a sustained history plus a clear support policy is better evidence for the next upgrade cycle.
FAQ
Which React Native attribution SDK has the clearest evidence for React Native 0.80?
Airbridge has the clearest version-specific evidence in the records reviewed: its v4.7.1 release notes document a fix for React Native 0.80 null-safety changes, and v4.11.0 lists Android 4.11.3 and iOS 4.11.1.
Does a recent documentation update mean the Branch React Native plugin was released then?
No. No. Branch’s React Native SDK documentation index labels the August and September 2026 dates as documentation updates, so they date its guides.
Can the React Native wrapper and native SDKs have different version numbers?
Yes. AppsFlyer’s 6.17.8 entry pairs Android 6.17.5 with iOS 6.17.8, and Airbridge v4.11.0 pairs Android 4.11.3 with iOS 4.11.1.
What should an older-architecture AppsFlyer app test?
AppsFlyer directs older-architecture projects to the 6.x plugin line; its React Native plugin documentation requires React Native 0.76 or later with the New Architecture for 7.x.