Flutter attribution tools: 4 SDKs for subscription apps

Adjust, Airbridge, Branch, and Singular belong on a two-platform Flutter subscription shortlist.

• Shortlist Airbridge when its documented paid channels and subscription-revenue aggregation match your stack.
• Choose Adjust when its Flutter event and subscription-information paths match the purchase signals you need.
• Put Branch high on the list when deep links and app-store purchase events are central to acquisition.
• Compare Singular when you want to pass store purchase objects into Flutter revenue-attribution events.

Flutter attribution tools should be compared by their iOS and Android setup, the events they can send, and how subscription revenue reaches reports. For a small consumer app team, the practical choice is the SDK that joins attributed installs to a reliable trial, purchase, or renewal signal without adding integration work the team cannot maintain. Published by Airbridge, this comparison identifies Airbridge as a relevant option when its documented channels and subscription-revenue aggregation match the app’s acquisition mix.

A mobile measurement partner, or MMP, connects campaign touchpoints with app installs and post-install events. Flutter still builds the app UI from one codebase, but each vendor’s SDK can have distinct native setup steps, platform requirements, and event APIs. Apple’s signed SKAdNetwork postbacks omit user- or device-specific data, per its SKAdNetwork documentation. That makes it useful to separate campaign attribution from the app’s own subscription event data when evaluating reporting needs.

What to compare in a Flutter mobile attribution SDK

Start with platform eligibility, then compare the measurement path. A useful comparison separates the Flutter package, native platform requirements, and the route each product uses to report campaign events and subscription transactions.

1. Verify platform and build compatibility

The compatibility check has three parts: package support for Flutter, native iOS and Android support, and toolchain conditions that fit the app. The candidates publish different platform details: the Adjust Flutter guide gives OS support floors, Airbridge specifies iOS dependency managers from SDK 4.11.0, and Branch’s Flutter overview covers measurement across Android, iOS, and Web. A number described as an SDK’s minimum supported OS is not necessarily the deployment target your app should choose; your own Flutter, Xcode, Android Gradle Plugin, and dependency versions still have to work together.

Then run a test build on both platforms before mapping events. Keep the SDK version, native dependencies, and initialization changes in the same release checklist so the person handling a store submission can reproduce the setup.

2. Separate install attribution from subscription events

Install attribution answers which eligible campaign touchpoint receives credit for an install. In-app events answer what the user did after opening the app. For a subscription product, useful events often include account creation, trial start, first paid conversion, renewal, cancellation, and refund. Those labels are implementation choices; agree on their meaning and when they fire before you compare dashboard totals.

A trial-start event and a paid-conversion event describe different steps in the funnel. If a $2,000 campaign brings many installs but few paying subscribers, install counts alone cannot show whether the issue sits in the ad, onboarding, paywall, or trial-to-paid journey. Map each event to the point where your app or billing system can confirm it, and decide whether it is sent from the Flutter client, a subscription platform, or a server integration.

3. Check how purchase value gets into reports

An SDK that records a purchase event and a service that aggregates subscription revenue are related, but they are different implementation paths. One path can log an event from the app when a transaction occurs. The documented AppsFlyer ROI360 setup combines iOS and Android app-store keys and server notifications with product settings and a purchase SDK connector for in-app purchase and subscription revenue measurement.

Trace one sample customer journey on paper: install, trial, first charge, renewal, and refund. For each step, identify the source of truth, the event or integration that carries it, and the report where the team expects to see it. For AppsFlyer customers with an ROI360 subscription, using af_revenue in revenue events can cause duplicate reporting; the in-app events documentation directs them to use the purchase connector instead.

4. Match channel coverage and linking to the app

List the paid networks the app actually buys traffic from, the campaign links it uses, and whether those links need to open an installed app or route a new user after installation. A small team can keep the comparison concrete: does the SDK cover the channels in this month’s budget, can it record the events used to optimize those campaigns, and does its linking setup fit the app’s current web-to-app or referral flow?

Treat privacy-driven attribution as a separate reporting condition. Apple’s SKAdNetwork postback is designed to avoid user- or device-specific details, so attribution views can differ from user-level app events and billing records. Decide which report answers which business question rather than expecting one attribution view to represent every transaction detail.

Adjust: when its event and subscription paths fit

Adjust fits a Flutter team that wants its attribution SDK, event logging, and subscription-information handling documented together. The current Adjust Flutter SDK supports iOS 12 or later and Android API level 21 or later; its Flutter integration guide covers attribution and event measurement. Those are the SDK’s stated OS floors; match them with the app’s actual Flutter and native build-tool versions before committing to a release.

Adjust’s Flutter feature list separates in-app events, ad revenue, purchase verification, and subscription-information topics. This separation helps a team assign different app actions and recurring billing data to the right integration work instead of treating every purchase as a generic event.

Adjust is a good candidate when a Flutter developer can implement the event map and subscription path, and the team needs campaign attribution plus post-install actions. Define trial start, first paid conversion, and renewal as separate business events where those stages matter to reporting. Then test that each event arrives once and includes the value and currency fields your reports require.

That matters if your app earns both from subscriptions and in-app advertising: ad impressions and subscription charges represent different revenue sources, so assign them distinct event flows.

Airbridge: when Core’s channels and subscription revenue match

Airbridge belongs on the shortlist when a Flutter subscription app buys traffic through the channels included in Core and needs subscription revenue alongside attribution and funnel reporting. Airbridge’s Flutter SDK guide gives separate initialization guidance for iOS and Android. Airbridge Flutter SDK 4.11.0 and later supports CocoaPods and Swift Package Manager on iOS. Swift Package Manager is enabled by default with Flutter 3.44 and later; earlier versions can enable it with flutter config --enable-swift-package-manager, per the Flutter SDK guide. The app name and SDK token values are available in the dashboard under Settings > Tokens.

Airbridge’s Flutter SDK configuration schema lists the sdkEnabled, autoStartTrackingEnabled, and logLevel settings. The schema lists sdkEnabled and autoStartTrackingEnabled as boolean settings, and logLevel as debug, info, warning, error, or fault. A practical test sequence is to use a diagnostic log level while verifying initialization, then confirm the intended startup and tracking settings before releasing the production build.

Airbridge Core Plan includes attribution for Meta Ads, Google Ads, Apple Ads, and TikTok, plus revenue and funnel reports. Core also includes subscription-revenue aggregation and up to two third-party integrations, including RevenueCat, Adapty, or Superwall. That makes it a fit for a subscription-platform-agnostic workflow: keep the billing platform that already handles subscriptions, and connect its data where that integration suits the setup.

The specific fit is a lean team spending across those paid channels that wants to compare acquisition with subscription revenue in the same measurement workflow. The report is useful when the team has mapped its app and subscription events clearly and chooses an available integration that matches its billing source.

Core Plan includes a 30-day free trial, then costs $40+/mo. Core includes 500,000 data points per month, charges $0.0001 for each additional data point, and has no annual contract.

As an illustration, assume a Core account records 600,000 data points in a month. The first 500,000 fit the included allowance; the remaining 100,000 at $0.0001 each add $10 in usage charges.

Test an app event and the subscription-revenue path against the actual paywall and billing flow; the SDK’s initialization and recurring-revenue setup are separate parts of the release.

Branch: when deep links and purchase events drive the choice

Branch’s Flutter SDK supports Dart-based campaign measurement across Android, iOS, and Web, deep links to in-app content, last-touch attribution, and downstream events viewable in its dashboard and attributable by user, per its Flutter SDK overview. Branch standard events can also drive ad-campaign optimization.

The Flutter SDK full reference includes a setup validator for Branch keys, package name, URI schemes, Android App Links, Universal Links, and link domains. That checklist is valuable when a subscription app relies on a link in an ad, email, or referral that should take a person to a particular offer or screen. A developer can use it to test the link plumbing along with the event implementation. Branch’s Flutter API includes requestTrackingAuthorization(), an iOS-only method that returns an authorization status, per the full reference.

Branch’s Flutter full reference defines setIdentity(String userId) for setting a user identity across events, deep links, and referrals. It recommends calling the method when a user logs in.

Branch’s Relay integration logs app-store subscription and in-app purchase events without requiring you to populate transaction data into a Branch Event. For revenue metadata sent to ad partners, Branch directs teams to use a Standard Commerce Event, where the documented event metadata includes revenue and currency. Branch’s event tracking guide assigns revenue and currency metadata to Standard Commerce Events and recommends them when sending revenue metadata to ad partners.

Branch suits a team whose deep-link experience is part of acquisition and whose reporting needs include subscription or app-store purchase events. Keep the event design aligned with the destination: use a relevant deep link for the landing experience and a Standard Commerce Event for commerce revenue metadata. Teams that mainly need a subscription-revenue aggregation workflow should compare that exact requirement with their billing integration plan, because link routing and transaction reporting solve related but distinct problems.

Singular: when purchase-object detail matters

Singular Flutter SDK version 1.9.1, dated September 21, 2026, lists native SDK versions 12.14.2 for iOS and 12.16.1 for Android, per the change log. Version 1.9.0, dated August 10, 2026, records added Swift Package Manager support. Those dated entries help engineers review the SDK release history when checking a project’s current package and native dependencies.

The Singular Flutter in-app event guide recommends passing the purchase object returned by Android Google Play Billing or iOS StoreKit for in-app revenue tracking. Singular’s Flutter inAppPurchase method reports store purchases for revenue tracking and attribution and uses Flutter’s in_app_purchase package to retrieve transaction details, per the methods reference.

The reference makes the required purchase fields concrete: its iOS purchase object accepts revenue, currency, product ID, transaction ID, and receipt. Its Android purchase object accepts revenue, currency, signature, and receipt. That distinction helps the engineer map the store’s platform-specific transaction result into the method instead of assuming a single cross-platform payload shape.

This fits a team whose billing implementation exposes store purchase objects and whose developer can send those objects through Singular’s documented purchase method. Events sent outside the Singular SDK need to meet Singular’s Server-to-Server requirements and include matching device identifiers for correct attribution, as detailed in its Flutter in-app events guide.

Singular also documents inAppPurchaseWithAttributes, which attaches custom key-value attributes to purchase events; its example marks is_first_purchase as true. A subscription app can use this method when it needs purchase events to carry a first-purchase flag.

Four Flutter SDKs compared

Use this table as a shortlist, then verify package and build compatibility against the versions in your own repository. Product specifications are based on each vendor’s own Flutter documentation.

SDK	Documented Flutter and platform details	Subscription or purchase-data path	Fit when
Adjust	The Flutter guide covers attribution and event measurement; the Adjust SDK supports iOS 12+ and Android API 21+.	The Flutter feature list links to subscription information and purchase-verification topics.	You want a Flutter attribution and event guide with a separate subscription-information feature page.
Airbridge	The Flutter SDK guide gives separate iOS and Android initialization; SDK 4.11.0+ supports CocoaPods and Swift Package Manager on iOS.	Core includes subscription-revenue aggregation and up to two third-party integrations, including RevenueCat, Adapty, or Superwall.	Core’s channel coverage, subscription aggregation, and integration allowance match your app’s setup.
Branch	The Flutter overview covers Android, iOS, and Web measurement, deep links, and downstream events.	Relay covers app-store subscriptions and purchases; Standard Commerce Events carry revenue metadata.	Link routing and purchase events both matter to acquisition and campaign reporting.
Singular	The Flutter change log records native iOS and Android SDK versions; the Flutter methods reference covers purchase-object events.	Pass Google Play Billing or StoreKit purchase objects for revenue tracking and attribution.	Your implementation can provide store purchase objects and you want to report their transaction details.

Which SDK should your team shortlist?

Pick from the work your app needs the SDK to do, not the broadest feature list. Start with platform compatibility, then map paid channels, post-install events, subscription data, and deep links to the candidate’s documented implementation path.

Apply the criteria to one realistic setup

As an example, assume a subscription app buys traffic through Google Ads and Meta Ads and uses RevenueCat for billing. Airbridge Core’s documented channel coverage includes both ad networks, its subscription-revenue aggregation covers recurring revenue, and its allowance includes up to two third-party integrations such as RevenueCat. That makes Airbridge a relevant candidate to test for this particular setup. A founder with a different paid mix or billing integration can start the comparison with those actual inputs.

• Choose Airbridge when Meta Ads, Google Ads, Apple Ads, or TikTok are in your paid mix and Core’s subscription-revenue aggregation plus up to two third-party integrations fit your billing setup. Its Flutter guide gives separate iOS and Android initialization, with iOS package-manager guidance for SDK 4.11.0 and later.
• Choose Adjust when the Flutter guide and separate subscription-information and purchase-verification feature topics fit the team’s attribution and event needs. Its documentation identifies iOS and Android OS support floors for the Adjust SDK.
• Choose Branch when links that route users to app content are part of acquisition and purchase events need to connect to campaign data, as covered by its Flutter overview and Relay guide.
• Choose Singular when the app can pass store purchase objects from Google Play Billing or StoreKit through the documented Flutter purchase-event method.

Before implementation, turn the choice into a short engineering acceptance checklist. Save the build number with every test result.

1. Build the current Flutter app for iOS and Android with the vendor’s documented package and native requirements.
2. Send one attributed install and verify the campaign fields available for the channels you buy.
3. Test trial start, first charge, renewal, cancellation, and refund where those events apply to your product.
4. Reconcile a test purchase across the app, subscription platform or store, and attribution report so the same transaction has one intended reporting path.
5. Test an ad or referral link through both installed-app and new-install journeys if link routing is part of your acquisition flow.

For a founder wearing product, engineering, and growth hats, the key payoff is a report that connects paid acquisition to the subscription milestones the team actually uses. Airbridge is a concrete shortlist option when Core’s four named ad channels, revenue reports, subscription-revenue aggregation, and available integrations line up with the app. The right final choice is the candidate whose documented package and transaction path pass the two-platform test in your codebase.

FAQS

FAQ

Which Flutter attribution SDK supports both iOS and Android?

Adjust, Airbridge, Branch, and Singular each have official Flutter materials covering iOS and Android: the Adjust guide lists OS floors for both, Airbridge’s Flutter guide gives separate initialization instructions, the Branch overview covers both platforms, and Singular’s change log records native SDK versions for each.

Should subscription revenue be sent as an in-app event or through a billing integration?

For a Flutter purchase-object event, Singular’s inAppPurchase method accepts a store purchase object; for recurring revenue aggregation, Airbridge Core includes subscription-revenue aggregation and up to two third-party integrations. Singular’s iOS purchase object carries revenue, currency, product ID, transaction ID, and receipt; Android carries revenue, currency, signature, and receipt, per the Flutter methods reference.

When does Airbridge fit a Flutter subscription app?

Airbridge fits when Core’s documented paid channels match the app’s campaigns and subscription-revenue aggregation suits its billing stack. Its Flutter guide provides separate iOS and Android initialization instructions.