Performance & footprint
Figures below were measured on Screeb iOS SDK v4.0.2 (2026-07-07) with a Release build, using a repeatable, versioned methodology. They cover two independent regimes: Core (surveys and in-app messages, what every integration gets by default) and Session Replay (screen recording, opt-in only — inactive unless the customer enables it, via the SDK API or server-side targeting).
Summary
| Metric | Core (surveys, default) | Session Replay (opt-in) |
|---|---|---|
| App size added | ~0.55 MB compressed (~1.9 MB uncompressed framework) | included above — ships in the same framework |
| Memory (RAM) | the SDK's rendering surface (a WKWebView) runs in iOS system WebKit processes, outside your app's own memory; the SDK's in-process footprint is small — no measurable app-process increase in our reference run | small in-process additions (capture buffer, tile cache) while actively recording |
| CPU | no measurable cost — the SDK is idle between events; survey rendering happens in the system WebKit processes | while actively recording a continuously-changing screen: on the order of 6% of one core in our reference run; far less on mostly-static screens; zero when not recording |
| Network | first session downloads the survey rendering bundle (~2 MB, shared web runtime, versioned and cacheable — not re-downloaded every session); event tracking is batched (near-zero incremental) | scales with how much the screen changes: ~1.3 MB/min of replay data under continuously-animating content in our reference run, near zero on static screens |
| On-device storage | none SDK-managed — no files, no databases, no UserDefaults; the WebView keeps a few KB of localStorage plus its standard HTTP cache | none beyond Core — replay frames are never written to disk |
App size
Adding the Screeb SDK to an iOS app adds about 0.55 MB compressed (the embedded framework is ~1.9 MB on disk before App Store thinning and compression). This single figure covers both Core and Session Replay, since they ship in the same framework — there's no separate "Session Replay module" to add on top. The exact App Store download delta depends on app thinning for each device model.
Memory
On iOS, the SDK renders surveys and in-app messages in a WKWebView, and WebKit runs its content, networking and GPU work in separate system processes managed by iOS — not inside your app's memory space. Your app's own memory footprint therefore stays close to what it would be without the SDK: in our reference measurement, the app-process memory difference between a build with the SDK and one without was within measurement noise. Session Replay adds modest in-process buffers (a capture bitmap and a tile cache) while a recording is active.
CPU
At rest, the SDK adds no measurable CPU cost — it is event-driven and idle between interactions, and survey rendering happens in the system WebKit processes. Session Replay does add CPU while it is actively recording, since it captures, diffs, and encodes screen content: in our reference run — which keeps the screen continuously changing (permanent scrolling and animating content) — that cost was on the order of 6% of one CPU core: capture is clipped to what actually changed, unchanged frames are skipped before any encoding work, and diffing runs off the main thread. On typical screens that are mostly static between interactions the cost is far lower, and it is exactly zero whenever replay is not recording — it is not part of the default footprint.
Network
A first survey session downloads the survey rendering bundle — the same versioned web runtime used across Screeb's SDKs, about 2 MB. It is served with standard HTTP caching, so it is not re-downloaded on every session — it only churns when the bundle version changes on our end. Event tracking is batched and adds close to zero incremental network usage.
Session Replay's network usage scales with how much the screen visually changes, because only changed regions are transmitted: a mostly static screen produces very little traffic, while continuously-animating content produces more. In our reference run — deliberately worst-case-leaning, with the screen changing continuously for the whole measurement window — replay generated about 1.3 MB of data per minute. Treat it as an upper band for very active content, not a fixed rate; typical sessions with intermittent interaction sit well below it. This traffic only exists while a recording is active and is separate from the Core session figure above.
Storage
The Screeb iOS SDK keeps no persistent storage of its own on the device: no files, no databases, no UserDefaults. The SDK's rendering surface (a WKWebView) persists a small amount of state via standard browser localStorage — a few kilobytes of session/client state — and maintains its own standard HTTP cache for the survey bundle, which is what enables the caching behavior described above; that cache is managed entirely by iOS/WebKit, not by the SDK. Session Replay never writes frames to disk.
Figures are measured on a single reference configuration with a repeatable scripted workload and represent a realistic baseline; exact numbers vary by device and iOS version. Session Replay is always opt-in — it has zero runtime footprint (CPU/memory/network) until it is started, either explicitly via the SDK API or when enabled through Screeb's server-side targeting configuration; its code is included in the SDK's binary size regardless.