Console.app: what it is, features and how to read logs in macOS

What is Console.app

Console.app is a graphical interface to Apple's unified logging system. It replaced the old Console application (as part of macOS) and provides access to all system and application logs written through the os_log, os_trace, and syslog APIs. Console.app is located in /Applications/Utilities/ on any Mac.

Unlike Xcode, which only shows logs for the application launched from the IDE, Console.app displays logs from all processes on the system simultaneously. This allows you to diagnose problems that only occur when the application is launched outside Xcode or in the background. Console.app also shows system logs — kernel, launchd, WindowServer — which is useful for debugging low-level issues.

Console.app does not require installing additional tools or an internet connection. All data is stored locally in a .tracev3 database, and the application works completely offline. To view logs from another Mac or iOS device, use the log collect command and then open the .logarchive in Console.app.

Console.app Interface

The Console.app interface consists of three main areas: the sidebar with filters, the message table, and the detail panel for the selected message. The sidebar contains the Devices section (available log sources), Reports (system crash reports), and Saved Searches (saved search queries).

The message table displays a list of logs with columns: Time (timestamp), Category (category), Level (severity level — color-coded), Process (process name), Message (message text). Clicking any message opens the detail panel showing the subsystem, activity identifier, thread ID, and the full formatted text.

Console.app highlights messages by color: red for Fault, yellow for Error, blue for Debug, gray for Info. Default messages are not highlighted. This lets you visually scan the log stream and instantly notice critical events.

// Logs that will appear in Console.app
import OSLog

let logger = Logger(
    subsystem: "com.example.myapp",
    category: "network"
)

logger.error("Connection failed: timeout")
logger.debug("Retry attempt 3 of 5")

// These messages are visible in Console.app with the filter "myapp"

Filters and Search in Console.app

Filtering is the main feature of Console.app, turning a stream of thousands of messages per second into a readable list. The search field at the top supports AND conditions: multiple words separated by a space show only messages containing all the words. For example, myapp error shows all logs of the myapp application with the Error level.

Subsystem filter in the sidebar lets you select one or more subsystems. This is the fastest way to isolate a specific application's logs from system messages. Category filter is available after selecting a subsystem — it shows all categories used by the selected application. Level filter restricts messages by severity level: you can show only errors or only debug messages.

Regular Expressions in Search

The Console.app search field supports regex via the REGEX:pattern syntax. Example: REGEX:error.*tim(e|out) finds all messages containing “error” and a word starting with “tim” and ending with “e” or “out”. Regex only works in the search field, not in subsystem or category filters.

Live and Historical Modes

Live is the real-time mode in which Console.app shows new messages as they appear in the kernel ring buffer. This mode is active by default and is suitable for debugging a running application: you launch the app and see its logs with a 1–5 second delay. The Live button (or ⌘L) toggles the stream on and off.

Historical is the archive viewing mode. Console.app stores all messages from the last 7–14 days (configurable in the system) in a .tracev3 database. Historical mode opens this archive and lets you search through it using any filters, not just the current stream. This is indispensable for analyzing problems that occurred at night or when the application was running without being connected to a Mac.

Switching between modes is done via the Live button in the toolbar. When Live is off, Console.app shows historical data. In this mode you can navigate the timeline using the calendar or the ← → buttons. Historical data is only available for logs that were saved to disk — messages that were overwritten in the ring buffer do not appear in the archive.

Exporting and Sharing Logs

Console.app supports exporting filtered logs in several formats. File → Export → Save lets you choose the format: .logarchive (Apple's native format, includes all metadata), .txt (plain text with columns), and .json (structured data with fields). For attaching to a bug report, use .logarchive — it can be opened on any Mac in Console.app.

Export from an iOS device: via Xcode (Devices → Open Console) or via the log collect --device --output ./archive.logarchive command in the terminal. Open the resulting .logarchive in Console.app on a Mac — the logs come from the remote device, but filters and search work the same as with local logs.

// Exporting iOS device logs via terminal
// log collect --device --output ./ios_crash.logarchive
// log show --subsystem com.example.app --last 1h --output json

// Example: export logs for the last hour
// log show --predicate 'subsystem == "com.example.myapp"' \
//   --info --debug --last 1h --output json > logs.json

// Parsing exported logs in Swift
let jsonData = try Data(contentsOf: URL(fileURLWithPath: "logs.json"))
let decoded = try JSONDecoder()
    .decode([LogEntry].self, from: jsonData)

Sharing Logs

.logarchive is the optimal format for sending to a colleague or attaching to a JIRA ticket. The file contains not only messages but also subsystem, category, timestamps, thread IDs, and all metadata. The archive size is significantly smaller than raw logs thanks to .tracev3 compression. Before sending, make sure the logs contain no private data: use a filter on your application's subsystem to exclude system logs that may contain confidential information from other processes.

Practical Debugging Examples with Console.app

Crash diagnosis without Xcode: if an application crashes when launched outside Xcode, Console.app will show a Fault message from the process. Find Reports → Crash Reports in the sidebar — complete crash reports with signatures and stack traces are displayed there. Use the subsystem filter for your application and set the level to Error+Fault to see all critical events before the crash.

Performance Analysis via Console.app

Console.app allows you to track application delays using timestamps. If more time than expected has passed between two related messages (e.g., “request sent” and “response received”), that is a signal of a performance problem. A filter on your application's subsystem with the Default level will show all key events with millisecond precision.

Finding memory leaks: when a memory leak occurs, the system sends a memory warning via os_log with the memory category and Error level. In Console.app, filter by the word memory and select your subsystem. If the warning repeats every 5–10 seconds, the application is actively consuming memory. You can also enable Debug logs to track allocations.

Debugging network requests: if your application uses os_log for network events, Console.app will show all requests and responses with timings. A category=network filter reduces noise. If the time between a request and response exceeds expectations, look for messages with level=Error — they will indicate timeouts or DNS errors.

// Structure for parsing Console.app JSON logs
struct LogEntry: Codable {
    let timestamp: String
    let eventMessage: String
    let subsystem: String
    let category: String
    let messageType: UInt8

    var level: String {
        switch messageType {
        case 1: return "Fault"
        case 16: return "Error"
        case 17: return "Debug"
        default: return "Default"
        }
    }
}