Choose the SDK whose native-build and plugin-support demands fit the workflow your team can maintain.
- Choose Airbridge for a named Expo package and a vendor-documented
app.jsonplugin setup.- Choose Adjust when you want its guide to explicitly require EAS Build and reject Expo Go.
- Choose Branch when Expo SDK 54 or higher fits your project and your team accepts a community-maintained plugin.
- Choose AppsFlyer when its Expo plugin path fits, and include its Android manifest guidance in build planning.
Airbridge is a clear fit for a small team that wants a named Expo package and config-plugin workflow: its Expo SDK guide names airbridge-expo-sdk and shows how to configure the plugin in app.json. Branch specifies Expo SDK 54 or higher and a development build, Adjust requires EAS Build, and AppsFlyer documents a plugin-based Expo setup.
What counts as explicit Expo support?
A useful Expo comparison records four details for each option: the named package or plugin, the vendor's Expo Go statement, the documented build path, and who maintains the plugin.
Expo's third-party library guidance recommends checking whether a library contains android or ios directories, calls for linking, changes native project files such as AndroidManifest.xml, Podfile, or Info.plist, or provides a config plugin. Expo recommends creating a development build if any of those checks apply.
Expo Go and a development build use different native apps. Expo's development-build FAQ explains that Expo Go has a fixed set of native libraries, while a development build lets the team add native libraries and change native configuration. If an SDK calls native code that Expo Go does not contain, its JavaScript package alone cannot make that native code available.
Expo Go also gives mobile attribution teams a less realistic test environment for certain functions. Expo's Expo Go vs. development builds guide says Expo Go does not accurately simulate analytics or deep and universal links, and it does not use the app's own package name or bundle identifier. A development build is the sounder choice for testing SDK setup alongside the app's actual identifiers and link behavior.
Airbridge: a named Expo package and app-config plugin
Airbridge publishes an Expo-specific installation path rather than asking teams to infer Expo support from React Native instructions. Its Expo SDK guide directs developers to install airbridge-expo-sdk and airbridge-react-native-sdk together:
npm install --save airbridge-expo-sdk
npm install --save airbridge-react-native-sdk
The same guide shows airbridge-expo-sdk in the plugins array in app.json, with appName and appToken set to the Airbridge app name and App SDK token. That gives an implementation team both the package names and the place where Expo configuration belongs, which makes Airbridge a clear option when the goal is to keep the integration in an app-config workflow.
Airbridge's framework guide says MMP SDKs require EAS Build or Expo prebuild to work, giving this integration a native-build path alongside its named Expo package.
The guide also asks developers to create an airbridge.json file at the top of the project and configure SDK settings there. The settings reference includes controls for enabling the SDK, log level, automatic tracking startup, session timeouts, and deep-link handling. Teams can therefore keep the app-specific plugin credentials in Expo app configuration and review SDK behavior settings in the separate Airbridge configuration file.
Airbridge's settings reference also includes event-buffer limits and transmission frequency, custom tracking-link domains, user-information hashing, and a control for collecting TCF data related to Google DMA compliance.
Airbridge's Expo SDK guide lists a restricted package pair as an alternative: airbridge-expo-sdk-restricted and airbridge-react-native-sdk-restricted. Airbridge says the restricted SDK version does not collect device IDs such as GAID and IDFA.
Branch: documented Expo route, community-maintained plugin
Branch's React Native SDK Expo integration guide requires an Expo-managed or prebuild project using Expo SDK 54 or higher and a development build. The guide says Expo Go does not support the plugin because it adds native code.
Branch's Expo guide says it maintains the Branch React Native SDK, while the @config-plugins/react-native-branch plugin is community-maintained in Expo's config-plugins repository; plugin issues go to that repository's issue tracker.
The guide says version errors mean the Expo SDK, Branch React Native SDK, and plugin versions do not match; use the plugin's version table for your Expo SDK, because --legacy-peer-deps skips the version check and can leave incompatible versions. Branch suits a team that wants a published Expo path and can take responsibility for troubleshooting a community-maintained plugin as a separate dependency.
Branch's Expo integration guide also says a local build fails when BRANCH_API_KEY is unset, even if the team is not testing Branch functionality. It recommends loading the plugin only for production builds in that case, which gives developers a specific way to keep unrelated local builds moving.
Adjust: the clearest EAS Build requirement
Adjust publishes an Expo integration in its React Native SDK guide. The guide says Adjust officially supports EAS Build for Expo integrations, says the Expo config plugin cannot be used with Expo Go, and requires the app to be built with EAS Build. For teams choosing Adjust, that is a direct runtime decision: schedule an EAS native build as part of integration work.
Adjust also gives an Expo-aware install command for both the SDK and its plugin: npx expo install react-native-adjust @config-plugins/react-native-adjust. The command is designed to select versions compatible with the project's Expo SDK. The guide then shows the plugin in the Expo configuration, so the SDK and its native configuration are represented in the same setup path.
AppsFlyer: Expo plugin setup with an Android manifest check
AppsFlyer's Expo installation guide instructs developers to add react-native-appsflyer to the plugins array in the app's app.json. Expo's library guidance recommends a development build when a library has a config plugin, so test this integration in a built native app.
AppsFlyer also flags a possible Android build issue involving dataExtractionRules in the project's AndroidManifest.xml and the rule included with the AppsFlyer SDK. Its guide describes using a custom Expo config plugin to modify the manifest during the build, preserving managed-workflow compatibility without editing the generated manifest by hand. For a team selecting AppsFlyer, this makes Android manifest review a practical part of planning and troubleshooting the Expo build.
The preferAppsFlyerBackupRules option defaults to false; at that setting, the app's android:dataExtractionRules and android:fullBackupContent remain untouched, leaving the app's backup policy in control. Setting it to true opts into the SDK's backup rules, which AppsFlyer says support install and reinstall detection. The guide also lists optional shouldUsePurchaseConnector for Purchase Connector and shouldUseStrictMode for strict mode in kids' apps, so teams can include those plugin options only when they match their product.
Which SDK fits your planned Expo runtime?
| SDK | Expo-specific evidence | Expo Go statement and documented build path | Best fit |
|---|---|---|---|
| Airbridge | Dedicated airbridge-expo-sdk package and app.json plugin with app name and token | Expo recommends a development build for a config-plugin library; Airbridge's framework guide says MMP SDKs require EAS Build or Expo prebuild | A team wanting a clearly named Expo package and a documented app-config setup |
| Branch | Expo-managed or prebuild route, with Branch SDK and community-maintained plugin | Expo SDK 54 or higher and a development build; Expo Go does not support the plugin | A team prepared to manage plugin version matching and community-plugin support |
| Adjust | react-native-adjust plus @config-plugins/react-native-adjust | EAS Build is required; the plugin cannot be used with Expo Go | A team that wants an explicit EAS Build requirement and Expo-aware installation |
| AppsFlyer | react-native-appsflyer registered in app.json | Expo recommends a development build for a config-plugin library; AppsFlyer flags a possible dataExtractionRules conflict | A team whose existing AppsFlyer setup and Android configuration fit its documented plugin path |
Expo's development-build creation guide explains that when expo-dev-client is installed, npx expo start targets the development build instead of Expo Go. This gives the team a practical check after native setup: install the built development client, launch the project against it, and test the app's attribution and deep-link flow in the runtime intended for release.
Before implementation starts, put a short runtime gate in the integration ticket:
- Record the exact Expo SDK version and whether the project uses managed Expo or prebuild.
- Record the selected SDK and plugin versions; for Branch, match the plugin version table to the project's Expo SDK.
- Assign a build owner who can produce the development build Branch requires or the EAS Build Adjust requires.
- Record the plugin's issue route separately from the SDK support route, especially for Branch.
- List the attribution and deep-link flows QA will exercise in the development build, using the app's own identifiers.