iOS

This library uses an internal queue to make calls fast and non-blocking. It also batches requests and flushes asynchronously, making it perfect to use in any part of your mobile app.

PostHog supports the following Apple platforms:

• iOS: Version 13 or later
• macOS: Catalina (10.15) or later
• tvOS: Version 13 or later
• watchOS: Version 6 or later

Installation

PostHog is available through CocoaPods or you can add it as a Swift Package Manager based dependency.

CocoaPods

pod "PostHog", "~> 3.0.0"

Swift Package Manager

Add PostHog as a dependency in your Xcode project "Package Dependencies" and select the project target for your app, as appropriate.

For a Swift Package Manager based project, add PostHog as a dependency in your "Package.swift" file's Package dependencies section:

dependencies: [
  .package(url: "https://github.com/PostHog/posthog-ios.git", from: "3.0.0")
],

and then as a dependency for the Package target utilizing PostHog:

.target(
    name: "myApp",
    dependencies: [.product(name: "PostHog", package: "posthog-ios")]),

Configuration

import Foundation
import PostHog
import UIKit

class AppDelegate: NSObject, UIApplicationDelegate {
    func application(_: UIApplication, didFinishLaunchingWithOptions _: [UIApplication.LaunchOptionsKey: Any]? = nil) -> Bool {
        let POSTHOG_API_KEY = "<ph_project_api_key>"
        // usually 'https://us.i.posthog.com' or 'https://eu.i.posthog.com'
        let POSTHOG_HOST = "https://us.i.posthog.com"

        let config = PostHogConfig(apiKey: POSTHOG_API_KEY, host: POSTHOG_HOST) 
        PostHogSDK.shared.setup(config)

        return true
    }
}

Capturing events

You can send custom events using capture:

PostHogSDK.shared.capture("user_signed_up")

Tip: We recommend using a [object] [verb] format for your event names, where [object] is the entity that the behavior relates to, and [verb] is the behavior itself. For example, project created, user signed up, or invite sent.

Setting event properties

Optionally, you can also include additional information in the event by setting the properties value:

PostHogSDK.shared.capture("user_signed_up", properties: ["login_type": "email"], userProperties: ["is_free_trial": true])

Autocapture

PostHog autocapture automatically tracks the following events for you:

• Application Opened - when the app is opened from a closed state or when the app comes to the foreground (e.g. from the app switcher)
• Application Backgrounded - when the app is sent to the background by the user
• Application Installed - when the app is installed
• Application Updated - when the app is updated
• $screen - when the user navigates (if using UIViewController)
• $autocapture - when the user interacts with elements in a screen (if using UIKit)

🚧 Note: $autocapture is currently supported only in UIKit and remains in an experimental state, with the feature disabled by default. SwiftUI support is planned for an upcoming release.

Autocapture configuration

You can enable or disable autocapture through the PostHogConfig object.

let POSTHOG_API_KEY = "<ph_project_api_key>"
// usually 'https://us.i.posthog.com' or 'https://eu.i.posthog.com'
let POSTHOG_HOST = "https://us.i.posthog.com"

let config = PostHogConfig(apiKey: POSTHOG_API_KEY, host: POSTHOG_HOST)

// capture screen views
config.captureScreenViews = true 
// capture application lifecycle events (installed, updated, opened, backgrounded)
config.captureApplicationLifecycleEvents = true
// capture element interactions (button presses, text input changes, etc.)
config.captureElementInteractions = true 

PostHogSDK.shared.setup(config)

Capturing screen views

With configuration.captureScreenViews set as true, PostHog will try to record all screen changes automatically.

If you want to manually send a new screen capture event, use the screen function.

PostHogSDK.shared.screen("Dashboard", properties: ["fromIcon": "bottom"])

Important: Please note that captureScreenViews configuration is intented for UIKit use. For SwiftUI screen captures, please see the following section.

Capturing screen views in SwiftUI

To track a screen view in SwiftUI, apply the postHogScreenView modifier to your full-screen views. PostHog will send a $screen event when the onAppear action is executed and will infer a screen name based on the view’s type. You can provide a custom name and event properties if needed.

// This will trigger a screen view event with $screen_name: "HomeViewContent"
struct HomeView: View {
    var body: some View {
        HomeViewContent()
            .postHogScreenView()
    }
}

// This will trigger a screen view event with $screen_name: "My Home View" and an additional event property from_button: "start"
struct HomeView: View {
    var body: some View {
        HomeViewContent()
            .postHogScreenView("My Home View", ["from_button": "start"])
    }
}

In SwiftUI, views can range from entire screens to small UI components. Unlike UIKit, SwiftUI doesn’t clearly distinguish between these levels, which makes automatic tracking of full-screen views harder.

Adding a custom label on autocaptured elements

PostHog automatically captures interactions with various UI elements in your app, but these interactions are often identified by element type names (e.g., UIButton, UITextField, UILabel).

While this provides basic tracking, it can be challenging to pinpoint specific interactions with particular elements in your analytics. To make your data more meaningful and actionable, you can assign custom labels to any autocaptured element. These labels act as descriptive identifiers, making it easier to identify, filter, and analyze events in your reports.

Adding a custom label in UIKit

To assign a custom label to a UIView, use the postHogLabel property:

let view = UIView()
view.postHogLabel = "usernameTextField"

In this example, interactions with the UITextField will be captured with an additional identifier "usernameTextField".

Adding a custom label in SwiftUI

In SwiftUI, use the .postHogLabel(_:) modifier instead:

var body: some View {
    ...
    TextField("username", text: $username)
        .postHogLabel("usernameTextField")
}

In this example, interactions with the underlying UITextField will be captured with an additional identifier "usernameTextField".

Example of generated analytics data

The generated analytics element in the examples above will have the following form:

<UITextField id="usernameTextField">text value</UITextField>

Filtering for labeled autocaptured elements in reports

To locate and filter interactions with specific elements in PostHog reports, you can use Autocapture element filters, such as:

• Tag Name (UITextField in this example)
• Text (text value in this example)
• CSS Selector (the generated id attribute in this example)

In the examples above, we can filter for the specific text field using the CSS Selector #usernameTextField

Preventing sensitive data capture

To exclude specific UI elements from autocapture or session replay, add ph-no-capture as either an accessibilityLabel or accessibilityIdentifier. When PostHog detects this label or identifier anywhere in the view hierarchy, the element will be either ignored or masked:

// This view will be excluded from autocapture
let view = UIView()
view.accessibilityLabel = "ph-no-capture"

Important: By default, PostHog will make a best effort to automatically exclude fields detected as sensitive, even without the ph-no-capture tag. These include password fields, credit card fields, OTP fields, and any other fields related to Personally Identifiable Information (PII).

For more details on how to setup masking for session replay, please refer to our Privacy Controls documentation.

Identifying users

We highly recommend reading our section on Identifying users to better understand how to correctly use this method.

Using identify, you can associate events with specific users. This enables you to gain full insights as to how they're using your product across different sessions, devices, and platforms.

An identify call has the following arguments:

• distinct_id which uniquely identifies your user in your database

• userProperties: Optional. A dictionary with key:value pairs to set the person properties
• userPropertiesSetOnce: Optional. Similar to userProperties. See the difference between userProperties and userPropertiesSetOnce

PostHogSDK.shared.identify("user_id_from_your_database",
                            userProperties: ["name": "Peter Griffin", "email": "peter@familyguy.com"],
                            userPropertiesSetOnce: ["date_of_first_log_in": "2024-03-01"])

You should call identify as soon as you're able to. Typically, this is every time your app loads for the first time as well as directly after your user logs in. This ensures that events sent during your user's sessions are correctly associated with them.

When you call identify, all previously tracked anonymous events will be linked to the user.

Get the current user's distinct ID

You may find it helpful to get the current user's distinct ID. For example, to check whether you've already called identify for a user or not.

To do this, call getDistinctId(). This returns either the ID automatically generated by PostHog or the ID that has been passed by a call to identify().

Alias

Sometimes, you want to assign multiple distinct IDs to a single user. This is helpful when your primary distinct ID is inaccessible. For example, if a distinct ID used on the frontend is not available in your backend.

In this case, you can use alias to assign another distinct ID to the same user.

PostHogSDK.shared.alias("alias_id")

We strongly recommend reading our docs on alias to best understand how to correctly use this method.

Anonymous vs identfied events

PostHog captures two types of events: anonymous and identified

Identified events enable you to attribute events to specific users, and attach person properties. They're best suited for logged-in users.

Scenarios where you want to capture identified events are:

• Tracking logged-in users in B2B and B2C SaaS apps
• Doing user segmented product analysis
• Growth and marketing teams wanting to analyze the complete conversion lifecycle

Anonymous events are events without individually identifiable data. They're best suited for web analytics or apps where users aren't logged in.

Scenarios where you want to capture anonymous events are:

• Tracking a marketing website
• Content-focused sites
• B2C apps where users don't sign up or log in

Under the hood, the key difference between identified and anonymous events is that for identified events we create a person profile for the user, whereas for anonymous events we do not.

💡 Tip: Under our current pricing, anonymous events can be up to 4x cheaper than identified ones (due to the cost of processing them), so it's recommended you only capture identified events when needed.

How to capture anonymous events

PostHog captures anonymous events by default. However, this may change depending on your personProfiles config when initializing PostHog:

1. personProfiles: .identifiedOnly (recommended) (default) - Anonymous events are captured by default. PostHog only captures identified events for users where person profiles have already been created.

2. personProfiles: .always - Capture identified events for all events.

3. personProfiles: .never - Capture anonymous events for all events.

For example:

let config = PostHogConfig(
    apiKey: POSTHOG_API_KEY, 
    host: POSTHOG_HOST
)
config.personProfiles = .identifiedOnly
PostHogSDK.shared.setup(config)

How to capture identified events

If you've set the personProfiles config to IDENTIFIED_ONLY (the default option), anonymous events are captured by default. Then, to capture identified events, call any of the following functions:

• identify()
• alias()
• group()

When you call any of these functions, it creates a person profile for the user. Once this profile is created, all subsequent events for this user will be captured as identified events.

Alternatively, you can set personProfiles to ALWAYS to capture identified events by default.

Setting person properties

To set properties on your users via an event, you can leverage the event properties userProperties and userPropertiesSetOnce.

When capturing an event, you can pass a property called $set as an event property, and specify its value to be an object with properties to be set on the user that will be associated with the user who triggered the event.

PostHogSDK.shared.capture("signed_up", properties: ["plan": "Pro++"], userProperties: ["user_property_name": "your_value"])

userPropertiesSetOnce works just like userProperties, except that it will only set the property if the user doesn't already have that property set.

PostHogSDK.shared.capture("signed_up", properties: ["plan": "Pro++"], userPropertiesSetOnce: ["user_property_name": "your_value"])

Super Properties

Super Properties are properties associated with events that are set once and then sent with every capture call, be it a $screen, or anything else.

They are set using PostHogSDK.shared.register, which takes a properties object as a parameter, and they persist across sessions.

For example, take a look at the following call:

PostHogSDK.shared.register(["team_id": 22])

The call above ensures that every event sent by the user will include "team_id": 22. This way, if you filtered events by property using team_id = 22, it would display all events captured on that user after the PostHogSDK.shared.register call, since they all include the specified Super Property.

However, please note that this does not store properties against the User, only against their events. To store properties against the User object, you should use PostHogSDK.shared.identify. More information on this can be found on the Sending User Information section.

Removing stored Super Properties

Super Properties are persisted across sessions so you have to explicitly remove them if they are no longer relevant. In order to stop sending a Super Property with events, you can use PostHogSDK.shared.unregister, like so:

PostHogSDK.shared.unregister("team_id")

This will remove the Super Property and subsequent events will not include it.

If you are doing this as part of a user logging out you can instead simply use PostHogSDK.shared.reset which takes care of clearing all stored Super Properties and more.

Amending event properties before they are captured

In case you need to modify or process event properties before they are captured, cached, and sent to PostHog, you can use the config.propertiesSanitizer option.

This feature allows you to define custom logic for sanitizing or transforming properties, ensuring that your event data meets your specific requirements before it is sent over the wire.

To implement this, define a custom sanitizer by creating a class or struct that conforms to the PostHogPropertiesSanitizer protocol and implement the sanitize() method.

The sanitize() method receives a dictionary of event properties and should return a modified version of the dictionary.

Then pass your custom sanitizer to config.propertiesSanitizer option.

class ExampleSanitizer: PostHogPropertiesSanitizer {
    public func sanitize(_ properties: [String: Any]) -> [String: Any] {
        // Create a mutable copy
        var sanitizedProperties = properties
        // Perform sanitization
        // For example, removing keys with empty values
        for (key, value) in properties {
            if let stringValue = value as? String, stringValue.isEmpty {
                sanitizedProperties.removeValue(forKey: key)
            }
        }
        return sanitizedProperties
    }
}

Flush

You can set the number of events in the configuration that should queue before flushing. Setting this to 1 will send events immediately and will use more battery. This is set to 20 by default.

configuration.flushAt = 1

You can also manually flush the queue:

PostHogSDK.shared.capture("logged_out")
PostHogSDK.shared.flush()

Reset after logout

To reset the user's ID and anonymous ID, call reset. Usually you would do this right after the user logs out.

PostHogSDK.shared.reset()

Opt out of data capture

You can completely opt-out users from data capture. To do this, there are two options:

1. Opt users out by default by setting optOut to true in your PostHog config:

let config = PostHogConfig(apiKey: <ph_project_api_key>, host: https://us.i.posthog.com)
config.optOut = true
PostHogSDK.shared.setup(config)

2. Opt users out on a per-person basis by calling optOut():

PostHogSDK.shared.optOut()

Similarly, you can opt users in:

PostHogSDK.shared.optIn()

To check if a user is opted out:

PostHogSDK.shared.isOptOut()

Group analytics

Group analytics allows you to associate the events for that person's session with a group (e.g. teams, organizations, etc.). Read the Group Analytics guide for more information.

Note: This is a paid feature and is not available on the open-source or free cloud plan. Learn more here.

• Associate the events for this session with a group

PostHogSDK.shared.group(type: "company", key: "company_id_in_your_db")

• Associate the events for this session with a group AND update the properties of that group

PostHogSDK.shared.group(type: "company", key: "company_id_in_your_db", groupProperties: [
    "name": "ACME Corp"
])

The name is a special property which is used in the PostHog UI for the name of the Group. If you don't specify a name property, the group ID will be used instead.

Feature Flags

PostHog's feature flags enable you to safely deploy and roll back new features.

Boolean feature flags

if (PostHogSDK.shared.isFeatureEnabled("flag-key")) {
    // Do something differently for this user

    // Optional: fetch the payload
    let matchedFlagPayload = PostHogSDK.shared.getFeatureFlagPayload("flag-key")
}

Multivariate feature flags

if (PostHogSDK.shared.getFeatureFlag("flag-key") as? String == "variant-key") { // replace "variant-key" with the key of your variant
    // Do something differently for this user

    // Optional: fetch the payload
    let matchedFlagPayload = PostHogSDK.shared.getFeatureFlagPayload("flag-key")
}

Reloading feature flags

Feature flag values are cached. If something has changed with your user and you'd like to refetch their flag values, call:

PostHogSDK.shared.reloadFeatureFlags()

Ensuring flags are loaded before usage

Every time a user opens the app, we send a request in the background to fetch the feature flags that apply to that user. We store those flags in the storage.

This means that for most screens, the feature flags are available immediately – except for the first time a user visits.

To handle this, you can use the didReceiveFeatureFlags notification to wait for the feature flag request to finish:

class AppDelegate: NSObject, UIApplicationDelegate {
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {
        // register for `didReceiveFeatureFlags` notification before SDK initialization
        NotificationCenter.default.addObserver(
            self,
            selector: #selector(receiveFeatureFlags),
            name: PostHogSDK.didReceiveFeatureFlags,
            object: nil
        )

        let POSTHOG_API_KEY = "<ph_project_api_key>"
        // usually 'https://us.i.posthog.com' or 'https://eu.i.posthog.com'
        let POSTHOG_HOST = "https://us.i.posthog.com"

        let config = PostHogConfig(apiKey: POSTHOG_API_KEY, host: POSTHOG_HOST)

        PostHogSDK.shared.setup(config)

        return true
    }

    // The "receiveFeatureFlags" method will be called when the SDK receives the feature flags from the server.
    @objc func receiveFeatureFlags() {
        print("receiveFeatureFlags called")
    }
}

Alternatively, you can use the completion block of the reloadFeatureFlags(_:) method. This allows you to execute logic immediately after the flags are reloaded:

// Reload feature flags and check if a specific feature is enabled
PostHogSDK.shared.reloadFeatureFlags {
    if PostHogSDK.shared.isFeatureEnabled("flag-key") {
        // do something
    }
}

Experiments (A/B tests)

Since experiments use feature flags, the code for running an experiment is very similar to the feature flags code:

if (PostHogSDK.shared.getFeatureFlag("experiment-feature-flag-key") as? String == "variant-name") {
    // do something
}

It's also possible to run experiments without using feature flags.

A note about IDFA (identifier for advertisers) collection in iOS 14

Starting with iOS 14, Apple will further restrict apps that track users. Any references to Apple's AdSupport framework, even in strings, will trip the App Store's static analysis.

Hence starting with posthog-ios version 1.2.0 we have removed all references to Apple's AdSupport framework.

Session replay

To set up session replay in your project, all you need to do is install the iOS SDK, enable "Record user sessions" in your project settings and enable the sessionReplay option.

All configuration options

The configuration element contains several other settings you can toggle:

/**
 * The number of queued events that the posthog client should flush at. Setting this to `1` will not queue
 * any events and will use more battery. `20` by default.
 */
configuration.flushAt = 20

/**
 * The amount of time to wait before each tick of the flush timer.
 * Smaller values will make events delivered in a more real-time manner and also use more battery.
 * A value smaller than 10 seconds will seriously degrade overall performance.
 * 30 seconds by default.
 */
configuration.flushIntervalSeconds = 30

/**
 * The maximum number of items to queue before starting to drop old ones. This should be a value greater
 * than zero, the behaviour is undefined otherwise. `1000` by default.
 */
configuration.maxQueueSize = 1000

/**
 * Number of maximum events in a batch call. (50 by default)
 */
configuration.maxBatchSize = 50

/**
 * Whether the posthog client should automatically make a capture call for application lifecycle events,
 * such as "Application Installed", "Application Updated" and "Application Opened". (on/true by default)
 */
configuration.captureApplicationLifecycleEvents = true

/**
 * Whether the posthog client should automatically make a screen call when a view controller is added to
 * a view hierarchy. Because the underlying implementation uses method swizzling, we recommend initializing
 * the posthog client as early as possible (before any screens are displayed), ideally during the
 * Application delegate's applicationDidFinishLaunching method. (on/true by default)
 */
configuration.captureScreenViews = true

/**
* Whether the posthog client should automatically make a capture call when the user interacts with an element in a screen.
* 
* Experimental support (UIKit)
* Defaults to false
*/
configuration.captureElementInteractions = false

/**
 * Send a `$feature_flag_called` event when a feature flag is used automatically. (on/true by default)
 */
configuration.sendFeatureFlagEvent = true

/**
 * Preload feature flags automatically. (on/true by default)
 */
configuration.preloadFeatureFlags = true

/**
 * Logs the SDK messages into Logcat. (off/false by default)
 */
configuration.debug = false

/**
 * Prevents capturing any data if enabled. (off/false by default)
 */
configuration.optOut = false

/**
 * Callback that allows to sanitize the event properties (not set by default)
 */
configuration.propertiesSanitizer = { ... }

/**
 * Hook that allows for modification of the default mechanism for
 * generating anonymous id (which as of now is just random UUID v7)
 */
configuration.getAnonymousId = { ... }

/**
 * Allows to send your data only if the data mode matches your configuration
 * such as wifi only, cellular only or any.
 * Defaults to .any
 */
configuration.dataMode = .any

/**
 * Determines the behavior for processing user profiles.
 * Defaults to .identifiedOnly
 */
configuration.personProfiles = .identifiedOnly

/**
 * Enable Recording of Session Replays. (off/false by default)
 * Experimental support
 */
configuration.sessionReplay = false

/**
 * Session Replay configuration
 * Experimental support
 */
configuration.sessionReplayConfig = .init()

/**
* The identifier of the App Group that should be used to store shared analytics data. 
* PostHog will try to get the physical location of the App Group’s shared container, otherwise fallback to the default location
*/
configuration.appGroupIdentifier = nil