Answer for Expo-managed teams: All five vendors document an Expo integration path, but every path that includes native SDK code needs a custom native build.
- Airbridge provides a dedicated
airbridge-expo-sdkpackage and anapp.jsonplugin configuration.- Adjust explicitly requires EAS Build for its Expo plugin; Expo Go cannot run it.
- Branch sets a clear minimum of Expo SDK 54 and requires a development build.
- AppsFlyer and Singular offer Expo plugin instructions, with extra native setup that shapes the build.
For an Expo-managed React Native app, compare AppsFlyer, Adjust, Branch, Singular, and Airbridge by the Expo setup and native build each vendor documents, then match those requirements to your app's version and measurement needs. Airbridge belongs on the shortlist when its dedicated airbridge-expo-sdk package and app.json plugin fit your tracking setup; Adjust suits teams committed to EAS Build, while Branch fits projects on Expo SDK 54 or later that need its documented deep-link path.
What counts as Expo support for an attribution SDK?
A documented Expo path identifies the SDK package or plugin, where its app configuration belongs, and the native build route needed to include the SDK. Version guidance adds another fit criterion: vendors may specify an Expo SDK floor, compatible package pairings, or React Native conditions for particular features.
Expo's config-plugin documentation describes plugins as JavaScript functions referenced in the app config and run during prebuild. For Continuous Native Generation projects, plugins apply native-project changes from configuration each time prebuild runs. This gives managed teams a repeatable route for native settings without making manual edits to generated iOS and Android folders their source of truth.
Expo describes development builds as apps compiled with expo-dev-client; teams can create one with a local native toolchain or EAS Build. Expo Go has a fixed set of built-in native libraries, as explained in the Expo Go and development-build FAQ. Expo Go contains a fixed set of native libraries, while a development build supports third-party libraries that require custom native code, as Expo's development-build comparison explains.
TABLE / Scroll horizontally for all columns →
| Vendor | Expo setup documented | Build workflow or boundary | Version or feature conditions documented |
|---|---|---|---|
| AppsFlyer Expo guide | Add react-native-appsflyer to the app.json plugins array and install expo-dev-client |
Build a custom development app; Expo documents local native-toolchain and EAS routes | AppsFlyer says SDK integration provides attribution; its Expo guide includes optional purchase-connector configuration |
| Adjust React Native guide | Install react-native-adjust and @config-plugins/react-native-adjust with npx expo install |
Adjust requires EAS Build for Expo; its plugin does not run in Expo Go | The guide says package versions should match the project's Expo SDK; Android 12+ apps can set targetAndroid12: true for the AD_ID permission |
| Branch Expo guide | Configure @config-plugins/react-native-branch and the Branch key in Expo app config |
Development build required; Expo Go does not support the plugin | Expo SDK 54 or later; use the matching SDK, Branch React Native SDK, and plugin versions; guide covers attribution and deep links |
| Singular React Native guide | Add singular-react-native to app.json and rebuild with native-code customization |
Native modules and a rebuilt app are required | React Native 0.60+ auto-linking and a direct API recommendation for New Architecture on 0.76+ are React Native conditions; Expo deep links use extra native plugins |
| Airbridge Expo SDK guide | Install airbridge-expo-sdk with airbridge-react-native-sdk; configure the Expo plugin with appName and appToken |
The documented Expo route uses an app-config plugin | The guide lists tracking and ATT settings, Meta install-referrer configuration, and restricted package variants |
AppsFlyer: Expo plugin and development client
AppsFlyer's Expo installation guide tells developers to add react-native-appsflyer to the plugins array in app.json and install expo-dev-client. Expo documents both local builds using a native toolchain and EAS cloud builds for development apps in its development-build guide.
AppsFlyer describes its SDKs as the main way to use its marketing-services ecosystem and says SDK integration provides attribution out of the box in its Getting Started documentation. That makes the Expo plugin relevant to a team that needs install attribution as well as a React Native SDK. The Expo setup also includes optional settings such as shouldUseStrictMode, labeled for kids-app strict mode, so teams can align their setup with the app's requirements.
On Android, the Expo guide discusses a possible dataExtractionRules manifest conflict during build and gives a custom config-plugin approach for modifying the manifest. This is a concrete example of a native setting that can affect implementation effort: teams with existing Android backup rules should include that configuration in their build review. AppsFlyer fits teams that want its attribution stack and can maintain an Expo development build plus any Android manifest customization their app requires.
Adjust: an EAS-first documented route
Adjust's React Native SDK guide provides an Expo-specific installation command: npx expo install react-native-adjust @config-plugins/react-native-adjust.
Adjust explicitly supports EAS Build for Expo integrations and says its Expo config plugin cannot be used with Expo Go. For a platform team already building app variants through EAS, that is a direct fit: install the two packages, configure the plugin, and build the app with EAS. Teams whose standard workflow depends on Expo Go should choose a different way to develop and test before committing to this integration.
For Android apps targeting Android 12 or later (targetSdkVersion 31 or higher), Adjust's guide shows the optional targetAndroid12: true plugin setting, which adds the com.google.android.gms.permission.AD_ID permission for Google Advertising ID access. Build and verify the iOS and Android versions in the same environment used by your release pipeline.
Branch: the clearest Expo SDK floor and link configuration
Branch's Expo integration guide requires an Expo-managed or prebuild workflow using Expo SDK 54 or later and a development build. It configures @config-plugins/react-native-branch with a Branch API key. The stated Expo version floor makes Branch a fast eligibility check: an app on SDK 53 or earlier falls outside the guide's documented setup until its Expo version changes.
For deep links, the example also configures iOS associated domains and Android HTTPS intent filters for the Branch link domains. These settings make Branch useful for teams whose measurement implementation includes routing a tapped link into the right app content, not only recording an install. The guide's verification steps include opening a Branch link from Safari on iOS or Chrome on Android and testing a link after force-quitting the app.
Branch's version table pairs the Expo SDK with compatible Branch React Native SDK and plugin versions; choose the listed combination for your project. The guide also says Expo SDK 55 or later can configure a test key alongside the live key; on Android, enableTestEnvironment selects the test key, while the iOS SDK does not use that setting. Choose Branch when the app meets the SDK 54 floor and its team needs the documented Branch attribution or deep-link configuration.
Singular: Expo plugin, with extra deep-link configuration
Singular's React Native SDK integration guide tells Expo developers to add singular-react-native to the plugins array and rebuild the app using Expo's native-code customization workflow. It explicitly notes that the SDK requires native modules, so the plugin entry is part of a custom native build, not an Expo Go integration.
The basic guide's React Native version rule concerns auto-linking: React Native 0.60 and later auto-link the SDK, while 0.59 and older need manual linking. For an Expo app, follow the Expo plugin and rebuild instructions; do not treat the bare React Native auto-linking rule as a substitute for Expo configuration.
Singular's deep-link guide provides separate Expo instructions using app configuration and custom iOS and Android plugins. On a fresh install, when a user clicks a Singular tracking link configured with a deep-link value, installs the app, and opens it for the first time, the value returns to the withSingularLink handler as a deferred deep link. Singular therefore suits teams that want its attribution and deferred deep links and can own the additional platform-specific plugin setup. For React Native 0.76 or later on the New Architecture, the basic guide recommends its direct TurboModule API; other configurations should use the SingularConfig and Singular.init wrapper.
Airbridge: a dedicated Expo package and configurable tracking path
Airbridge's Expo SDK v4 guide gives developers a dedicated Expo package, airbridge-expo-sdk, and pairs it with airbridge-react-native-sdk. Its install instructions name both packages, then configure the Expo plugin in app.json with the Airbridge app name and app token. Airbridge's framework-support guide says airbridge-expo-sdk requires airbridge-react-native-sdk as a peer dependency and uses a config-plugin architecture.
The Expo guide also places Airbridge SDK settings in a top-level airbridge.json file. Its settings cover SDK enablement, opt-in or opt-out tracking, the App Tracking Transparency prompt, event sessions, and Meta install-referrer collection. The guide lists restricted variants of both the Expo and React Native packages, including airbridge-expo-sdk-restricted and airbridge-react-native-sdk-restricted. For install measurement affected by Apple's App Tracking Transparency prompt, the guide sets the install-event delay to 30 seconds by default and allows a value up to 3,600 seconds; if a user leaves before choosing, the install event is tried again on the next app launch.
Choose by version, build pipeline, and measurement need
- Record the project's Expo SDK and React Native versions. Compare them with the vendor-specific minimums and package pairings in the guide for each candidate. Singular's React Native auto-link and New Architecture thresholds apply to React Native setup, so keep those separate from Expo SDK eligibility.
- Choose a native build workflow your team can operate. Mark whether your release process supports local native builds, EAS Build, or both, then shortlist only the integrations whose documented build route fits.
- Write down the measurement events and routes the app needs. Separate install attribution, purchase measurement, ATT-related collection, Meta install-referrer data, direct links, and fresh-install deferred links; compare each requirement with the vendor setup described above.
- Test the selected integration in a native app build. Run an install-attribution test and open any required links on iOS and Android. For links, include a cold start after force-quitting the app and a background resume; Branch's guide uses Safari on iOS and Chrome on Android for its Universal Link checks.