Short answer: Expo Go is a prototype runtime, not a home for native attribution SDKs.
- AppsFlyer, Adjust, Branch, Singular, and Airbridge all document an Expo integration path.
- Adjust explicitly requires EAS Build; Branch requires a development build and Expo SDK 54 or later.
- Airbridge provides a dedicated Expo package,
airbridge-expo-sdk, configured as an Expo plugin.- Match each SDK and plugin to your Expo version, then test in a development build before release.
If your app runs in Expo Go today, you can keep that setup for quick interface work, but plan a native development build before integrating mobile attribution. Airbridge belongs on the shortlist when its dedicated Expo package and app.json plugin suit your team’s workflow; AppsFlyer, Adjust, Branch, and Singular each publish their own Expo path with different build and version conditions.
What counts as support for an Expo-managed app?
Evaluate an Expo-managed SDK on three documented points: its Expo-specific setup path, the native configuration and build it needs, and its stated Expo or React Native version conditions.
Expo Go includes a fixed set of native libraries. In Expo’s development-build FAQ, Expo explains that JavaScript for an absent library may load in Expo Go, but a call to that library’s missing native code errors. A development build is the project’s own native app, compiled with expo-dev-client, so it can include native modules that Expo Go does not bundle.
An Expo config plugin applies native configuration during prebuild. Expo’s config-plugin introduction describes plugins as JavaScript functions listed in the app config and run during the prebuild process; in Continuous Native Generation projects, they make native-project changes reproducible when the project is generated again. That is why a plugin entry in app.json is a useful sign of an Expo-managed integration, while the plugin itself still needs a compatible native build.
For a development build, Expo’s official setup guide starts with npx expo install expo-dev-client. Teams can build locally with Xcode or Android Studio, or use an EAS cloud build without installing a local native toolchain. After adding a native library or changing app configuration, rebuild the native app.
Comparison table Scroll to view every column ↔
| Vendor | Documented Expo path | Build and version fit | Best workflow match |
|---|---|---|---|
| AppsFlyer | React Native SDK with Expo plugin; prebuild injects native launch and link handling | The guide describes automatic AppDelegate integration for Expo SDK 52+ templates; use a native development or release build | Teams that want AppsFlyer attribution plus its documented Expo deep-link wiring |
| Adjust | Install react-native-adjust and @config-plugins/react-native-adjust with npx expo install |
EAS Build required; Expo Go cannot use the plugin | Teams already using or adopting EAS Build |
| Branch | Branch React Native SDK plus @config-plugins/react-native-branch |
Expo SDK 54 or later; development build; plugin version paired with Expo SDK | Teams implementing Branch attribution, links, paid ads, or advanced features |
| Singular | singular-react-native in the Expo plugin list; custom local plugins for Expo deep links |
Native modules require native customization and a rebuild; docs give React Native and Android SDK conditions | Teams comfortable maintaining native config for deep links |
| Airbridge | Dedicated airbridge-expo-sdk package plus airbridge-react-native-sdk; app.json plugin |
Native plugin build required; release notes identify 16 KB page-size support from Expo SDK package v4.6.0 | Teams that value an explicit Expo package and configuration path |
AppsFlyer: Expo plugin with automatic launch and link wiring
AppsFlyer documents an Expo-managed installation in its Expo Installation guide. The guide describes installing the React Native plugin and running Expo prebuild; with the plugin installed, prebuild automatically updates the iOS AppDelegate to connect launch handling, deep links, and attribution. The documented automatic integration covers the Swift template used by Expo SDK 52 and later, as well as the legacy Objective-C template.
AppsFlyer’s SDK getting-started documentation describes attribution as available through its SDK integration, with access to additional SDK features. The Expo installation guide documents a potential Android build error when the app’s dataExtractionRules conflicts with the attribute in the AppsFlyer SDK, and gives a custom config-plugin approach to modify the manifest during the build.
Adjust: a clear EAS Build requirement
Adjust makes the build choice explicit in its React Native SDK integration guide: EAS Build is supported for Expo integrations, the Adjust Expo config plugin cannot be used with Expo Go, and the app must be built with EAS Build. Its setup installs react-native-adjust and @config-plugins/react-native-adjust through Expo’s Expo-aware installer:
npx expo install react-native-adjust @config-plugins/react-native-adjust
Adjust’s guide lists attribution information, event information, callbacks, deep linking, privacy features, and subscription information among its React Native SDK capabilities. Teams needing those functions can evaluate them alongside the EAS-only build route.
Branch: Expo SDK 54 or later and version-matched plugin
Branch’s Expo integration guide supports Expo-managed or prebuild workflows using Expo SDK 54 or later. The guide directs teams to install the Branch React Native SDK and the @config-plugins/react-native-branch plugin at versions listed for their Expo SDK. The same guide requires a development build because the plugin adds native code that Expo Go does not include.
The setup puts the Branch plugin in the app configuration with a Branch API key. Its example also configures iOS universal-link domains and Android HTTPS intent filters, which are the platform-level details a team needs when routing Branch links into the app. Branch’s guide groups its intended use cases as attribution and deep linking, paid ads, and other advanced features.
Branch warns that mismatched Expo SDK, Branch React Native SDK, and plugin versions can cause errors.
Singular: Expo plugin, plus custom deep-link plugins
Singular counts as an Expo option because its React Native SDK setup guide tells Expo users to add singular-react-native to the plugins configuration and rebuild the app. Singular also says the SDK requires native modules, so Expo teams should be familiar with native-code customization.
Singular’s deep-link guide for React Native separates Expo from bare React Native and shows the Expo plugin list with two local plugin files, one for iOS and one for Android. In practice, a team that needs Singular links should budget time to maintain those local native-configuration plugins and configure the withSingularLink callback.
Singular’s setup guide recommends React Native 0.59 or later for auto-linking. It also states that React Native SDK 4.3.1 and later compile against Android API 34. Those are React Native and Android build conditions, respectively, so teams should match them to their app’s native toolchain when evaluating compatibility. Singular suits an Expo team willing to own these configuration details for its chosen attribution and link workflow.
Airbridge: a dedicated Expo SDK and app configuration
Airbridge gives Expo teams a package expressly named airbridge-expo-sdk. Its Expo SDK installation guide instructs developers to install that package together with airbridge-react-native-sdk. It then configures the Expo plugin in app.json with the Airbridge app name and app token:
{
"expo": {
"plugins": [
[
"airbridge-expo-sdk",
{
"appName": "APP_NAME",
"appToken": "APP_TOKEN"
}
]
]
}
}
The same instructions call for an airbridge.json file at the top level of the Expo project to hold SDK settings. The guide lists the restricted package pair as airbridge-expo-sdk-restricted and airbridge-react-native-sdk-restricted. For teams that need to tune the implementation, documented settings include SDK enablement, opt-in or opt-out setup, Meta deferred app links, Meta Install Referrer collection, and Airbridge deep-link handling.
The official release notes add a useful Android packaging check: the Airbridge Expo SDK has supported 16 KB page sizes since v4.6.0, and v4.9.0 corrected a Play Console warning affecting versions v4.6.0 through v4.8.0. Teams targeting devices with 16 KB page sizes should use v4.9.0 or later to avoid that noted warning, while the SDK’s stated runtime behavior on those devices was unaffected by the earlier alignment issue.
Choose by your version, build route, and feature needs
Use this sequence to make the shortlist practical:
- Record your app’s baseline. Note its Expo SDK and React Native versions, target platforms, and available local or EAS build setup. Those details let you apply the vendor-specific conditions in the comparison rather than treating all React Native packages as interchangeable.
- Apply the stated version and build conditions. Branch’s Expo guide sets an Expo SDK 54 minimum and requires a development build. Adjust’s guide requires EAS Build. AppsFlyer’s automatic AppDelegate integration covers its documented SDK 52+ Swift template and legacy Objective-C template; Singular’s React Native version and Android API conditions concern native compatibility, while Airbridge’s 16 KB page-size note depends on its Expo SDK package version.
- Match the implementation to the feature. For campaign links that open app content, compare the platform link configuration and native plugin work: Branch documents iOS associated domains and Android intent filters, while Singular’s Expo deep-link setup includes local iOS and Android plugin files. For attribution and event measurement, compare the particular SDK events, privacy controls, and install-referrer functions the app plans to use, then configure only the functions required by that workflow.
- Validate the native app before release. For Branch, its Link Validator guidance recommends previewing link flows across platforms and click sources before device testing. Its test cases include opening links from Safari on iOS and Chrome on Android, cold-starting from a link, and resuming a backgrounded app. Use equivalent test cases for the link, install-attribution, and consent behavior your own app requires.
Choose the SDK whose documented Expo version conditions and native build requirements match your app; Airbridge is a strong candidate when its dedicated Expo package and named app.json plugin fit that workflow.