> ## Documentation Index
> Fetch the complete documentation index at: https://test-8ad8522e-feat-ai-sre.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# iOS SDK Performance Impact

> Learn about the performance impact of the Flashduty iOS RUM SDK on CPU, memory, launch time, package size, and network usage, along with optimization recommendations.

## Overview

When integrating any SDK into an iOS application, understanding its performance impact is crucial for maintaining a good user experience. The Flashduty RUM SDK is designed with the goal of minimizing performance overhead and provides transparent measurement data to help you evaluate whether the SDK meets your application's performance budget.

<Check>
  The SDK uses asynchronous processing mechanisms, with all data processing performed in background queues without blocking the main thread.
</Check>

## Performance Benchmark

To evaluate the actual performance impact of the SDK on your application, we conducted performance benchmarks under typical usage scenarios. The following SDK features were enabled during testing:

* Basic RUM monitoring: View, action, and resource tracking
* Distributed tracing

The SDK was initialized with default configuration and simulated common user operations (such as page views, scrolling lists, network requests, etc.).

### Test Results

| Metric            | With SDK                       | Without SDK | Impact                   |
| ----------------- | ------------------------------ | ----------- | ------------------------ |
| Peak CPU Usage    | \~44%                          | \~40%       | +4%                      |
| Peak Memory Usage | \~72 MB                        | \~68 MB     | +4 MB                    |
| App Launch Time   | \~0.9 ms                       | \~0.65 ms   | +0.25 ms                 |
| Package Size      | +1.4 MB                        | -           | \~1.4 MB                 |
| Network Usage     | \~22 KB sent / \~2 KB received | -           | Varies with event volume |

<Note>
  The above data are reference values under typical scenarios; actual impact may vary depending on application complexity, device performance, and SDK configuration.
</Note>

### Performance Impact Details

<AccordionGroup>
  <Accordion title="CPU Usage" icon="microchip">
    The SDK's CPU impact primarily comes from:

    * Event collection and processing
    * Data batching and compression
    * Network request reporting

    The SDK uses asynchronous processing mechanisms, with all data processing performed in background queues without blocking the main thread, ensuring it does not affect the application's UI responsiveness.
  </Accordion>

  <Accordion title="Memory Usage" icon="memory">
    The SDK uses a fixed-size memory buffer to store pending event data, which does not grow indefinitely over time. Stale data is automatically cleaned up to ensure it does not consume excessive memory.
  </Accordion>

  <Accordion title="Launch Time" icon="rocket">
    The SDK initialization process is optimized, with impact on application launch time controlled to sub-millisecond level.

    <Tip>
      It is recommended to initialize the SDK as early as possible in `AppDelegate`'s `didFinishLaunchingWithOptions` to capture the complete application startup process.
    </Tip>
  </Accordion>

  <Accordion title="Package Size" icon="box">
    The SDK uses a modular design, allowing you to include only the necessary functional modules:

    | Dependency Name           | Import Name              | Description                   |
    | ------------------------- | ------------------------ | ----------------------------- |
    | `FlashcatCore`            | `DatadogCore`            | Core functionality (required) |
    | `FlashcatRUM`             | `DatadogRUM`             | RUM monitoring                |
    | `FlashcatTrace`           | `DatadogTrace`           | Distributed tracing           |
    | `FlashcatWebViewTracking` | `DatadogWebViewTracking` | WebView tracking              |

    Including only the necessary modules can minimize the impact on package size.
  </Accordion>

  <Accordion title="Network Usage" icon="wifi">
    The SDK employs the following strategies to optimize network usage:

    * **Batch reporting**: Events are cached locally first and sent in batches to reduce the number of network requests
    * **Data compression**: Reported data is compressed to reduce transmission traffic
    * **Intelligent scheduling**: Upload timing is intelligently scheduled based on network status and battery level
  </Accordion>
</AccordionGroup>

## Performance Optimization Recommendations

If you have specific performance requirements, consider the following measures:

<Steps>
  <Step title="Adjust the sample rate">
    Reduce the number of collected events by configuring the sample rate:

    ```swift theme={null}
    RUM.enable(
        with: RUM.Configuration(
            applicationID: "<RUM_APPLICATION_ID>",
            sessionSampleRate: 80 // sample 80% of sessions
        )
    )
    ```
  </Step>

  <Step title="Enable only the features you need">
    Turn off the automatic tracking you do not analyze:

    ```swift theme={null}
    RUM.enable(
        with: RUM.Configuration(
            applicationID: "<RUM_APPLICATION_ID>",
            uiKitViewsPredicate: nil,      // disable automatic view tracking
            uiKitActionsPredicate: nil,    // disable automatic action tracking (nil by default)
            trackFrustrations: false,      // disable frustration signals (enabled by default)
            trackBackgroundEvents: false,  // disable background events (false by default)
            longTaskThreshold: nil,        // disable long task tracking (default 0.1 s)
            vitalsUpdateFrequency: nil,    // stop collecting vitals (default .average, every 500 ms)
            telemetrySampleRate: 0         // disable the SDK's internal telemetry (default 20%)
        )
    )
    ```

    <Warning>
      This step trades data coverage for load, so weigh each option against what you actually analyze. Disabling action tracking drops automatic action events to zero, and the frustration signals that depend on them (rage/dead/error tap) disappear with them. View, resource and error events are unaffected, and manual instrumentation still works.

      `telemetrySampleRate: 0` disables the SDK's own operational telemetry. It does not affect any RUM data, so you can set it safely.

      **Disabling long task tracking costs more than its name suggests.** Frozen frames are not counted from rendered frames — they are the subset of long tasks running past 700ms — and Freeze Frequency is derived from the frozen-frame count. So `longTaskThreshold: nil` drives **Long Tasks, Frozen Frames and Freeze Frequency all to 0 at once** in the dashboard's Smoothness Analysis table, which reads as "no jank at all" when it really means "not measured". Slow Frame Share travels a separate path and is unaffected. If your goal is to reduce event volume, **raise the threshold rather than disabling it** — for example `longTaskThreshold: 0.5`, which keeps every frozen frame because the 700ms criterion sits above 500ms.
    </Warning>

    <Note>
      In Swift, long task tracking is disabled with `longTaskThreshold: nil`. The Objective-C bridge cannot pass `nil`, so you have to write `rumConfiguration.longTaskThreshold = 0`. That does disable the feature, but RUM logs a `cannot be less than 0s` error on every start. This is expected and can be ignored.
    </Note>
  </Step>

  <Step title="Tune the upload cadence">
    Adjust the upload interval, batch window and per-cycle batch limit to reduce contention between SDK uploads and your own requests, without losing any events. See the next section.
  </Step>
</Steps>

## Reducing the Impact of Uploads on Your Own Requests

If your app makes latency-sensitive requests of its own (sign-in, checkout, key provisioning) over a narrow uplink, SDK uploads can compete with them for the uplink. The symptom is a higher tail (P95) on your own request latency that comes and goes.

Three core settings change how uploads are distributed over time — fewer uploads, spread further apart:

```swift theme={null}
Datadog.initialize(
    with: Datadog.Configuration(
        clientToken: "<CLIENT_TOKEN>",
        env: "<ENV_NAME>",
        batchSize: .large,             // batch window: default .medium 10 s -> .large 35 s
        uploadFrequency: .rare,        // upload interval: default .average 2 s -> .rare 5 s
        batchProcessingLevel: .low     // batches per cycle: default .medium 20 -> .low 5
    ),
    trackingConsent: .granted
)
```

| Setting                | Default                | Suggested          | Effect                                                                                                                      |
| ---------------------- | ---------------------- | ------------------ | --------------------------------------------------------------------------------------------------------------------------- |
| `uploadFrequency`      | `.average` (2 s)       | `.rare` (5 s)      | Lengthens the interval between upload cycles, lowering the chance of colliding with your requests                           |
| `batchSize`            | `.medium` (10 s)       | `.large` (35 s)    | Batches collect for longer, so there are fewer requests; larger batches also compress better, so uplink bytes drop slightly |
| `batchProcessingLevel` | `.medium` (20 batches) | `.low` (5 batches) | Caps how many batches one upload cycle ships back-to-back, so a backlog cannot saturate the uplink at once                  |

<Tip>
  These three settings only change *when* uploads happen. They drop no events and remove no dimension from your dashboards, so if you do not want to sacrifice data, tune only these. The iOS SDK always compresses upload requests with deflate, so there is nothing to configure there.
</Tip>

<Note>
  The iOS, Android, HarmonyOS and Flutter SDKs use the same names and values for these three settings, so tuning advice transfers between platforms unchanged. The one difference is that iOS `.low` is 5 batches per cycle, while Android and HarmonyOS use 1 — same direction, smaller reduction.
</Note>

If the event volume itself is high, an EventMapper can drop specific noisy events (return `nil` from the mapper). That is less invasive than changing your instrumentation — see [Advanced configuration](/en/rum/sdk/ios/advanced-config).

## Offline Data Storage

When the device is offline, the SDK stores data locally with strict storage space limits:

<Check>
  * Uses fixed-size disk cache
  * Expired data is automatically cleaned up
  * Cached data will not affect device storage space
</Check>

## Battery Consumption

The SDK is designed with battery consumption in mind:

* Automatically reduces upload frequency when battery level falls below a certain threshold
* Leverages system background task mechanisms for data reporting
* Avoids frequent device wake-ups

## Related Documentation

<CardGroup cols={2}>
  <Card title="SDK Integration Guide" icon="plug" href="/en/rum/sdk/ios/sdk-integration">
    Learn how to integrate the SDK
  </Card>

  <Card title="Advanced Configuration" icon="sliders" href="/en/rum/sdk/ios/advanced-config">
    Learn about SDK advanced configuration options
  </Card>

  <Card title="Data Collection" icon="database" href="/en/rum/sdk/ios/data-collection">
    Learn what data the SDK collects
  </Card>

  <Card title="Compatibility" icon="check-circle" href="/en/rum/sdk/ios/compatible">
    Learn about supported platform versions
  </Card>
</CardGroup>