FlutterFlow Attribution SDK Integration: Paths Compared
FlutterFlow attribution SDK routes are compared by package, startup, native setup, and build tests; Airbridge is conditional on project support.
A practical test for FlutterFlow attribution SDK routes
- A Flutter SDK guide proves that a vendor supports Flutter, while a FlutterFlow-ready route also needs package, startup, native configuration, and build steps that work in your project.
- Airbridge’s Flutter SDK guide provides a package dependency and Android and iOS startup instructions, making it a conditional option when your project exposes those integration points.
- Make the decision with a clean Android and iOS build, then verify SDK installation and the events or campaign data your team needs.
FlutterFlow attribution SDK integration works when your project can add the vendor’s Flutter package, run its startup initialization, and complete required platform configuration in the built app. A vendor’s Flutter guide is a useful starting point, but the deciding question for a small team is whether FlutterFlow gives you a durable way to complete and test every required step.
What counts as a real FlutterFlow SDK route?
Use four evidence levels when you review a vendor’s setup guide. Each level moves from a convenient builder surface to the actual app lifecycle, where mobile SDKs need to initialize.
| Evidence level | What to look for in the documentation | How it informs your decision |
|---|---|---|
| Built-in integration | FlutterFlow names the vendor and gives setup steps inside the builder | This is direct evidence for a builder-specific path. Follow those exact steps for the app and platform you plan to ship. |
| Flutter package and custom code | The vendor documents a Flutter dependency, initialization API, and any needed custom Dart code | Match the dependency and code to the integration surfaces your project can use, including the SDK's required app-start point. |
| Android or iOS configuration | The vendor identifies native files, lifecycle callbacks, deployment settings, or platform dependencies | Include those platform requirements in the implementation plan and assign an owner who can apply them to the generated app. |
| Build and test scope | The vendor describes how to build or test the SDK, and what that test checks | Use the documented test for its stated purpose, then check campaign attribution and events through the measurement workflow you intend to use. |
A built-in integration may reduce custom code, a package route may require a developer to connect the Dart API, and native configuration may call for someone comfortable with the generated Android or iOS project. Choose the least involved route that still meets your attribution and deep-link requirements.
Which vendors document a Flutter route?
The official materials for all five candidates describe Flutter SDK implementation at the framework level. The table separates what each vendor’s documentation establishes from the FlutterFlow project checks that remain part of your decision.
| Vendor | What its official Flutter material establishes | What to map to your FlutterFlow project |
|---|---|---|
| AppsFlyer | The AppsFlyer developer hub lists a Flutter integration and links to a Flutter plugin repository. | Use the linked integration material to identify package and startup steps, then map them to the build you intend to ship. The hub establishes a Flutter integration entry point. |
| Adjust | The Adjust Flutter integration guide documents adding adjust_sdk in pubspec.yaml, retrieving packages, and initializing early with an app token and environment. | Plan for the dependency and launch-time initialization. Adjust specifies the sandbox environment for tests and production before an app-store submission. |
| Branch | The Branch Flutter SDK reference lists a validator for Branch keys, package name, URI schemes, Android App Links, Universal Links, and link domains. | Use the validator for the SDK and deep-link items it lists; it supplies a concrete verification path for those settings. |
| Singular | The Singular Flutter basic integration guide documents a pubspec.yaml dependency, Dart bindings to native iOS and Android SDKs, and initialization on every app launch. | Plan for a Flutter package, platform SDKs, credentials, and app-launch initialization. Singular says initialization creates a session used for retention metrics. |
| Airbridge | The Airbridge Flutter SDK guide documents the airbridge_flutter_sdk dependency and separate Android and iOS initialization examples. | Plan for the package and app-start configuration on both platforms. The guide documents Flutter SDK steps; map each required step to the workflow your project can implement. |
Is Firebase or Google Analytics the same choice as install attribution?
A Firebase and Google Analytics connection serves a different role from the MMP attribution flow documented in AppsFlyer's GA4 integration guide. For iOS and Android apps that already have Google Analytics for Firebase implemented, the guide sends attribution data and selected in-app events from AppsFlyer to GA4.
AppsFlyer's setup instructions collect Firebase's app_instance_id and ga_session_id and pass them to AppsFlyer before first launch, so installs, sessions, and in-app events can include those identifiers.
What to verify before using Airbridge in FlutterFlow
Airbridge's Flutter SDK guide says SDK 4.11.0 and later supports CocoaPods and Swift Package Manager on iOS and requires an iOS deployment target of 12.0 or higher.
- Add the package. Airbridge's Flutter guide shows
airbridge_flutter_sdkunderdependenciesand directs developers to replace the version placeholder with the latest release. Plan how your project will add and resolve this dependency in the app build. - Place Android initialization at startup. The Android example calls
AirbridgeFlutter.initializeSDK(this, "YOUR_APP_NAME", "YOUR_APP_SDK_TOKEN")inMainApplication.onCreate(), aftersuper.onCreate(), using the app name and SDK token from Airbridge settings. - Place iOS initialization at startup. The Swift example calls
AirbridgeFlutter.initializeSDK(name:token:)inapplication(_:didFinishLaunchingWithOptions:). Airbridge's Flutter SDK troubleshooting guide says apps using the UIScene lifecycle do not call the relevant AppDelegate callbacks and provides SceneDelegate callback guidance. Check the app's lifecycle before choosing where to initialize the SDK. - Review Swift Package Manager settings. Flutter 3.44 and later enables Swift Package Manager by default. With Swift Package Manager,
AIRBRIDGE_ENVIRONMENTdoes not work on iOS. - Run the SDK installation check. Airbridge's guide points to a separate Flutter SDK test for checking whether the SDK was installed correctly. Use that check for installation, then validate a representative attributed install and the post-install events your team plans to use in its reporting workflow.
A short decision checklist
Before committing to a vendor, record the answers for your actual FlutterFlow project:
- Can the build add the vendor’s Flutter package and resolve its dependencies?
- Can you run the SDK’s initialization code at the required app-start point?
- Can you apply any Android and iOS settings the guide requires?
- Can you run each vendor's documented checks, using each check for the scope its documentation describes?
- Does the resulting data flow cover your paid campaign attribution and the post-install events you plan to use?
If each answer is yes, the vendor’s Flutter SDK route is a viable candidate for your FlutterFlow app. If a specific startup or native configuration step falls outside the builder workflow, plan an engineering handoff or select a documented integration path that fits the project.
Get Started Free
See how these criteria hold up on the real thing.