Skip to main content

Core Concepts

This page covers the foundational architecture and design decisions behind AppDNA. Understanding these concepts will help you integrate the SDK effectively and get the most out of the platform.

SDK Architecture

The AppDNA SDK follows a singleton pattern with module namespaces. After calling configure(), the SDK is accessible through a single global instance. Each feature area is organized as a namespace on that instance:
NamespacePurpose
pushPush notification registration and handling
billingSubscription status, product fetching, purchases
onboardingServer-driven onboarding flow presentation
paywallServer-driven paywall rendering and events
remoteConfigKey-value remote configuration
featuresFeature flags and entitlements
experimentsA/B experiment assignment and exposure tracking
surveysIn-app survey presentation and response collection
inAppMessagesTriggered in-app messaging
deepLinksDeep link routing and deferred deep links
Each namespace operates independently but shares the core event pipeline, identity state, and configuration layer.
// Access module namespaces
AppDNA.push.requestPermission()
AppDNA.billing.getProducts()
AppDNA.experiments.getVariant("onboarding-v2")
AppDNA.remoteConfig.getString("welcome_message")

Offline-First Design

AppDNA SDKs are built for unreliable networks. The SDK never assumes connectivity is available and degrades gracefully when it is not.

Configuration Priority

The SDK resolves configuration using a three-tier fallback:
Remote (Firestore real-time sync)

        ▼ unavailable?
Cached (persisted on device from last successful fetch)

        ▼ unavailable?
Bundled (appdna-config.json embedded in the app binary)
SourceDescriptionLatency
RemoteReal-time sync from Firestore. Always preferred when available.~100ms
CachedLast known good config, persisted in local storage. Expires after the configured TTL.~1ms
BundledStatic JSON file shipped with the app binary. Used on first launch before any network call completes.~1ms
The default config TTL is 5 minutes. After the TTL expires, the SDK attempts a remote fetch. If the fetch fails, the cached config continues to be used until a successful refresh.

Event Queue

Events are never dropped. When the SDK records an event:
  1. The event is written to a persistent on-disk queue (Keychain on iOS, SharedPreferences on Android).
  2. The queue is auto-flushed every 30 seconds or when it reaches 20 events, whichever comes first.
  3. If the flush fails (no connectivity, server error), events remain in the queue and are retried on the next flush cycle.
  4. Events are only removed from the queue after a successful server acknowledgment.
Because events are persisted to disk, they survive app restarts and even device reboots. No event is ever lost due to a crash or force-quit.

Config Bundle

A config bundle is a versioned JSON snapshot generated server-side. It contains all active configuration for your app: onboarding flows, paywalls, in-app messages, experiments, feature flags, and remote config values.

How It Works

  1. The dashboard generates a new bundle version whenever you publish a change.
  2. The SDK polls GET /api/v1/sdk/config-bundle/version to check for updates.
  3. If a newer version exists, the SDK downloads the full bundle and caches it locally.
  4. The bundle can also be embedded in your app binary for zero-latency first launch.

Embedding a Bundle

For the best first-launch experience, embed the latest config bundle in your app:
Add appdna-config.json to your Xcode project as a bundle resource.
The embedded bundle is a fallback only. The SDK will always prefer a fresher remote or cached config when available. Embedding a bundle ensures your app works correctly on first launch before any network request completes.

Experiments

AppDNA experiments use deterministic bucketing to assign users to variants. No server call is required — the assignment is computed locally on the device.

How Bucketing Works

The SDK computes a bucket using:
bucket = MurmurHash3(userId + experimentId + salt) % 100
InputSource
userIdThe identified user ID (or anonymous ID if not identified)
experimentIdUnique identifier for the experiment
saltRandom string generated when the experiment is created
The resulting bucket (0–99) maps to a variant based on the traffic allocation configured in the dashboard.

Key Properties

  • Deterministic: The same user always gets the same variant for the same experiment. No randomness, no server dependency.
  • Cross-platform consistent: A user who opens your app on iOS and Android will see the same variant because the hash function and inputs are identical.
  • Session-stable: The variant does not change between sessions or app restarts.
  • Exposure tracking: The SDK records an exposure event once per session when getVariant() is called. This prevents inflated exposure counts from multiple reads.
let variant = AppDNA.experiments.getVariant("onboarding-v2")

switch variant {
case "control":
    showClassicOnboarding()
case "streamlined":
    showStreamlinedOnboarding()
default:
    showClassicOnboarding()
}

Delegates and Callbacks

All SDK modules use a delegate/callback pattern to communicate events back to your application. This keeps the SDK non-blocking and lets you respond to events in your own code.
Modules expose protocols with default empty implementations. Conform to only the methods you need:
class MyPaywallHandler: PaywallDelegate {
    func paywallDidPresent(paywallId: String) {
        // Track in your own analytics
    }

    func paywallDidDismiss(paywallId: String, action: PaywallAction) {
        // Handle purchase or dismissal
    }
}

AppDNA.paywall.delegate = MyPaywallHandler()

Environments

AppDNA supports two environments to separate development and production data:
EnvironmentAPI Base URLKey Prefix
Productionhttps://api.appdna.aiadn_live_
Sandboxhttps://sandbox-api.appdna.aiadn_test_
  • Events, experiments, and configuration are completely isolated between environments.
  • Use sandbox during development and testing. Switch to production for App Store / Play Store builds.
  • The SDK determines the environment from the API key prefix — there is no need to set it separately if the key is correct.
Never ship an app to production with a sandbox API key. Sandbox data is periodically purged and is not included in production analytics.

Webhooks

AppDNA can send real-time HTTP callbacks to your server whenever key events occur. Webhooks let you sync data to your backend, trigger workflows, or feed events into third-party tools.

Event Types

AppDNA supports 16 webhook event types spanning the full lifecycle:
CategoryEvents
Useruser.created, user.identified, user.trait_updated
Subscriptionsubscription.started, subscription.renewed, subscription.cancelled, subscription.expired
Experimentexperiment.exposure, experiment.conversion
Paywallpaywall.presented, paywall.dismissed, paywall.purchase_started, paywall.purchase_completed
Pushpush.delivered, push.opened
Onboardingonboarding.completed

Security

Every webhook payload is signed with HMAC-SHA256. Your server should verify the signature before processing:
X-AppDNA-Signature: sha256=<hex-encoded HMAC of request body>
The signing secret is generated when you create a webhook endpoint in the dashboard and is only displayed once.

Reliability

  • 5 retry attempts with exponential backoff (1s, 5s, 30s, 2min, 10min).
  • Your endpoint must respond with a 2xx status within 15 seconds or the attempt is considered failed.
  • After 50 consecutive failures, the webhook endpoint is automatically disabled and you receive an email notification.
  • You can view delivery logs and manually retry failed deliveries in the dashboard.
To test webhooks locally during development, use a tunneling tool like ngrok and point your webhook endpoint to the tunnel URL.

Identity

AppDNA manages user identity through a combination of anonymous and authenticated identifiers.

Anonymous ID

On first launch, the SDK generates a random anonymous ID and persists it securely:
PlatformStorage
iOSKeychain
AndroidSharedPreferences (encrypted)
FlutterPlatform-specific (Keychain on iOS, SharedPreferences on Android)
React NativePlatform-specific (Keychain on iOS, SharedPreferences on Android)
The anonymous ID survives app restarts and reinstalls (on iOS, as long as the Keychain entry is preserved).

Linking Identity

When you call identify(userId:), the SDK links the anonymous ID to the provided user ID. All past events tracked under the anonymous ID are retroactively associated with the user.
Anonymous ID (auto-generated)  ──identify()──▶  User ID (your system)

Resetting Identity

Calling reset() clears the user ID but keeps the anonymous ID. This is appropriate for sign-out flows where another user may sign in on the same device.
// User signs out
AppDNA.reset()

// New user signs in
AppDNA.identify(userId: "user-456", traits: ["plan": "free"])
The anonymous ID is never deleted by reset(). This ensures continuity for device-level analytics even across multiple user sessions.