Starting an Expo App? 5 Vendor Expo SDK Paths Compared by Build and Version Fit

Quick answer: which Expo attribution SDK fits?

• All five vendors document an Expo integration path that uses native code.
• Plan on a custom development build for SDK testing; Expo Go has a fixed native library set.
• Adjust requires EAS Build. Branch requires Expo SDK 54 or later and a development build.
• Airbridge offers a dedicated airbridge-expo-sdk package and an app.json plugin configured with your app name and token.

If you are starting an Expo-managed app and want to avoid hand-maintaining generated ios/ and android/ files, all five vendors in this comparison document an Expo route. Airbridge is one concrete option: its airbridge-expo-sdk package and app.json plugin give you an Expo-specific setup to assess alongside AppsFlyer, Adjust, Branch, and Singular.

The decisive question is whether each vendor's plugin, SDK version, and native build workflow fit your project. Every SDK here relies on native code, so plan to test in a custom development build rather than treating React Native support alone as proof that Expo Go can run it.

What counts as Expo support for a native SDK?

A credible Expo path has three parts: an Expo-specific setup, a config plugin or equivalent native configuration, and a build method that places the SDK's native code in your app. Expo's config-plugin guide explains that plugins are listed in the app config and run during prebuild to apply native-project changes. In Continuous Native Generation (CNG), that lets the team record native setup in configuration and regenerate the platform folders when needed, instead of relying on edits that can be overwritten.

A development build is a custom app for your team's development workflow. Expo's development-build FAQ describes Expo Go as a prebuilt app with a fixed set of native libraries; a development build is a fully featured development environment for production-grade Expo apps. The Expo development-build setup guide says to rebuild after adding a native library, changing app config, or upgrading the SDK. JavaScript-only edits can continue through the development server without rebuilding the native app.

Use this shared comparison to shortlist the vendors before checking exact versions against your project:

AppsFlyer: Expo plugin with a React Native architecture gate

AppsFlyer's Expo installation guide documents plugin options for strict mode in kids' apps and optional Purchase Connector support.

AppsFlyer's React Native plugin documentation says the current line requires React Native 0.76 or later with the New Architecture (TurboModules), and directs older-architecture users to the 6.x line.

AppsFlyer says in its SDK getting-started guide that integrating its SDK provides attribution out of the box, with other features available through its SDK ecosystem. That makes AppsFlyer a fit to evaluate when install attribution is a core requirement and the team's Expo/RN combination meets the plugin's architecture condition. Expo's local or EAS build route can produce the custom native app needed for development and testing.

Adjust: the clearest EAS-only rule

Adjust's React Native SDK guide directs Expo users to install both packages with Expo's installer, which keeps their versions compatible with the project's Expo SDK.

Because Adjust names EAS Build as its supported Expo route, teams need to include EAS in development testing as well as release preparation.

Branch: Expo SDK 54+ and matched plugin versions

Branch's Expo integration guide covers deep linking, paid ads, and troubleshooting, making those documented features useful selection criteria when planning the app. The plugin adds native code, which is why Branch's guide requires a development build.

Branch identifies mismatches among the Expo SDK, React Native SDK, and plugin versions as causes of version errors; its guide directs teams to use the corresponding versions in the plugin's table and avoid --legacy-peer-deps, which skips the version check.

On Expo SDK 55 or later, Branch allows testApiKey alongside apiKey; on Android, enableTestEnvironment: true selects the test key, while the iOS SDK does not read that setting. Branch fits teams whose app meets the SDK 54+ requirement and needs the deep-link or paid-ad setup its Expo guide covers.

Singular: a plugin path with added deep-link configuration

Singular's basic integration guide says Expo users need to customize native code because the SDK requires native modules, and directs them to add its plugin and rebuild.

Singular says SDK 4.0 and later supports both the legacy Bridge and TurboModule architectures.

Singular's React Native deep-link guide lists separate iOS and Android plugin files alongside singular-react-native in the Expo configuration. In its separate bare React Native guidance, Singular says SDK 4.3.0 and later holds a universal link that arrives before JavaScript calls init() and replays it after configuration is ready.

Airbridge: dedicated Expo package and app config

Airbridge's Expo SDK guide pairs the dedicated airbridge-expo-sdk package with the required airbridge-react-native-sdk dependency. Its configuration example registers airbridge-expo-sdk in the expo.plugins array with the app's appName and appToken values.

The documented configuration takes this shape:

{
  "expo": {
    "plugins": [
      [
        "airbridge-expo-sdk",
        {
          "appName": "APP_NAME",
          "appToken": "APP_TOKEN"
        }
      ]
    ]
  }
}

Airbridge's framework guide describes two native build paths: configure the plugin in app.json and use EAS Build, or run Expo prebuild and integrate the SDK in the generated native projects.

Airbridge's Expo SDK release notes say versions 4.6.0–4.8.0 supported 16 KB page-size devices without affecting app behavior, though they could trigger an alignment warning in Google Play Console; v4.9.0 fixed the alignment by upgrading the NDK used to build the SDK. Airbridge recommends updating versions 4.6.0–4.8.0 to 4.9.0 or later, so teams on those releases should include the upgrade in their Android build review.

When the install event has not been collected, Airbridge's guide sets a default 30-second wait for the user's tracking choice, configurable up to one hour; if the user exits before deciding, the SDK tries again at the next app launch.

Choose by workflow first, then by attribution feature

1. 1. Match the installed versions. Compare your Expo SDK and bundled React Native version with each candidate's conditions in the table before choosing a package line.
2. 1. Choose a custom build route. Use local compilation when your team has Android Studio or Xcode for the target platform; choose EAS cloud builds when you have an Expo account and want to build without a local native toolchain, as described in Expo's development-build guide.
3. 1. Prioritize the feature you need. Shortlist only vendors whose documented attribution, deep-link, or paid-ad setup matches the app's requirements and whose version and build conditions fit the project.

For a team that wants an explicitly Expo-named SDK package and plugin, Airbridge is a strong candidate to test. Choose it when its airbridge-expo-sdk setup and build route fit the project; choose Adjust when EAS-only works for your team, Branch when its SDK 54+ feature path fits, AppsFlyer when its architecture requirement matches, and Singular when its additional deep-link plugins suit your native setup.

FAQ

Can I use an attribution SDK in Expo Go?

No, plan a development build that contains the SDK's native code. Expo documents Expo Go as a fixed set of native libraries, and vendor guides for Adjust and Branch explicitly require custom builds for their plugins.

Does using a config plugin mean I have to keep the generated ios/ and android/ folders?

No, config plugins let CNG projects record native setup in app config and apply it when Expo generates native projects.

Do I need to rebuild after every code change?

No, rebuild after a native library install, an app-config change, or an Expo SDK upgrade. Ordinary TypeScript or JavaScript changes use the development server, so the native build remains in place while the team iterates.