How to Get Android & iOS Device Logs (ADB Logcat, Xcode Console, Log Apps)

"Can you attach the logs?" is one of the most common follow-ups after a mobile bug report. A screenshot shows what happened; Android logs or iOS device logs show why. This guide covers how to get logs from an Android device (ADB logcat, system logger / app logs, and on-device log readers) and how to view device logs in Xcode or Console.app on iOS — then turn developer options back off when you are done.

Android: Enable Developer Mode Before Viewing Logs

Developer options are hidden by default on Android, so the first step on any device is unlocking them before you can pull Android app logs or system logs:

1. Open Settings → About phone (naming varies slightly by manufacturer, e.g. "About device").
2. Find Build number.
3. Tap Build number seven times in a row. You'll see a countdown toast ("You are now 4 steps away from being a developer...").
4. After the seventh tap, Android confirms: "You are now a developer!"
5. Go back to the main Settings screen — a new Developer options (or System → Developer options) menu is now visible.

Android: Enable USB Debugging for ADB Logs

Developer options being visible isn't enough on its own — USB debugging has to be switched on separately before ADB can see the device and stream Android ADB logs:

1. Open Settings → System → Developer options.
2. Toggle on USB debugging.
3. Confirm the "Allow USB debugging?" dialog.
4. Connect the device to your computer with a USB cable and select "Always allow from this computer" when the RSA key fingerprint prompt appears, so future connections don't re-prompt.

How to Check Android Device Logs with ADB (Logcat)

ADB (Android Debug Bridge) gives you the full, unfiltered Android system log — the same stream developers use for crashes, ANRs, and network failures. If you searched for "how to check Android logs," "Android log files," or "Android ADB logs," this is the primary method.

Installing ADB (Windows, macOS, Linux)

Once ADB is installed and the device is connected, confirm it's detected:

adb devices
# Expect output like:
# List of devices attached
# R58N30ABCDE    device

With the device authorized, capture the Android application log / device log to a file, reproduce the bug, then stop the capture:

# Clear any stale buffered log lines first (optional but recommended)
adb logcat -c

# Start capturing Android logs to a file
adb logcat > logs.txt

# ...reproduce the bug on the device now...

# Press Ctrl+C in the terminal to stop capturing

Attach logs.txt (your Android log file) to the bug report along with steps, timestamp, and app version. To focus on one app's package instead of the entire system logger output:

# Filter to a single app by package name
adb logcat --pid=$(adb shell pidof -s com.example.app) > app-only-logs.txt

Android Log Viewer Apps (When You Have No PC)

When a computer isn't available — field testing, a client's phone, or a bug that only reproduces away from a desk — an Android log reader / log tool on the device can replace ADB. Two I've used reliably:

• MatLog Libre — open-source Android log viewer; filters by tag/priority and exports a shareable text log file.
• Logcat Reader — lightweight viewer with search and save-to-file, once it can read the full device log.

The catch: since Android 4.1, apps can only read their own log output by default. To let either app show the full Android system logs, grant READ_LOGS once — via adb shell pm grant <package> android.permission.READ_LOGS from a computer, or root on the device. That one-time grant is the only PC step; after it's done, the app captures logs on its own.

Android: Disable Developer Mode After Capturing Logs

Once the investigation is closed, turn Developer options back off — leaving USB debugging enabled long-term is an unnecessary attack surface, especially on shared or client-owned hardware.

1. Open Settings → System → Developer options.
2. Toggle Developer options off (or toggle USB debugging off individually if you want to keep other developer settings).
3. Confirm if prompted.

How to View iOS Device Logs in Xcode

iOS doesn't expose an ADB-style debug toggle, but Apple's tooling gives QA a live log stream — no jailbreak required. If you searched for "iOS device logs" or "Xcode view device logs," start here.

Xcode Devices & Simulators console (recommended)

1. Connect the iPhone/iPad to a Mac with a cable (or pair over Wi-Fi if already configured) and trust the computer on the device if prompted.
2. Open Xcode → Window → Devices and Simulators.
3. Select the connected device in the left sidebar.
4. Click Open Console at the bottom of the window — this streams the device's live unified log (same idea as Android console log / logcat).
5. Use the search/filter bar to narrow by process name (your app's binary) before reproducing the issue, then reproduce the bug and copy or export the relevant lines.

Console.app with the device selected

macOS's built-in Console.app (Applications → Utilities → Console) can also target a connected iOS device directly from its sidebar, without opening Xcode at all. It's the same unified log, useful when you just need a quick read without a full Xcode install, or want to run a sysdiagnose (Console.app → device menu → "Collect sysdiagnose from device") for a deeper diagnostic bundle.

Command-line via libimobiledevice

For a lighter-weight, scriptable capture (useful in CI or when Xcode isn't installed), idevicesyslog from the open-source libimobiledevice project streams the same device log to a terminal:

# macOS install
brew install libimobiledevice

# Stream the connected device's log to a file
idevicesyslog > ios-logs.txt

# ...reproduce the bug...
# Press Ctrl+C to stop

TestFlight builds

For issues that only reproduce on a TestFlight build away from a Mac, ask the tester to send feedback with a screenshot from within TestFlight (shake the device or use the TestFlight app's "Send Beta Feedback") — this bundles recent diagnostic logs automatically and lands directly in App Store Connect for the build, without needing a cable at all.

Android vs iOS Device Logs: Quick Reference

Whichever platform you're on, the habit that matters most is capturing the log while the bug is reproduced — not after. Start the capture, note the timestamp, reproduce the issue, then stop and attach. That single discipline turns a vague "it crashed" report into something a developer can actually trace.