iOS SDK Performance Impact

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.

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

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

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

Performance Impact Details

CPU Usage

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.

Memory Usage

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.

Launch Time

The SDK initialization process is optimized, with impact on application launch time controlled to sub-millisecond level.

It is recommended to initialize the SDK as early as possible in AppDelegate’s didFinishLaunchingWithOptions to capture the complete application startup process.

Package Size

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.

Network Usage

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

Performance Optimization Recommendations

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

Adjust the sample rate

Reduce the number of collected events by configuring the sample rate:

RUM.enable(
    with: RUM.Configuration(
        applicationID: "<RUM_APPLICATION_ID>",
        sessionSampleRate: 80 // sample 80% of sessions
    )
)

Enable only the features you need

Turn off the automatic tracking you do not analyze:

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%)
    )
)

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.

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.

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.

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:

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

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.

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.

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.

Offline Data Storage

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

Uses fixed-size disk cache
Expired data is automatically cleaned up
Cached data will not affect device storage space

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

SDK Integration Guide

Learn how to integrate the SDK

Advanced Configuration

Learn about SDK advanced configuration options

Data Collection

Learn what data the SDK collects

Compatibility

Learn about supported platform versions

Quick Start

Analytics

SDK Integration

Performance

Error Tracking

Explorer

Session Replay

Best Practices

Others

iOS SDK Performance Impact

Overview

Performance Benchmark

Test Results

Performance Impact Details

Performance Optimization Recommendations

Reducing the Impact of Uploads on Your Own Requests

Offline Data Storage

Battery Consumption

SDK Integration Guide

Advanced Configuration

Data Collection

Compatibility

​Overview

​Performance Benchmark

​Test Results

​Performance Impact Details

​Performance Optimization Recommendations

​Reducing the Impact of Uploads on Your Own Requests

​Offline Data Storage

​Battery Consumption

​Related Documentation

SDK Integration Guide

Advanced Configuration

Data Collection

Compatibility

Overview

Performance Benchmark

Test Results

Performance Impact Details

Performance Optimization Recommendations

Reducing the Impact of Uploads on Your Own Requests

Offline Data Storage

Battery Consumption

Related Documentation