11 · Mobile SDK — AA Academy

1 · What the Mobile SDK is

The AEP Mobile SDK (sometimes called Mobile Core + extensions) is the native-app analogue of the Web SDK. It packages identity management, network transport, batching, offline queueing, and consent handling into a small framework you embed in your iOS or Android app.

Like the Web SDK, it sends XDM events to the Adobe Experience Platform Edge Network. Like the Web SDK, your datastream configuration decides where those events fan out: Analytics, Target, AAM, CDP. From a data-modelling standpoint there is no difference — the same XDM schema serves both web and mobile.

From an implementation standpoint there are significant differences: SwiftUI vs Jetpack Compose vs UIKit vs XML lifecycles, native crash domains, app-store privacy disclosures, App Tracking Transparency on iOS, the absence of cookies. The SDK abstracts most of it.

2 · Installation

You install the SDK as a package via Swift Package Manager (iOS), CocoaPods (iOS legacy), or Gradle (Android). The packages you'll commonly pull in:

Package	Role
`AEPCore`	Foundation — event hub, identity, lifecycle
`AEPEdge`	Sends events to the Edge Network
`AEPEdgeIdentity`	Manages ECID for Edge calls
`AEPEdgeConsent`	Tracks user consent state
`AEPLifecycle`	App-open / app-close metrics
`AEPAssurance`	Debug bridge to Adobe Assurance

iOS — Swift package, in your app delegate:

// Swift
import AEPCore
import AEPEdge
import AEPEdgeIdentity
import AEPLifecycle
import AEPAssurance

func application(_ application: UIApplication,
                 didFinishLaunchingWithOptions launchOptions: ...) -> Bool {
  MobileCore.registerExtensions([
    Edge.self,
    Identity.self,
    Consent.self,
    Lifecycle.self,
    Assurance.self
  ]) {
    MobileCore.configureWith(appId: "YOUR_AEP_TAGS_PROPERTY_APP_ID")
    MobileCore.lifecycleStart(additionalContextData: nil)
  }
  return true
}

Android (Kotlin):

// Kotlin
class MyApp : Application() {
  override fun onCreate() {
    super.onCreate()
    MobileCore.setApplication(this)
    MobileCore.configureWithAppID("YOUR_AEP_TAGS_PROPERTY_APP_ID")
    MobileCore.registerExtensions(
      listOf(Edge.EXTENSION, Identity.EXTENSION,
             Consent.EXTENSION, Lifecycle.EXTENSION,
             Assurance.EXTENSION)
    ) {
      MobileCore.lifecycleStart(null)
    }
  }
}

The appId identifies a Tags (Launch) mobile property you set up in the Adobe Experience Platform Data Collection UI. Same Launch UI as web; different property type. Rules, data elements, and extensions all exist on the mobile side.

3 · Tracking calls

Two layers. The new, recommended layer is direct Edge events with XDM payloads. The legacy layer is "track" methods that the SDK auto-maps to XDM behind the scenes.

3.1 — Modern Edge events

// Swift — log a screen view
let event = ExperienceEvent(xdm: [
  "eventType": "web.webpagedetails.pageViews",
  "web": [
    "webPageDetails": [
      "name": "Product Detail · Astro-3000",
      "pageViews": ["value": 1]
    ]
  ],
  "_yoursandbox": [
    "productSku": "ASTRO-3000",
    "category": "telescopes"
  ]
])
Edge.sendEvent(experienceEvent: event)

Identical pattern in Kotlin. The XDM object is the same shape as on web — the same schema can back both implementations, and the datastream maps the same field names to the same eVars.

3.2 — Legacy track APIs

If you're working with an older codebase or just prefer concise syntax, the legacy methods still work — they emit Edge events under the hood:

// Swift
MobileCore.track(state: "PDP · Astro-3000",
                 data: ["productSku": "ASTRO-3000",
                        "category": "telescopes"])

MobileCore.track(action: "Add to Cart",
                 data: ["productSku": "ASTRO-3000"])

trackState ≈ page view. trackAction ≈ link click. The data dictionary is mapped to XDM via your Tags mobile property configuration. Behind the scenes, this is now built on the Edge stack.

4 · Lifecycle metrics

The AEPLifecycle extension automatically tracks app-state events that would be tedious to instrument by hand:

App installs (first launch ever for that device)
App launches (each cold start)
App upgrades (new version detected)
Crashes (detected on the launch following an unclean shutdown)
Sessions (a launch after > 5 minutes of background)
Engaged users (DAU / MAU / 90-day)
Device metrics (OS version, model, screen size, locale, carrier)

Call MobileCore.lifecycleStart() on app foreground and lifecyclePause() on background — the SDK derives everything else.

These metrics arrive as their own XDM events and populate the standard mobile reports in Workspace (Launches, Installs, Crashes, etc.) without any further work.

5 · Identity & consent

On mobile there is no cookie. Identity is carried by:

An Experience Cloud ID generated by the SDK and persisted in the app's sandboxed storage. Survives across app sessions, dies when the app is uninstalled.
The device's vendor identifier (IDFV on iOS, ANDROID_ID on Android) as a fallback signal.
Optionally, the IDFA / GAID — the advertising identifier — but only if the user grants permission (App Tracking Transparency on iOS 14+).
Your own customer ID, set via Identity.updateIdentities() after login.

Consent is handled by AEPEdgeConsent. Set state on app launch from the user's choice; the SDK includes it in every Edge call's header. The edge enforces consent server-side — events from a user who hasn't consented are routed only to permitted destinations or dropped entirely.

// Swift — user opted in
let consents: [String: Any] = [
  "consents": [
    "collect": ["val": "y"]
  ]
]
Consent.update(with: consents)

6 · Adobe Assurance — the mobile debugger

Mobile debugging is harder than web — no DevTools, no network panel you can casually open. Adobe ships Assurance, which solves this with a paired-device pattern.

How it works:

Open https://experience.adobe.com/assurance in your laptop browser. Create a new session; you get a deep link / QR code.
Open the deep link on a development device running your app. The SDK's Assurance extension catches it.
The app now streams every SDK event, every Edge call, every state change to the Assurance session in real time.
You see the equivalent of "network panel for mobile" in your laptop browser, alongside event diff views, XDM validation results, and rule traces.

Pair Assurance with the AEP Debugger browser extension and you have a single console showing both web and mobile traffic from the same user across both surfaces. This is the only practical way to validate a cross-channel implementation.

7 · Cross-device stitching

If a user opens your iOS app and later browses your website on a laptop, how do those two sessions get connected?

The mechanism is the known customer ID — typically a hashed email or your CRM ID — set on both surfaces after login. Both web and mobile use the Identity Map XDM structure:

// Both surfaces emit this once the user has signed in
"identityMap": {
  "Email_SHA256": [
    { "id": "9a3f5...c2", "authenticatedState": "authenticated" }
  ],
  "CRM_ID": [
    { "id": "USR-440189", "authenticatedState": "authenticated" }
  ]
}

The Adobe Experience Platform Identity Service maintains a graph that says "ECID A on web, ECID B on mobile, and CRM_ID USR-440189 all belong to the same person." Customer Journey Analytics queries this graph at read time to deliver cross-device reports.

Important: this works only when users sign in. Anonymous mobile and anonymous web are necessarily separate. There is no magic — the customer ID is the bridge.