Writing mobile bug reports: devices, crash IDs, and logs

A mobile bug report has the same skeleton as a web bug report: title, steps, expected, actual, evidence. But the details that matter are different, and the evidence is harder to reach.

On the web, the console is one keyboard shortcut away. On a phone, the equivalent information is buried in system settings, or needs a cable and a computer. This guide covers what to capture and where to find it.

Short version

Always include app version AND build number — they are different things.
The device model matters more than the brand.
For crashes, the crash log is the whole report. Learn where it lives.
Battery saver, low storage, and permissions cause a surprising share of mobile bugs.
Screen recordings are easier on mobile than on desktop — use them.

The mobile environment section

App version and build number

Every mobile app has two numbers:

Version — the marketing number users see, like 3.9.1
Build — the internal counter that changes with every single build, like 4412

Two testers can both be "on 3.9.1" and be running different code, because they installed different builds. Always include both:

App: 3.9.1 (build 4412), installed via TestFlight

Also say how the app was installed — App Store, TestFlight, Play Store, internal testing track, or a direct APK. Different tracks often carry different code and different feature flags.

Device model, not just brand

"Samsung phone" covers thousands of devices with different screens, memory, and Android versions. Be exact:

Device: Samsung Galaxy S24 (SM-S921B) OS: Android 15, One UI 7.0

On iOS:

Device: iPhone 14 (not Pro/Plus) OS: iOS 18.2

Find the model in Settings → About phone (Android) or Settings → General → About (iOS).

The conditions people forget

These cause real bugs and almost never make it into reports:

Battery saver mode — throttles background work; breaks sync and timers
Low storage — breaks downloads, caching, and photo capture
Permissions — camera, location, notifications: granted, denied, or "ask every time"?
Network type — WiFi, 5G, 4G, or offline; and did it change during the test?
Dark mode — a common source of unreadable-text bugs
Font size and display zoom — system-level accessibility settings break layouts
Language and region — date formats, RTL layout, text length

You do not need all of these in every report. But when a bug is strange, run through this list — one of them is often the trigger.

Where to find crash logs

For a crash, the log is the most important attachment by far. A crash report with a log is usually fixable the same day. Without one, it may never be.

iOS

Open Settings → Privacy & Security → Analytics & Improvements → Analytics Data
Scroll the alphabetical list to your app's name
Files are named like MyApp-2026-08-07-160422.ips
Tap one, then use the share icon to send it

If the tester's device is synced with a Mac, logs also appear in the Console app under Crash Reports.

For TestFlight builds, crashes are also collected automatically in App Store Connect, and users can send feedback with a screenshot directly from TestFlight by taking a screenshot and tapping "Share Beta Feedback".

Android

The simplest route needs a computer and a cable:

Enable Developer Options (tap Build Number seven times in Settings → About phone)
Enable USB debugging
Connect to a computer with adb installed
Run adb logcat -b crash to see only crash output, or adb bugreport for a full report

If a cable is not practical, most teams rely on a crash reporting SDK instead — Crashlytics, Sentry, or similar. In that case the report needs the crash ID or the exact time, so the developer can find the right entry in the dashboard.

The crash ID shortcut

If your app uses a crash reporting tool, the ideal report is short:

App crashed on Photo Gallery when scrolling fast. Time: 07 Aug 2026, 16:04:22 UTC+5 Crashlytics issue: appears as PhotoGridCell.imageDidLoad — link attached Device: iPhone 14, iOS 18.2, build 4412

The timestamp plus the device is enough for a developer to find the full stack trace in the dashboard. This is why writing down the exact time matters so much on mobile.

Screen recordings on mobile

Both platforms have built-in recording, and it is the easiest evidence to produce:

iOS: add Screen Recording to Control Centre (Settings → Control Centre), then swipe down and tap the record button
Android: Screen Record lives in the Quick Settings tiles

Keep recordings under a minute, and show the whole flow from a known starting point. For touch bugs, enable "Show taps" (Android: Developer Options → Show taps; iOS records touches in some tools but not natively — narrate with slow, deliberate gestures instead).

One habit worth building: record before you expect a bug when testing a risky area. Deleting an unneeded recording costs nothing; failing to capture a rare bug costs a lot.

Steps to reproduce, mobile edition

The rules from web testing all apply — start from a known state, one action per step, exact labels, real data. Mobile adds a few of its own:

Name the gesture precisely. Tap, double-tap, long-press, swipe, pinch, and drag are different actions. "Click" is ambiguous on a touch screen.

Long-press the photo until the menu appears

Swipe left on the third item in the list

Describe app state transitions. Mobile bugs love the edges between states:

Backgrounding the app and returning
Receiving a call or notification mid-action
Rotating the device
Losing network mid-request
The system killing the app in the background and restoring it

If your bug involves any of these, spell it out as a numbered step: "3. Press the home button. 4. Wait 30 seconds. 5. Reopen the app from the app switcher."

Mention the keyboard. Software keyboards cover half the screen and cause layout bugs, focus bugs, and scroll bugs. Say whether the keyboard was open.

A complete mobile bug report

Title: App loses draft message when interrupted by a phone call — Android only

Environment App: 3.9.1 (build 4412), Play Store internal track Device: Samsung Galaxy S24, Android 15 Network: WiFi Account: [email protected] (Editor)

Steps

Open the app and go to any chat

Type a message of at least 20 characters — do not send

Receive a phone call (call the test device from another phone)

Answer the call, talk for ~10 seconds, hang up

Return to the app from the app switcher

Expected: The draft message is still in the input field. Actual: The input field is empty. The draft is gone.

Frequency: 5 of 5 on the S24. 0 of 5 on iPhone 14 (iOS keeps the draft).

Evidence: Screen recording attached. No crash — the app was restored, but with empty state.

Note: Does not happen if the call is declined instead of answered. Likely related to the app being killed while backgrounded, since Android restored the activity but not the text.

Note the comparison across platforms and the declined-call variation — each took a minute to test and each narrows the cause significantly.

Web views: the hybrid case

Many mobile apps show web content inside the app. Bugs there are really web bugs wearing a mobile costume, and they need web evidence — console output and network activity.

Android: open chrome://inspect in desktop Chrome with the device connected, and you can attach full DevTools to the app's web view
iOS: enable Web Inspector (Settings → Safari → Advanced) and inspect from desktop Safari's Develop menu

If your product is a web app that users also open on phones, the same evidence problem applies in the mobile browser — and capturing console and network data there is harder than on desktop. This is a case where an in-page reporting tool such as Crosscheck earns its place, since it collects that evidence from inside the page itself, without DevTools or a cable.

Frequently asked questions

Do I need to test on real devices, or are emulators enough? Emulators catch most functional bugs and are fine for day-to-day reporting. Real devices are needed for anything involving performance, camera, sensors, calls, notifications, or touch feel. Report which one you used.

How many devices should a bug report cover? One is enough to file. Two is much better — knowing a bug is "S24 only" or "all Android" changes where the developer looks. Test the second device if you have one within reach.

What is a symbolicated crash log? Raw crash logs show memory addresses instead of function names. Symbolication translates them using files produced at build time. As a tester you just need to attach the raw log — the team's tooling handles translation, as long as someone uploaded the symbol files.

The bug only happens on a device I do not have. What now? Report what the user gave you, clearly marked as second-hand, with their device model and app build. Then check the crash dashboard for entries matching that device and time.

Should mobile bug reports go in a different tracker? No — same tracker, same format, different evidence. Splitting trackers by platform makes duplicate bugs invisible.