Capturing device logs on iOS and Android

The app closes itself on a Pixel 8 the moment you tap Pay. You reopen it, try again, and it happens twice more. You write a clear ticket with steps and a screenshot of the home screen, because there was nothing else to screenshot.

The developer replies asking for the log. By then you have used the phone for two hours and the log is gone, overwritten by everything that happened since.

Device logs expire. Capturing them is a habit you build before you need them.

Short version

• A device log is a running text record of what the operating system and apps report.
• Logs sit in a small rolling buffer, so old lines vanish. Capture soon after the bug.
• On Android, use adb logcat from a computer, or Take bug report on the device.
• On iOS, use the Console app on a Mac, or Analytics Data in Settings for crash files.
• Attach a trimmed extract plus the full file, and redact tokens before you upload.

---

What a device log is

A device log is a stream of text lines written by the operating system and by every app on it. Each line has a timestamp, a source, a severity level, and a message.

Levels run from Verbose and Debug at the noisy end to Error and Fatal at the useful end. A crash usually produces a stack trace, which is a list of the function calls that were running when the failure happened, read from the top down.

Two facts drive everything else in this guide. The buffer is small, so lines are dropped as new ones arrive. And the log is device-wide, so your app's lines sit among thousands from unrelated services.

Android: logcat from a computer

adb is the Android Debug Bridge, a command-line tool that talks to a connected device. It comes with Android Studio, or as part of the standalone platform tools package.

First, turn on USB debugging on the phone:

1. Open Settings, then About phone.
2. Tap Build number seven times. You will see "You are now a developer".
3. Go back to Settings, then System, then Developer options.
4. Turn on USB debugging.
5. Connect the cable and accept the "Allow USB debugging?" prompt on the phone.

Then capture:

adb devices                      # confirm the phone is listed
adb logcat -c                    # clear the buffer, so you start clean
adb logcat > device-log.txt      # start recording, leave this running

Now reproduce the bug on the phone. When it happens, note the time, go back to the terminal, and press Ctrl+C to stop.

Four variations worth memorising:

# Only your app's lines
adb logcat --pid=$(adb shell pidof -s com.example.app)

# Only errors and worse
adb logcat *:E

# The last 500 lines already in the buffer, then exit
adb logcat -d -t 500

# The dedicated crash buffer
adb logcat -b crash

If your app is very chatty and lines are being dropped, grow the buffer before you start:

adb logcat -G 16M

Android: a bug report with no computer

Android can produce a full report on the device itself. It is large, but it contains the log, running processes, battery state, and more.

1. In Developer options, tap Take bug report.
2. Choose Interactive report and reproduce the bug when prompted.
3. When the notification appears, tap it and share the file to your ticket, email, or drive.

From a computer the same thing is one command:

adb bugreport bugreport.zip

Use this when a developer asks for "the full bug report". Use plain logcat for everyday tickets, because a bug report zip is often tens of megabytes and nobody reads it casually.

iOS: the Console app on a Mac

Apple's Console app streams live logs from a connected iPhone or iPad.

1. Connect the device by cable and unlock it. Tap Trust if asked.
2. Open Console on the Mac. You will find it in Applications, then Utilities.
3. Select the device by name in the left sidebar, under Devices.
4. Click Start streaming.
5. Type your app or process name in the search box at the top right to filter.
6. Reproduce the bug.
7. Select the relevant lines, then use File, then Save Selection As to write a text file.

Two Console habits save time. Click Pause as soon as the bug happens, because the stream moves fast. And add a filter for your bundle identifier, for example com.example.app, rather than filtering by free text, which matches unrelated lines.

Xcode has a second view worth knowing. Open Window, then Devices and Simulators, select the device, and click View Device Logs. This shows crash reports specifically, including ones from before you connected.

iOS: Analytics Data with no Mac

Every iPhone stores its own crash files, and you can get them without any computer.

1. Open Settings, then Privacy & Security.
2. Tap Analytics & Improvements, then Analytics Data.
3. Scroll to files named after the app, for example MyApp-2026-05-17-101432.ips.
4. Tap the file, then the share button, and send it to yourself or attach it to the ticket.

The list is alphabetical and long, so search by the app name. The date in the filename is your friend: match it to the time the crash happened, and ignore everything else.

For deeper problems a developer may ask for a sysdiagnose, a full system snapshot triggered by holding both volume buttons and the side button for about a second and a half. Expect a file of several hundred megabytes and only produce one when asked.

Mobile web: a different set of tools

If the bug is in a website rather than a native app, device logs are the wrong place to look. Use remote debugging instead.

• iOS Safari. Turn on Web Inspector in Settings, then Safari, then Advanced. Connect to a Mac and open Safari's Develop menu.
• Android Chrome. Connect the phone, then open chrome://inspect in desktop Chrome.

Both give you the normal console and network tabs for the phone's page. When a cable is not available, an in-page reporting tool such as Crosscheck captures the console output, network requests, and environment details from inside the mobile browser itself, which covers the common case of a tester on a phone with no laptop nearby.

What to attach, and what to trim

A 40 MB log file with no pointer to the failure is close to useless. So is a five-line extract with no context. Send both, shaped like this.

A good extract starts about thirty seconds before the failure and ends a few lines after it. The lines just before the crash are usually the ones that explain it.

Write the pointer in the ticket itself:

Crash on tap of Pay, 17 May 2026 at 10:14:32 UTC. Pixel 8, Android 15, app 4.2.0 build 318, account [email protected]. Full log attached as device-log.txt. The relevant part starts at line 2,184: FATAL EXCEPTION: main ... java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String com.example.Order.getCurrency()' on a null object reference

Redact before you upload

Device logs record real data. Before attaching one, search it for these and replace the values:

• Authorization, Bearer, token, session, apiKey
• Email addresses and phone numbers
• Card numbers, addresses, and anything a user typed

Search once for each term. It takes a minute and prevents a live token ending up in a ticket that dozens of people can read. If your ticket system is public or shared with contractors, treat this as mandatory rather than optional.

A useful habit: test with dedicated accounts such as [email protected] and fake payment details, so a leaked log is boring rather than dangerous.

Frequently asked questions

Why is my log empty or missing the crash?

The buffer overwrote it. Logs hold only a few megabytes, so capture within minutes of the failure and run adb logcat -c before reproducing, so the buffer starts clean.

Do I need a Mac to get iOS logs?

For live streaming, yes. For crash files, no. Analytics Data in Settings gives you the .ips crash files directly from the phone, and those cover most crash tickets.

Can I capture Android logs without USB debugging?

Only through Take bug report in Developer options, which still needs Developer options enabled. Without it, you are limited to whatever crash reporting the app itself sends.

What is the difference between logcat and a bug report?

Logcat is the running text log. A bug report is a zip containing logcat plus system state such as processes, memory, and battery. Send logcat by default and a bug report on request.

Should testers attach logs to every ticket?

No. Attach them for crashes, freezes, and anything you cannot see in the interface. For a layout or wording bug, a screenshot is better evidence and far easier to review.