Performance & footprint
Figures below were measured on Screeb iOS SDK v4.0.4 (2026-08-20) on a physical iPhone 17 Pro (iOS 26.6) 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.33 MB compressed (~1.07 MB uncompressed framework, arm64 device slice) | 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; in your app's own process the SDK adds about 4 MB | about 3 to 4 MB more while actively recording (capture buffer, tile cache), with short peaks higher while a full frame is encoded |
| CPU | ~0.1% of one core: 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 12% of one core in our reference run; far less on mostly-static screens; zero when not recording |
| App frame rate | no measurable impact | the recorder's main-thread budget is capped by design and follows the display's refresh rate: on ProMotion (120 Hz) screens captures are placed in the frame's idle tail and spaced so they never displace the app's tighter frame budget; in our bench the app's median frame time stays at 16.7 ms in every phase while recording |
| Network | first session downloads the survey rendering bundle (~2 MB, shared web runtime, versioned and cacheable, so it is not re-downloaded every session); event tracking is batched (near-zero incremental) | scales with how much the screen changes: ~1.5 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.33 MB compressed (the embedded framework is ~1.07 MB on disk for the arm64 device slice, before App Store thinning and compression). This single figure covers both Core and Session Replay, since they ship in the same framework; there is 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 modest: in our reference measurement on a physical iPhone, the SDK added about 4 MB to the app process (measured as phys_footprint, the figure iOS itself uses when deciding which apps to reclaim). Session Replay adds about 3 to 4 MB more while a recording is active, a capture bitmap and a tile cache, with short peaks above that while a full frame is being encoded.
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 adds CPU only while it is actively recording, and the cost follows how much the screen actually changes:
| Screen activity while recording | CPU (reference device) |
|---|---|
| Continuously changing (permanent scrolling and full-screen animation, our reference run) | on a 120 Hz (ProMotion) device: ~6% of one core, because the recorder spaces captures to respect the tighter 8.3 ms frame budget; on 60 Hz hardware it allows a faster cadence, up to the order of 12% of one core |
| Localized but permanent change (a ticking widget) | ~5 to 8% of one core |
| Occasional interaction, static in between | ~2 to 3% of one core (heartbeat checks) |
| Not recording | exactly zero |
Two properties keep that cost bounded rather than incidental. First, the recorder's main-thread budget is capped by design: capture frequency is bounded to a small share of your app's frame budget, and diffing, encoding and transmission all run off the main thread. In our bench the app's median frame time stays at 16.7 ms (60 fps) in every phase while recording; only the p95 moves, and only under continuous full-screen animation. Second, unchanged frames are skipped before any encoding work, so a quiet screen costs almost nothing.
The recorder also adapts to the device's real conditions, not just to screen activity. It reads the display's maximum refresh rate: on ProMotion (120 Hz) screens the per-frame budget is halved, so captures are scheduled in the frame's idle tail and spaced further apart, always favoring the host app's fluidity. Under thermal pressure, Low Power Mode or memory pressure it reduces its work (quality and resolution first, cadence last; see Session Replay battery usage). The figures above are the envelope measured on a cool device; the same protocol on a heat-soaked phone measured lower CPU still, because the recorder follows the content's real pace instead of insisting on a fixed rate.
Network
A first survey session downloads the survey rendering bundle, the same versioned web runtime used across Screeb's SDKs, about 2 MB (measured on Android, where the WebView traffic is attributable per app; iOS downloads the same versioned bundle). 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:
| Screen activity while recording | Replay traffic (reference device) |
|---|---|
| Continuously changing (our reference run, deliberately worst-case-leaning) | about 0.9 MB per minute on the 120 Hz reference device (its capture cadence is spaced by design); up to about 1.5 MB per minute where the display allows a faster cadence |
| Localized change (a ticking widget) | ~0.3 MB per minute |
| Static between interactions | ~0.05 MB per minute |
| Not recording | none |
Treat the top row as an upper band for very active content, not a fixed rate; typical sessions with intermittent interaction sit well below it, and the adaptive behavior described in the CPU section lowers it further on constrained devices. 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 device (iPhone 17 Pro, iOS 26.6) 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.