Why UXCam has one of the best performing SDKs on the market

UXCam's SDK Performance at a glance

Here is what the SDK costs on a low-end Android device, before we get into how each number was measured.

• App size grows by about 0.6 MB, roughly 1% of ta typical app.

• Cold start adds about 90 ms. Warm and hot starts change by under 10 ms.

• Recording uses about 6 MB of heap.

• Screen capture runs about once every two seconds, off the main thread.

Android UXCam SDK 3.10.7, Galaxy M11 (worst-case low-end). iOS measured on iPhone 16 Pro, iOS 26 — see the iOS section below.

For the readers who want it in one place, here is the full spec on the low-end test device.

What an SDK is, and why its performance matters

An SDK, or software development kit, is a downloadable set of tools developers use to create applications on specific platforms. At its core, an SDK is a code snippet that someone else wrote so you can perform a function in your mobile app. The beauty of such a kit is that a developer doesn’t have to build all the functions of a mobile app from scratch. The kit can include libraries, documentation, code samples, processes, and guides that developers can use to integrate into their own apps. 

In this case, instead of writing session recording, screen capture, and secure upload from scratch, you install the UXCam SDK and get all of it.

Why a Low-Risk High-Performance SDK Matters

The reason performance matters is that every SDK runs inside your process, on your threads, against your frame budget.

A high-risk, poor-performing SDK can result in:

• Slower launches

• Bugs on the app (dropped frames while scrolling...)

• Higher memory use

• More crashes

• Worse battery life

• Reduced functionality

And the worst thing is, your users read all of that as your app being slow, not the vendor's. A misbehaving SDK can also put your store listing at risk, cause ANRs, or bloat your APK, and any of those lands on your team, not the vendor's.

So the right question to ask any analytics vendor is simple. What does adding your SDK cost, and can you show me?

Why UXCam's SDK is built for mobile performance

UXCam's numbers come out well because the SDK was designed for the constraints it runs in. A few things set it apart:

• It is mobile-native. UXCam has built for mobile since 2014, so the capture pipeline, occlusion, and upload queue were designed for phones, not ported from a web recorder.

• A dedicated SDK team maintains it full-time, across native and cross-platform frameworks.

• It covers the stacks teams actually ship on, including iOS, Android, React Native, Flutter, NativeScript, Cordova/Ionic, and .NET MAUI.

• It is quick to integrate, which keeps the risk of a bad install low.

None of this is a performance claim on its own. It is why the measurements below read the way they do.

UXCam was featured as one of the top 80 SDKs on the Google SDK Index, a directory that helps developers choose the best apps for their platform. SDKs featured on this list are reliable and trusted by the mobile app developer community.

How we measured UXCam's SDK impact

We measure the SDK in depth on a worst-case low-end Android device — if the cost is acceptable there, it is smaller on the hardware most users carry — then confirm it holds on a current iPhone in the iOS section below.

We built a benchmark setup that cold-launches the app, drives a fixed scroll over a 60-row list, and records the same run twice; once with the SDK absent, once with it installed and recording. Frame timings come from the platform frame metrics (frameDurationCpuMs), startup from time-to-initial-display, and thread and garbage-collection behavior from 76 Perfetto traces.

We decided to report medians and not means. Cold start on a CPU that is not frequency-locked is noisy. Across 10 runs, one cold launch came in at 1729 ms while the rest sat between about 1050 and 1250 ms, so a mean would misrepresent the typical launch.

We name the device on purpose. The same SDK behaves differently on a Pixel 9 than on a Galaxy M11, so a benchmark without a stated device is not a benchmark. We picked the M11, a low-end 2020 phone, because it is close to a worst case; overhead that is acceptable here is smaller on the mid-range and flagship hardware most users carry.

We also ran the same benchmark on a current flagship, an iPhone 16 Pro on iOS 26, to show the other end of the range; those results are in the iOS section below.

App size: UXCam adds about 0.6 MB

UXCam adds about 0.6 MB to a release build. Here is the breakdown from the benchmark:

• Test app without UXCam: 2.2 MB

• Test app with UXCam: 2.8 MB

• Added by the SDK: 0.6 MB

App size measured on Android SDK 3.8.12; the SDK footprint is stable across recent releases. On iOS the SDK adds roughly 1.3 MB (compressed estimate); see the iOS section.

The percentage depends on what you drop it into. On the 2.2 MB test stub, 0.6 MB reads as a 27% jump, which is why that figure is misleading on its own. On a 40 to 60 MB app, typical on Android, the same 0.6 MB is about 1%. That is why we lead with the absolute number.

App launch stays fast

Cold start is where SDK initialization shows up. With UXCam recording it moved from about 969 ms to 1058 ms, roughly 90 ms. Warm start went from 168 ms to 176 ms, hot start from 110 ms to 113 ms; effectively unchanged.

Initialization runs on the SDK's own threads, so it does not block the main thread while your app finishes launching. The 90 ms is concurrent work, not a stall the user waits through. The with-UXCam cold figure has also held steady across 3.9.0, 3.10.0, and 3.10.7, so it is not drifting upward release to release.

CPU stays inside the frame budget

During the benchmark we did not see UXCam push normal UI work past the 16.7 ms frame budget. Screen capture is the exception. It does real work, but that work runs off the main thread and fires roughly once every two seconds at the default capture rate.

One capture costs about 80 ms of background-thread work to grab, occlude, and transform the screen, plus about 18 ms to encode it. The main thread only takes a brief hop to hand off the frame. Perfetto showed the SDK using a small fixed pool of worker threads for this and reusing them, with no runaway thread growth or GC pauses over a session.

Push it harder than production ever would, continuous scroll on the M11 with capture forced well above the default rate, and the frames that coincide with a capture run long. That is a stress configuration, not a shipping one. At the default rate, and on mid-range or flagship hardware, we did not see it surface. The full per-frame percentiles are in the benchmark data if your team wants them.

Memory stays low and does not leak

While recording, heap peak moved from about 7.6 MB to 13.5 MB and resident memory (RSS) from about 25 MB to 38 MB, so recording costs roughly 6 MB of heap on this device.

Android SDK 3.10.7, session peak, median.

More to the point, the heap did not keep climbing over the session. In our runs it rose to the overhead above and then plateaued, which is the behavior you want from a recorder; a bounded working set rather than a slow leak. The same peaks held across 3.9.0, 3.10.0, and 3.10.7.

iOS: the same result on a current iPhone

The Android numbers above are a deliberate worst case: a low-end phone from 2020. To see the other end of the range, we ran the same benchmark on a current flagship — an iPhone 16 Pro on iOS 26 — across all ten workload screens, three iterations each. On that hardware, the SDK's overhead barely registers.

Average CPU across all ten screens moved from 1.44% to 1.51%, a change small enough to sit inside normal run-to-run noise. Peak memory rose by about 1.3 MB while recording, and frame rate was unchanged screen by screen. The iOS overhead reads lighter than the Android numbers above, but most of that gap is the device: a 2024 flagship has far more headroom than a low-end 2020 phone, so the fair reading is that these two runs bracket the range rather than that one platform is cheaper than the other.

On app size, the 0.32 MB baseline is a bare demo app, so reading the increase as a ratio overstates it; what carries over to a real app is the absolute increase of about 1.3 MB, which is why we lead with that number. The figure is an on-device compressed-package estimate rather than an App Store thinning report, so the final download size an end user sees depends on Apple's app thinning.

Built to fail safe

Recording is designed to never take the host app down with it.

UXCam's capture, encoding, and upload work is isolated on its own threads and wrapped so that if anything goes wrong inside the SDK, it stops recording rather than crashing your app. The SDK does not sit on the critical path of your UI, so a problem in capture shows up as a missing session, not a crash your users see.

That isolation is why UXCam runs across regulated finance, retail, and telecom apps that put every dependency through crash and stability review before it ships.

How UXCam keeps the SDK light

The numbers above are the result of a handful of deliberate engineering choices.

The ones that matter most:

• Screen capture uses PixelCopy where available and runs its heavy work on a background thread, so the main thread only takes a brief hop.

• Capture is throttled to about one frame every two seconds by default, which keeps the CPU cost rare.

• Occlusion happens at capture time, on the device, so masking sensitive content is part of the capture work rather than an extra pass.

• Uploads are batched and offline-friendly, queued locally and sent when the app backgrounds or a connection returns.

How UXCam compares to other mobile analytics SDKs

Most analytics and experience tools were built for the web first, or treat mobile session replay as a bolt-on. UXCam is mobile-native, records full session replay on real native views, and publishes what that costs. When you line up the numbers vendors put in their own public docs, UXCam has the smallest published app-size footprint of any mobile session-replay SDK.

Competitor figures are taken from each vendor's own public documentation, dated where the vendor dates them. Not every vendor publishes its mobile SDK size. We only included vendors with official, publicly available figures, so not every company appears in the table.

Two caveats sit under that table. App-size numbers are not measured identically across vendors, so read them as each vendor's own figure rather than one controlled test. And several tools here are built for web analytics or product analytics, not mobile session replay, which is a different job. On the numbers each vendor publishes, UXCam has the smallest app-size footprint of the session-replay tools listed, and it publishes more about its runtime impact than most of them.

How UXCam protects your users' data

Privacy is handled on the device, at capture time. Anything sensitive, whether individual text fields, a section of a screen, or an entire screen like a payment page, is occluded before the frame becomes video. The sensitive pixels are never rendered into the recording and never leave the device.

You control what gets masked:

• Hide specific text, for fields that hold personal data

• Hide a view, for a section of a screen

• Hide a whole screen, for pages like checkout or account settings

UXCam is GDPR-compliant, and because occlusion happens before upload, the guarantee does not depend on deleting anything server-side. Sensitive content simply never reaches us.

Platforms and frameworks UXCam supports

UXCam covers native and cross-platform stacks from a single core SDK, including iOS, Android, React Native, Flutter, NativeScript, Cordova/Ionic, and .NET MAUI. Jetpack Compose on Android is supported by the main SDK, and SwiftUI on iOS is supported through a dedicated SwiftUI SDK.

Integration is quick. A basic install, importing the SDK, creating the configuration object, and starting it, takes a few minutes, and a full setup with custom events and occlusion is usually about 30 minutes.

Frequently asked questions about UXCam's SDK

Ship it with confidence

UXCam records full mobile session replay for about 0.6 MB of app size, roughly 90 ms of concurrent cold-start work, and about 6 MB of memory, on a stack built for mobile since 2014. The numbers are above, and the full benchmark data is available if your team wants to go deeper.

If you want to see it against your own app, start for free or request a demo.