Quickstart — iOS

Install the Amply iOS SDK, initialize it with your API keys, and send your first event. You'll end with a tracked event visible in the Amply dashboard.

This tutorial takes about ten minutes. It uses Swift and UIKit's AppDelegate. The same pattern works in SwiftUI — call the same initializer from the App struct's init().

Prerequisites

• An iOS 14.0+ deployment target — see Installation for the full requirements matrix

• An Amply dashboard account with appId, apiKeyPublic, and apiKeySecret (Settings → API Keys)

• CocoaPods or Swift Package Manager set up in your project

You'll end with

• The SDK initialized on app launch

• One custom event tracked from your code

• That event showing up in the Amply dashboard's event log

1. Add the SDK

Follow Installation → iOS to add the AmplySDK pod or Swift package. Come back here once import AmplySDK resolves cleanly.

2. Initialize on launch

Initialize Amply in AppDelegate.application(_:didFinishLaunchingWithOptions:). Constructing Amply(config:) starts the SDK — there is no separate initialize() call.

AppDelegate.swift

import UIKit
import AmplySDK

@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    static var amply: Amply?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        let config = AmplyConfig(
            appId: "com.acme.app",
            apiKeyPublic: "YOUR_PUBLIC_KEY",
            apiKeySecret: "YOUR_SECRET_KEY",
            defaultConfig: nil
        )

        AppDelegate.amply = Amply(config: config)
        AppDelegate.amply?.setLogLevel(level: "debug")

        return true
    }
}

AmplyConfig takes three required fields — appId, apiKeyPublic, apiKeySecret — plus an optional defaultConfig used for preloaded campaign content. Leave it nil for now.

setLogLevel(level: "debug") prints SDK activity to the Xcode console while you're wiring things up. Remove or switch to "warn" before shipping.

SwiftUI? Put the same AmplyConfig + Amply(config:) in your App struct's init() and store the instance on an @StateObject or singleton of your choice.

3. Track your first event

From anywhere in your app — a button handler, a view controller's viewDidLoad, a coordinator — call track:

AppDelegate.amply?.track(event: "Signup", properties: ["plan": "pro"])

track(event:properties:) takes an event name and an optional [String: Any] map of properties. Event names should be short and consistent (e.g., Signup, Purchase, TrialStarted). Properties go on the event for segmentation in the dashboard.

4. Manage the session lifecycle

iOS doesn't emit the same lifecycle callbacks as Android, so Amply exposes three session methods you call yourself. Wire them to the standard UIApplicationDelegate hooks so sessions bookend real user activity.

AppDelegate.swift

func applicationDidBecomeActive(_ application: UIApplication) {
    AppDelegate.amply?.resumeSession()
}

func applicationDidEnterBackground(_ application: UIApplication) {
    AppDelegate.amply?.pauseSession()
}

func applicationWillTerminate(_ application: UIApplication) {
    AppDelegate.amply?.stopSession()
}

• resumeSession() — call when the app becomes active again

• pauseSession() — call when the app enters background

• stopSession() — call on terminate, or when you want to force-close the current session

Skipping these won't crash the SDK, but session duration and session-scoped custom properties will be inaccurate.

Android auto-manages sessions via the process lifecycle. iOS does not — this step is required on iOS.

5. Verify in the dashboard

1. Run the app on a simulator or device.

2. Trigger the code path that calls track(event: "Signup", ...).

3. Open the Amply dashboard and go to Events (or the real-time event log for your app).

4. You should see an entry for signup with the plan: pro property within a few seconds.

If the event doesn't appear, check:

• The Xcode console (log level "debug") for SDK errors

• That appId, apiKeyPublic, and apiKeySecret match your dashboard app exactly

• That the device has network connectivity — events are queued and retried, but the first event needs a live connection to prove the pipeline works

What's next

• iOS integration — deep link handling, custom properties, user identification

• Concepts → Sessions and events — how events, properties, and datasets fit together

• Recipes — entry-based onboarding routing — ready-made pattern for signup and onboarding flows

Related

• Installation — pod / SPM setup details

• Android Quickstart — same flow on Android