iOS SDK observability reference

This topic documents how to get started with the LaunchDarkly observability plugin for the iOS SDK.

The iOS SDK supports the observability plugin for error monitoring, logging, and tracing, and the session replay plugin for recording user sessions.

Prerequisites and dependencies

This reference guide assumes that you are somewhat familiar with the LaunchDarkly iOS SDK.

The observability plugin is compatible with the iOS SDK, version 9.14.0 and later, and is only available if you are using Swift.

Get started

Follow these steps to get started:

• Install the plugin
• Initialize the iOS SDK client
• Configure the plugin options
• Configure product analytics event collection
• Track screen views
• Configure session replay
• Explore supported features
• Review observability data in LaunchDarkly

Install the plugin

LaunchDarkly uses a plugin to the iOS SDK to provide observability.

The first step is to make both the SDK and the observability plugin available as dependencies.

Here’s how:

1
//...
2
    dependencies: [
3
        .package(url: "https://github.com/launchdarkly/ios-client-sdk.git", .upToNextMinor("9.0.0")),
4
        .package(url: "https://github.com/launchdarkly/swift-launchdarkly-observability.git", .upToNextMinor("1.0.0")),
5
    ],
6
    targets: [
7
        .target(
8
            name: "YOUR_TARGET",
9
            dependencies: ["LaunchDarkly"]
10
        )
11
    ],
12
//...

Then, import the plugin into your code:

1
import LaunchDarkly
2
import LaunchDarklyObservability
3
import OpenTelemetryApi

Initialize the client

Next, initialize the SDK and the plugin.

To initialize, you need your LaunchDarkly environment’s mobile key. This authorizes your application to connect to a particular environment within LaunchDarkly. To learn more, read Initialize the client in the Android SDK reference guide.

Here’s how to initialize the SDK and plugin:

1
let config = LDConfig(mobileKey: "example-mobile-key", autoEnvAttributes: .enabled)
2
config.plugins = [Observability()]
3
4
let contextBuilder = LDContextBuilder(key: "example-context-key")
5
guard case .success(let context) = contextBuilder.build()
6
else { return }
7
8
LDClient.start(config: config, context: context, startWaitSeconds: 5) { timedOut in
9
    if timedOut {
10
        // Client may not have the most recent flags for the configured context
11
    } else {
12
        // Client has received flags for the configured context
13
    }
14
}

Configure the plugin options

You can configure options for the observability plugin when you initialize the SDK. The plugin constructor takes an optional object with the configuration details.

Here is an example:

1
// Create the plugin options
2
let options = ObservabilityOptions(
3
    serviceName: "MyApp",
4
    serviceVersion: "1.2.3",
5
    otlpEndpoint: "https://otel.observability.app.launchdarkly.com:4318",
6
    resourceAttributes: [
7
        "environment": .string("production"),
8
        "team": .string("mobile-team"),
9
        "app.version": .string("1.2.3")
10
    ],
11
    customHeaders: ["Custom-Header": "header-value"],
12
    sessionBackgroundTimeout: 30 * 60, // 30 minutes in seconds
13
    isDebug: false
14
)
15
16
// Create the observability plugin with the options
17
let observabilityPlugin = Observability(options: options)
18
19
let config = LDConfig(mobileKey: "example-mobile-key", autoEnvAttributes: .enabled)
20
config.plugins = [observabilityPlugin]

Configuration options

The ObservabilityOptions struct provides the following parameters:

• isEnabled: When false, the plugin installs but exports no telemetry. Defaults to true.
• serviceName: The service name for the application. Defaults to “observability-swift”.
• serviceVersion: The service version for the application. Defaults to “0.1.0”.
• otlpEndpoint: The endpoint URL for the OpenTelemetry Protocol (OTLP) exporter. Defaults to the LaunchDarkly endpoint.
• resourceAttributes: Additional OpenTelemetry resource attributes to include in telemetry data.
• customHeaders: Custom headers to include with OTLP exports.
• sessionBackgroundTimeout: How long the app can stay in the background, in seconds, before the current session ends. Defaults to 15 minutes (900 seconds).
• isDebug: Enables additional logging for debugging. Defaults to false.
• logsApiLevel: The minimum severity of logs to export. Use .none to disable log collection. Defaults to .info.
• tracesApi: Controls trace collection. Defaults to .enabled.
• metricsApi: Controls metric collection. Defaults to .enabled.
• crashReporting: Controls automatic crash reporting. Defaults to .enabled.
• tracingOrigins: Which outgoing request origins propagate distributed tracing headers. Defaults to .disabled.
• urlBlocklist: URL patterns to exclude from automatic URLSession instrumentation. Defaults to an empty array.
• contextFriendlyName: A human-readable name to attach to the LaunchDarkly context for this session.
• instrumentation: Controls automatic instrumentation. To learn more, read Instrumentation options.
• analytics: Controls which product analytics events the plugin emits as OpenTelemetry spans. To learn more, read Configure product analytics event collection.

Instrumentation options

The instrumentation option controls which automatic instrumentations the plugin runs. Pass an Instrumentation value, or use the .enabled and .disabled presets to turn all of them on or off at once.

The Instrumentation options are:

• urlSession: Instruments URLSession requests. Defaults to .disabled.
• userTaps: Runs tap detection. The analytics.taps option separately controls whether the plugin publishes detected taps as click spans. If userTaps is .disabled, the plugin publishes no click spans regardless of the analytics.taps value. Neither option affects session replay capture. Defaults to .enabled.
• memory: Records memory usage metrics. Defaults to .disabled.
• memoryWarnings: Records memory warning events. Defaults to .disabled.
• cpu: Records CPU usage metrics. Defaults to .disabled.
• launchTimes: Emits launch-time performance telemetry, including the app.start span event that carries the cold or warm startup dimension on the app_launch span. Defaults to .enabled.
• screens: Automatically detects screen changes by swizzling UIViewController. Screen detection drives both the automatic screen_view span and the session replay Navigate events. Defaults to .enabled. The analytics.screenViews option gates screen_view spans.

Here is an example that turns off automatic screen detection while leaving other instrumentation at its default:

1
let options = ObservabilityOptions(
2
    instrumentation: ObservabilityOptions.Instrumentation(screens: .disabled)
3
)

For more information on plugin options, read Configuration for client-side observability.

Configure product analytics event collection

The iOS observability plugin can record the following product analytics events as OpenTelemetry spans:

• Taps (automatic): A click span for each user tap, with details about the tapped element and screen location. Enabled by default.
• Track events (manual): A track span when your code calls track(key:properties:metricValue:). To learn more, read Recording product analytics events.
• Screen views (automatic and manual): A screen_view span when a screen appears, either detected automatically or recorded manually when your code calls trackScreenView(). To learn more, read Recording product analytics events.
• App lifecycle (automatic): An app_foreground or app_background span as the app moves between the foreground and background states. Enabled by default.
• App launches (automatic): An app_launch span once per process launch, with the launch type and version information, plus an app.start span event that records the cold or warm startup dimension. Enabled by default. To learn more, read App launch events.

All product analytics span events also include information about the LaunchDarkly context that generated the event.

Use the generated span events to create custom product analytics charts, such as time series and funnels. To learn more, read Product analytics events.

The plugin records all event types by default. To disable all product analytics events, set analytics to .disabled in ObservabilityOptions. To control individual event types, pass an Analytics value directly:

1
let options = ObservabilityOptions(
2
    analytics: .disabled
3
)

The Analytics options are:

• taps: Emits a click span for each detected tap. Defaults to .enabled.
• trackEvents: Emits a track span when a custom event is tracked with track(key:properties:metricValue:). Defaults to .enabled.
• screenViews: Emits a screen_view span when a screen appears. Defaults to .enabled.
• appLifecycle: Emits app_foreground and app_background spans as the app moves between states. Defaults to .enabled.
• appLaunch: Emits an app_launch span once per process launch, including an app.start span event with the cold or warm startup dimension. Defaults to .enabled.

App launch events

The iOS observability plugin records a single app_launch span once per process launch. The plugin captures process start timing as early as possible during launch using a startup constructor that runs before main, then emits the app_launch span after observability initializes. This means the recorded startup duration reflects actual launch time rather than SDK initialization time.

The app_launch span includes:

• event.launch_type: Classifies the launch as install (first launch after install), update (first launch after a version update), or relaunch (a subsequent launch of the same version). The plugin determines the launch type by comparing the current app version to the previously stored version.
• Version attributes, including the current app version and, on an update, the previous version.
• An app.start span event with a start.type attribute (cold or warm) and, when available, a start.duration_ms attribute. A warm start is detected when the operating system prewarms the app, using the ActivePrewarm environment variable on iOS 15 and later.

To learn more about app launch attributes across SDKs, read App launch events.

Track screen views

The plugin emits a screen_view span when your app shows a screen. Each span uses the event.* attribute namespace, including event.name, event.screen_class, event.screen_id, event.previous_screen, and event.category. The plugin resolves event.previous_screen from a shared screen stack to ensure correctness whether the plugin captured the screen or your code recorded it manually.

Each recorded screen change also produces a session replay Navigate event to reflect navigation in the replay timeline.

Capture UIKit view controllers automatically

When instrumentation.screens is .enabled (the default), the plugin swizzles UIViewController and records a screen_view span each time a view controller appears. The plugin skips container and system controllers such as UINavigationController and UITabBarController.

To customize how the plugin reports a controller, conform it to LDScreenNameProviding:

1
import LaunchDarklyObservability
2
3
final class CheckoutViewController: UIViewController, LDScreenNameProviding {
4
    var ldScreenName: String? { "Checkout" }
5
    var ldScreenCategory: String? { "Commerce" }
6
}

Capture SwiftUI screens manually

The UIViewController swizzle does not observe pure SwiftUI navigation, such as NavigationStack destinations. You must record those screens manually.

Use the trackScreen modifier on the screen’s root view. Only one call per screen is required, because the plugin resolves event.previous_screen from the shared screen stack:

1
import SwiftUI
2
import LaunchDarklyObservability
3
4
struct ProfileView: View {
5
    var body: some View {
6
        VStack {
7
            // ...
8
        }
9
        .trackScreen("Profile", category: "Account")
10
    }
11
}

Track navigation stacks and modals

The trackScreen modifier records on .onAppear. SwiftUI does not re-run .onAppear when you pop back to a screen in a NavigationStack or when a sheet or fullScreenCover closes. Use the path-aware and presentation-aware modifiers to ensure that back navigation and modal returns are tracked correctly.

Apply trackScreenStack to the NavigationStack itself, passing the same path binding. The plugin records the top of the path, or the root name when the path is empty, on first appearance and on every push and pop. Return nil from destination to skip a screen that already records itself:

1
import SwiftUI
2
import LaunchDarklyObservability
3
4
struct RootView: View {
5
    @State private var path: [Route] = []
6
7
    var body: some View {
8
        NavigationStack(path: $path) {
9
            // ...
10
        }
11
        .trackScreenStack(path, root: "Home") { route in
12
            switch route {
13
            case .profile: return "Profile"
14
            case .settings: return "Settings"
15
            }
16
        }
17
    }
18
}

Apply trackScreenReturn to a presenting screen to record it again after a modal closes. Pass the flag, or combination of flags, that drives the presentation. The plugin records the screen on each transition from true to false:

1
struct RootView: View {
2
    @State private var activeSheet: Sheet?
3
4
    var body: some View {
5
        List { /* ... */ }
6
            .sheet(item: $activeSheet) { sheet in /* ... */ }
7
            .trackScreenReturn("Home", isPresented: activeSheet != nil)
8
    }
9
}

Driving presentations from a single optional or enum route, such as sheet(item:), keeps isPresented to one expression. If you use multiple sheet(isPresented:) flags, combine them, as in isPresented: a || b || c.

Both trackScreenStack and trackScreenReturn require iOS 14, macOS 11, tvOS 14, or watchOS 7 and later.

Record a screen view directly

You can also call trackScreenView from anywhere after the SDK initializes. To learn more, read Recording product analytics events.

Manual trackScreenView calls work even when you disable automatic detection with instrumentation.screens. The analytics.screenViews option still gates the emitted screen_view span.

Manual instrumentation

To implement distributed tracing, all spans generated across different function calls and services for the same user request must share the same context.

Recording custom metrics

Use the metric methods on LDObserve.shared to record a Metric with a name and a value. Each method maps to a different OpenTelemetry instrument type:

1
// Record a point-in-time metric
2
LDObserve.shared.recordMetric(metric: Metric(name: "response_time_ms", value: 250.0))
3
4
// Record metrics with attributes
5
let attributes: [String: AttributeValue] = [
6
    "endpoint": .string("/api/users"),
7
    "method": .string("GET")
8
]
9
LDObserve.shared.recordMetric(metric: Metric(
10
    name: "api_call_duration", 
11
    value: 120.5, 
12
    attributes: attributes
13
))
14
15
// Record different metric types
16
LDObserve.shared.recordCount(metric: Metric(name: "button_clicks", value: 1.0))
17
LDObserve.shared.recordIncr(metric: Metric(name: "page_views", value: 1.0))
18
LDObserve.shared.recordHistogram(metric: Metric(name: "request_size_bytes", value: 1024.0))
19
LDObserve.shared.recordUpDownCounter(metric: Metric(name: "active_connections", value: 5.0))

Recording custom logs

Use LDObserve.shared.recordLog to emit a structured log. Pass attributes as a plain Swift dictionary through the properties parameter:

1
// Record a basic log message
2
LDObserve.shared.recordLog(
3
    message: "User login successful",
4
    severity: .info,
5
    properties: [:]
6
)
7
8
// Record logs with custom properties
9
LDObserve.shared.recordLog(
10
    message: "Authentication completed",
11
    severity: .info,
12
    properties: [
13
        "user_id": "12345",
14
        "action": "login"
15
    ]
16
)

Recording custom errors

Use LDObserve.shared.recordError to report a caught error, with optional attributes for context:

1
do {
2
    // Some operation that might fail
3
    try performNetworkRequest()
4
} catch {
5
    // Record the error with context
6
    let errorAttributes: [String: AttributeValue] = [
7
        "operation": .string("network_request"),
8
        "endpoint": .string("/api/data")
9
    ]
10
    LDObserve.shared.recordError(error: error, attributes: errorAttributes)
11
}

Recording custom traces

Use LDObserve.shared.startSpan to create a span for tracing an operation. Always end the span when the operation completes:

1
// Start a span with custom properties
2
let span = LDObserve.shared.startSpan(
3
    name: "database_query",
4
    properties: [
5
        "table": "users",
6
        "operation": "select"
7
    ]
8
)
9
10
// Perform your operation
11
performDatabaseQuery()
12
13
// Optionally add more attributes during execution
14
span.setAttribute(key: "rows_returned", value: .int(42))
15
16
// Always end the span
17
span.end()

Recording product analytics events

Use track to record a custom event as a product analytics span. Use trackScreenView to record a screen view:

1
// Track an event with properties and an optional metric value
2
LDObserve.shared.track(
3
    key: "purchase_completed",
4
    properties: [
5
        "product_id": "SKU-123",
6
        "price": 29.99
7
    ],
8
    metricValue: 29.99
9
)
10
11
// Track an event with no properties
12
LDObserve.shared.track(key: "button_tapped")

1
// Convenience — name only
2
LDObserve.shared.trackScreenView(name: "ProductDetail")
3
4
// With category
5
LDObserve.shared.trackScreenView(name: "Checkout", category: "purchase")
6
7
// Full details with custom properties
8
LDObserve.shared.trackScreenView(
9
    name: "ProductDetail",
10
    screenClass: "ProductDetailViewController",
11
    screenId: "product-123",
12
    category: "browsing",
13
    properties: [
14
        "product_id": "SKU-123",
15
        "source": "search_results"
16
    ]
17
)

Using span builder for advanced tracing

Use LDObserve.shared.spanBuilder when you need more control over a span than startSpan provides, such as setting the span kind or adding attributes before the span starts:

1
// Get span builder for more control
2
let spanBuilder = LDObserve.shared.spanBuilder(spanName: "complex_operation")
3
    .setSpanKind(spanKind: .client)
4
5
spanBuilder.setAttribute(key: "user.id", value: .string("12345"))
6
let span = spanBuilder.startSpan()
7
8
// Make the span current for nested operations
9
span.makeCurrent()
10
11
// Perform work that might create child spans
12
performComplexWork()
13
14
span.end()

Using distributed tracing

To implement distributed tracing, all spans generated across different function calls and services for the same user request must share the same context.

While nested spans in the same scope automatically use the context of their parent span, Swift’s concurrency model (async, await, or Task) does not propagate the parent span context. Use the OpenTelemetry API to obtain and pass the parent span context explicitly to asynchronous methods:

1
let span0 = LDObserve.shared.startSpan(name: "parentSpan", properties: [:])
2
3
await OpenTelemetry.instance.contextProvider.withActiveSpan(span0) {
4
  let span1 = LDObserve.shared.startSpan(name: "NestedSpan1", properties: [:])
5
  await OpenTelemetry.instance.contextProvider.withActiveSpan(span1) {
6
    LDObserve.shared.recordLog(message: "NestedLog", severity: .info, properties: [:])
7
  }
8
  span1.end()
9
}
10
span0.end()

Alternatively, you can store the current context and then later restore it in a different scope:

1
// Capture the current context
2
let span = LDObserve.shared.startSpan(
3
    name: "log-context-demo",
4
    properties: ["demo": "log-with-context"]
5
)
6
let capturedContext = span.context
7
span.end()
8
9
// Simulate a detached task where the OpenTelemetry context would be lost automatically.
10
DispatchQueue.global(qos: .background).async {
11
    LDObserve.shared.recordLog(
12
        message: "Log with span context",
13
        severity: .warn,
14
        properties: ["source": "detached-queue-demo"],
15
        spanContext: capturedContext
16
    )
17
}

To propagate a span context to an entirely different service, use the OpenTelemetry W3CTraceContextPropagator to inject the context into outgoing HTTP headers. Services that receive the headers can then extract and use the context.

1
import OpenTelemetryApi
2
3
var request = URLRequest(url: url)
4
let activeSpan = OpenTelemetry.instance.contextProvider.activeSpan
5
let propagator = W3CTraceContextPropagator()
6
7
// Inject current active span context into headers
8
var headers: [String: String] = [:]
9
propagator.inject(
10
    spanContext: activeSpan.context,
11
    carrier: &headers,
12
    setter: { carrier, key, value in carrier[key] = value }
13
)
14
headers.forEach { request.setValue($1, forHTTPHeaderField: $0) }

The above example adds header content similar to:

1
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
2
tracestate: (optional vendor data)

Services that receive the headers would use the extract method from W3CTraceContextPropagator to obtain fields from header and use them as the parent context for new spans.

Session management

The observability plugin automatically manages sessions and handles application lifecycle events. Sessions are automatically ended when:

• The application is backgrounded for longer than the configured sessionBackgroundTimeout, which defaults to 15 minutes
• The application is terminated
• A new session is explicitly started

Session timeout configuration

You can configure how long the plugin waits before ending a session when the app goes to the background:

1
let options = ObservabilityOptions(
2
    sessionBackgroundTimeout: 45 * 60 // 45 minutes in seconds
3
)

Automatic instrumentation

The observability plugin automatically instruments your iOS application to collect:

• Application launch and lifecycle events: App launch, foreground, and background events, recorded as product analytics spans. To learn more, read Configure product analytics event collection.
• Session tracking: Automatic session start and end events with timing.
• Network requests: HTTP request/response data when enabled.
• Taps: A click span for each tap interaction.
• Screen views: A screen_view span when a UIViewController appears, and a session replay Navigate event on each screen change. To learn more, read Track screen views.
• LaunchDarkly SDK events: Feature flag evaluations and SDK operations.

Session Replay

Session Replay captures user interactions and screen recordings to help you understand how users interact with your application. Session Replay works as an additional plugin that requires the observability plugin to be configured first.

Install the Session Replay plugin

First, add the Session Replay package as a dependency alongside the observability plugin:

1
//...
2
    dependencies: [
3
        .package(url: "https://github.com/launchdarkly/ios-client-sdk.git", .upToNextMinor("9.0.0")),
4
        .package(url: "https://github.com/launchdarkly/swift-launchdarkly-observability.git", .upToNextMinor("1.0.0")),
5
    ],
6
    targets: [
7
        .target(
8
            name: "YOUR_TARGET",
9
            dependencies: [
10
                "LaunchDarkly",
11
                .product(name: "LaunchDarklySessionReplay", package: "swift-launchdarkly-observability")
12
            ]
13
        )
14
    ],
15
//...

Then, import the Session Replay plugin into your code:

1
import LaunchDarkly
2
import LaunchDarklyObservability
3
import LaunchDarklySessionReplay

Initialize Session Replay

To enable Session Replay, add the SessionReplay plugin to your SDK configuration alongside the Observability plugin. The Observability plugin must be added before the SessionReplay plugin:

1
let mobileKey = "example-mobile-key"
2
let config = LDConfig(
3
    mobileKey: mobileKey,
4
    autoEnvAttributes: .enabled
5
)
6
config.plugins = [
7
    // Observability plugin must be added before SessionReplay
8
    Observability(options: .init(
9
        serviceName: "ios-app",
10
        sessionBackgroundTimeout: 3)),
11
    SessionReplay(options: .init(
12
        isEnabled: true,
13
        privacy: .init(
14
            maskTextInputs: true,
15
            maskWebViews: false,
16
            maskImages: false,
17
            maskAccessibilityIdentifiers: ["email-field", "password-field"]
18
        )
19
    ))
20
]
21
22
let contextBuilder = LDContextBuilder(key: "example-context-key")
23
guard case .success(let context) = contextBuilder.build()
24
else { return }
25
26
LDClient.start(
27
    config: config,
28
    context: context,
29
    startWaitSeconds: 5.0,
30
    completion: { (timedOut: Bool) -> Void in
31
        if timedOut {
32
            // Client may not have the most recent flags for the configured context
33
        } else {
34
            // Client has received flags for the configured context
35
        }
36
    }
37
)

Initialize the plugins after the SDK client

You can initialize the session replay plugin manually, after the SDK client is initialized.

This approach supports feature-flagged rollouts or dynamic initialization after end user consent. Set isEnabled to false in SessionReplayOptions, then call LDReplay.shared.start() when you’re ready to begin recording.

First, configure the plugin with isEnabled: false:

1
let config = LDConfig(
2
    mobileKey: "example-mobile-key",
3
    autoEnvAttributes: .enabled
4
)
5
config.plugins = [
6
    Observability(),
7
    SessionReplay(options: .init(
8
        isEnabled: false, // Don't start recording automatically
9
        privacy: .init(
10
            maskTextInputs: true
11
        )
12
    ))
13
]
14
15
let contextBuilder = LDContextBuilder(key: "example-context-key")
16
guard case .success(let context) = contextBuilder.build()
17
else { return }
18
19
LDClient.start(config: config, context: context, startWaitSeconds: 5)

Then, start the session replay plugin when appropriate, such as after receiving end user consent or when a feature flag enables session replay.

1
// Start recording after user consent or feature flag check
2
LDReplay.shared.start()

This approach allows you to:

• Feature-flag the rollout of session replay to a subset of end users
• Wait for end user consent before starting data collection
• Dynamically enable session replay based on runtime conditions
• Maintain compliance with privacy regulations

Configure Session Replay privacy options

The Session Replay plugin provides privacy options to control what data is captured. Configure these options when initializing the plugin:

1
SessionReplay(options: .init(
2
    isEnabled: true,
3
    serviceName: "my-swift-app",
4
    privacy: .init(
5
        maskTextInputs: true,
6
        maskWebViews: false,
7
        maskLabels: false,
8
        maskImages: false,
9
        maskUIViews: [SensitiveView.self],
10
        ignoreUIViews: [PublicView.self],
11
        maskAccessibilityIdentifiers: ["email-field", "password-field"],
12
        ignoreAccessibilityIdentifiers: ["public-label"],
13
        minimumAlpha: 0.02
14
    )
15
))

Privacy configuration options

The PrivacyOptions struct provides the following parameters:

• maskTextInputs: Mask all text input fields. Defaults to true.
• maskWebViews: Mask the contents of web views (WKWebView and UIWebView). When this setting is enabled, web views are rendered as blank rectangles in session replays. Defaults to false.
• maskLabels: Mask all text labels. Defaults to false.
• maskImages: Mask all images. Defaults to false.
• maskUIViews: Array of UIView classes to automatically mask in recordings.
• ignoreUIViews: Array of UIView classes to exclude from masking rules.
• maskAccessibilityIdentifiers: Array of accessibility identifiers to mask. Use this to mask specific UI elements by their accessibility identifier.
• ignoreAccessibilityIdentifiers: Array of accessibility identifiers to exclude from masking rules.
• minimumAlpha: Minimum alpha value for view visibility in recordings. Views with alpha below this threshold are not captured. Defaults to 0.02.

Fine-grained masking control

You can override the default privacy settings on individual views. Use .ldMask() to mask a view, .ldUnmask() to exempt one from masking, and .ldPrivate(isEnabled:) to mask a view conditionally. These give you precise control over what session replay captures.

SwiftUI view masking

Use view modifiers to control masking for SwiftUI views:

1
import SwiftUI
2
import LaunchDarklySessionReplay
3
4
struct ContentView: View {
5
    @State private var email = ""
6
    @State private var shouldMaskEmail = true
7
8
    var body: some View {
9
        VStack {
10
            // Mask this specific view
11
            Text("Sensitive information")
12
                .ldMask()
13
14
            // Unmask this view (even if it would be masked by default)
15
            Image("profile-photo")
16
                .ldUnmask()
17
18
            // Conditionally mask based on a flag
19
            TextField("Email", text: $email)
20
                .ldPrivate(isEnabled: shouldMaskEmail)
21
        }
22
    }
23
}

UIKit view masking

Use the .ldMask(), .ldUnmask(), and .ldPrivate(isEnabled:) methods on UIView instances:

1
import UIKit
2
import LaunchDarklySessionReplay
3
4
class CreditCardViewController: UIViewController {
5
    let cvvField = UITextField()
6
    let nameField = UITextField()
7
    let cardNumberField = UITextField()
8
9
    override func viewDidLoad() {
10
        super.viewDidLoad()
11
12
        // Mask the CVV field
13
        cvvField.ldMask()
14
15
        // Unmask the name field (even if text inputs are masked by default)
16
        nameField.ldUnmask()
17
18
        // Conditionally mask based on a flag
19
        cardNumberField.ldPrivate(isEnabled: true)
20
    }
21
}

Masking precedence

When the SDK decides whether to mask a view, it evaluates the following rules in order and stops at the first rule that applies:

1. Explicit masking: If the view or any of its parent views is explicitly masked with .ldMask() or a matching maskAccessibilityIdentifiers entry, the SDK masks the view. This overrides all other rules.
2. Explicit unmasking: If the view or any of its parent views is explicitly unmasked with .ldUnmask(), the SDK does not mask the view.
3. Global configuration: If a global privacy option such as maskTextInputs or maskImages applies to the view, the SDK follows that option.

If rules conflict at the same level, masking wins over unmasking.

Explore supported features

The observability plugin supports the following features. After the SDK and plugins are initialized, you can access these from within your application:

• Configuration for client-side observability
• Configuration for session replay
• Errors
• Logs
• Metrics
• Symbolication
• Tracing

Review observability data in LaunchDarkly

After you initialize the SDK and observability plugin, your application automatically starts sending observability data back to LaunchDarkly in the form of custom events and OpenTelemetry data. You can review this information in the LaunchDarkly user interface. To learn how, read Observability.

The observability data collected includes:

• Error monitoring: Unhandled exceptions, crashes, and manually recorded errors with stack traces
• Logs: Application logs with configurable severity levels and custom attributes
• Traces: Distributed tracing data including span timing, nested operations, and custom instrumentation
• Metrics: Performance metrics, custom counters, histograms, and gauge measurements
• Session data: User session information including lifecycle events and timing

Specifically, the observability data includes events that LaunchDarkly uses to automatically create the following metrics:

• User error rate and crash frequency
• Application performance metrics such as launch time and session duration
• Feature flag evaluation context and timing
• Custom business metrics recorded through the SDK

To learn more about autogenerated metrics, read Observability autogenerated metrics.