Skip to main content
Supported on: iOS SDK 1.0.61+ · Android SDK 1.0.33+ · Flutter SDK 1.0.3+
This guide walks you through configuring the AppDNA SDK, identifying users, and tracking your first event in a Flutter application.

1. Configure the SDK

Initialize AppDNA as early as possible in your app lifecycle, typically in your main() function before runApp():
If you don’t have your own Firebase: Keep Firebase.initializeApp() as shown above.If you already use Firebase in your Flutter app: Remove the Firebase.initializeApp() call and just call AppDNA.configure(...). The SDK automatically initializes its own named Firebase instance from GoogleService-Info-AppDNA.plist (iOS) and google-services-appdna.json (Android). Your existing Firebase setup is not affected.
Call AppDNA.configure(...) exactly once before using any other SDK methods. Calling it multiple times will result in undefined behavior.

Configuration Options

The AppDNAOptions class lets you customize SDK behavior:

Environment

The AppDNAEnvironment enum controls which backend environment the SDK targets:

Log Level

The AppDNALogLevel enum controls console log verbosity:
Use AppDNALogLevel.debug during development to see all SDK activity. Switch to AppDNALogLevel.warning or AppDNALogLevel.none for production builds.

Billing Provider

The AppDNABillingProvider class specifies which billing system to use. The value-less providers are static consts; adapty is a factory that carries your Adapty public SDK key:
The setting applies on both iOS and Android (on Android storeKit2 means Google Play Billing). Omitted = storeKit2. Choose revenueCat when RevenueCat is your purchase SDK: AppDNA then never finishes or acknowledges a transaction, an SDK paywall tap calls onPaywallPurchaseFailed with errorType: 'providerNotAvailable' (start the RevenueCat purchase from that callback), and purchases reach AppDNA through the RevenueCat webhook. See Billing → Who owns the store transaction.

2. Wait for Ready State

Use onReady to know when the SDK is ready — the bootstrap has succeeded or failed:
onReady() accepts a callback that runs once the SDK is ready (at once, if it already is). onReady does not wait for the remote configuration. When it fires, the SDK serves the cached and bundled config, and the remote fetch may still be running (after a failed bootstrap it starts when a retry succeeds). Use remoteConfig.onChanged to pick up the fetched values.

3. Identify Users

Once a user signs in, call identify to associate events with their user ID:
Traits are merged with any previously set traits. You do not need to pass all traits on every call — only the ones that have changed.

4. Track Events

Track user actions with track:
Events are batched and flushed automatically: every flushInterval seconds, when the app goes to the background or returns to the foreground, and when the queue reaches a batch size set by the network (100 events on Wi-Fi or a wired connection, metered or not; 20 on a cellular connection the system marks as expensive (iOS) or metered (Android), which is every cellular connection on iOS and most cellular plans on Android; 50 on any other cellular connection). The batchSize option caps it: with a cap, the queue is flushed at the smaller of the two, and no upload sends more.

5. Flush Events Manually

Force an immediate flush of all queued events:
This is useful before the app enters the background or when you need to ensure events are sent immediately. Control whether the SDK collects and sends analytics data:
When analytics is set to false, events are silently dropped and not queued. No data is sent to AppDNA servers until consent is granted.

7. Change Log Level at Runtime

Adjust the log level without reconfiguring the SDK:
Valid levels: "none", "error", "warning", "info", "debug".

8. Remote Config and Feature Flags

Retrieve server-side configuration values:
Check whether a feature flag is enabled:

9. Experiments

Get the variant assigned to a user for an experiment:
Check if the user is in a specific variant:
Inspect all experiment exposures collected during the current session:

10. Session Data

Store cross-module session data that can be used in template interpolation across onboarding flows, paywalls, and in-app messages:
Session data values are accessible in Console-configured content using template syntax: {{session.selected_plan}}. See the Rich Media guide for the full template namespace ({{user.*}}, {{session.*}}, {{device.*}}, {{remote_config.*}}).

11. Entitlements

Check whether the user has any active subscription (StoreKit, Play Billing, RevenueCat, or web entitlement):
Subscribe to live entitlement updates so your UI reflects renewals, cancellations, and restored purchases without polling:
See the Billing guide for the full purchase and restore flow.

12. Web Entitlement

Retrieve the current web entitlement (subscriptions granted outside the app store, e.g. via Stripe):
Listen for web entitlement changes in real time:
Check for a deferred deep link that brought the user to your app on first launch:

14. Get SDK Version

Print the underlying native SDK version (useful for support tickets):

15. Reset on Logout

When a user signs out, call reset to clear the user identity and flush any remaining events:
This clears the identified user, generates a new anonymous ID, and flushes queued events.

16. Shutdown

When the app is terminating, shut down the SDK to ensure all events are flushed and resources are released:
On Android this releases native resources. On iOS this is a no-op because the SDK shuts down automatically when the process exits.
You now have the SDK configured with user identification, event tracking, remote config, experiments, entitlements, and deep links working. Continue to the module-specific guides for Push Notifications, Billing, Onboarding, and Paywalls.