Can’t reproduce device bugs? 5 fixes for mobile teams

A tester files a bug: checkout freezes on one phone, one OS version, every time. A developer picks it up, runs the same flow on a different device, and nothing happens. The ticket goes back with “cannot reproduce.” Two days later, a customer hits the same freeze in production.

I’ve watched this loop play out on enough mobile teams to have a firm opinion. If you can’t reproduce a bug on the exact device, OS version, and build configuration where it appeared, you can’t fix it with confidence. You can only guess and hope.

This post is a workflow, not a vendor pitch. It ends with an evidence bundle you can attach to any ticket and a way to pick the devices worth testing.

Why device-specific bugs vanish before release

Two gaps cause most of the disappearing acts.

The release build gap is the difference between what developers run and what users install: Debug versus Release configurations, fresh installs versus updates, permissions state, and network conditions.

The device gap is everything about the hardware and OS: model, OS version, memory pressure, battery mode, radios.

A bug usually lives in the overlap of the two. That’s why it disappears when someone changes either variable without realizing it.

Step 1: Treat reproduction like a build problem

Before blaming a device, confirm you’re testing the build users get. Apple’s developer documentation on testing a release build recommends creating an Xcode archive and testing both a fresh install and an app update before distribution. It also notes that debugger configuration can change behavior, so disconnect the debugger when testing the release build.

A practical sequence:

1. Archive the Release build and record the exact build number.
2. Compare Release and Debug settings (optimization levels, logging, feature flags, backend endpoints).
3. Test a fresh install, then an update from the previous production version.
4. Only then move to different devices and OS versions.

Release-only bugs tend to cluster around the same places. Check these first:

• Background behavior and tasks the OS terminates (watchdog timeouts)
• Low Power Mode, battery saver, and data saver settings
• Memory pressure after the app has been backgrounded for a while
• Permission prompts answered differently on update versus fresh install
• Locale and region settings that change formatting or flows

The same discipline applies on Android: test the signed release variant, with minification and shrinking enabled, not the debug APK.

Step 2: Capture the same evidence every time

Most “cannot reproduce” tickets fail because the report contains a description instead of proof. Cloud device platforms converged on the same answer. Sauce Labs documents real-device debugging around session video and application, device, and Appium logs. Firebase Test Lab captures logs and results and can record video during test runs.

Make this your minimum evidence bundle:

• Build variant and number (Release, Debug, update path)
• Exact device model and OS version
• Screen video of the failing session
• App logs and device logs from the same timestamps
• A network trace (HAR file) when the failure involves an API call
• Steps to replay the scenario on other devices

This also ends the “is it my app, or your rig?” argument. When QA hands over video, logs, and device details together, developers can see whether the failure comes from the app, the environment, or the test setup. In Kobiton’s Session Explorer, sessions can be replayed so the team can pinpoint where a defect occurred, and one-click Jira filing attaches logs and device context to the ticket automatically.

Step 3: Pick a focused device matrix, not a bigger one

The instinct when a device bug escapes is to add more devices. Resist it. Android fragmentation is real: OpenSignal’s 2015 fragmentation report counted 24,093 distinct Android devices from about 1,300 manufacturers in its data. The number has not shrunk since. You will never cover everything, so cover what matters.

Build the matrix from your own data:

• Top device models by sessions in your analytics
• OS versions with meaningful active users, including the laggards
• Crash analytics hits: any device model and OS version combination that shows up in crash reports
• The bug signature: the exact combination from the ticket, plus its nearest neighbors (same OS, different model, and vice versa)

Review it every release. The phone your app breaks on is usually the one nobody on the team owns, which is the argument for real device cloud testing over a shelf of hand-me-down handsets. Platforms like AWS Device Farm, Firebase Test Lab (which can list available Android models with

), and Kobiton all give you access to devices you don’t have to buy. Teams with strict security needs should also check deployment options, since Kobiton offers cloud, Hybrid, and Full On-Prem models.

Step 4: Debug the failure mode, not the symptom

Once you can reproduce, look at what the evidence says:

• UI element missing or unresponsive: check the video for a hidden overlay or permission dialog, then check the selector and screen state in the logs.
• Freeze, crash, or ANR: look at memory and CPU around the failure. Device metrics such as CPU, memory, battery, and temperature help here.
• Works on update, fails on fresh install (or reverse): compare permissions and stored state.
• Fails only on certain networks: replay with the HAR file and compare response timing and payloads.
• Fails only with accessibility or locale settings: repeat the session with those settings changed, one at a time.

Change one variable per run. That’s slow for the first hour and fast for every hour after.

Step 5: Turn the reproduction into a replayable test

A bug you reproduced manually and then forgot is a bug you’ll fix twice. Convert the successful path into automation while the steps are fresh. Kobiton’s Appium Script Generation produces Appium scripts from recorded manual sessions, which you can run across your device matrix and wire into CI/CD (Jenkins is supported). Appium Self-Healing helps keep those scripts from breaking when locators change. For teams new to this, our guide to Android UI testing in CI/CD shows how real-device runs fit into a pipeline.

Whatever tool you use, the principle holds: every escaped device bug should leave behind a regression test.

What to do before your next release

• Test the Release build, on fresh install and update paths
• Attach a full evidence bundle to every device-specific ticket
• Build the device matrix from analytics and crash data
• Debug by failure mode, changing one variable at a time
• Automate every reproduced bug so it stays fixed

I’m curious which artifact your team lacks most when reproduction fails: video, device logs, network traces, or the exact device? Whichever it is, fix that first. If you want to see how teams capture real-device evidence and replay it across devices, explore the Kobiton mobile device cloud.