Console в Xcode: ключові поняття, виведення даних та налагодження

Що таке Console в Xcode

Console — це частина Debug Area в Xcode, розташована в нижній панелі редактора (View → Debug Area → Activate Console, сполучення Cmd + Shift + Y). Console показує весь текстовий вивід від запущеного застосунку: повідомлення від NSLog, os_log, print, попередження часу виконання та автоматичні дампи винятків при падінні застосунку.

Console працює як на симуляторі, так і на фізичному пристрої. На симуляторі повідомлення надходять миттєво через локальний pipe, на пристрої — через USB-з'єднання із затримкою 1–3 кадри. Для продакшн-застосунків Console на пристрої недоступна — розробник покладається на Crashlytics або Unified Logging із віддаленим збором через log collect.

На відміну від системного застосунку Console.app на Mac, вікно Console в Xcode показує лише логи поточного запущеного застосунку (з можливістю фільтрації). Console.app збирає логи всіх процесів на Mac, включаючи iOS-симулятори. Однак для налагодження iOS-застосунків розробники використовують вбудовану Console Xcode через інтеграцію з відлагоджувачем LLDB.

API логування: NSLog, os_log та print

Три основні API доступні iOS-розробнику для виведення в Console: NSLog (застарілий), os_log (рекомендований) та print (лише Swift). Кожен має свої особливості щодо продуктивності, форматування та сумісності з Unified Logging System.

NSLog — класичне логування

NSLog — функція з Foundation, доступна в Objective-C та Swift. NSLog виводить повідомлення з міткою часу, іменем процесу та PID. Недоліки: NSLog записує в системний буфер синхронно, блокуючи поточний потік на час запису. При частих викликах (наприклад, у циклі) NSLog створює помітну затримку. Apple не рекомендує NSLog для нових проектів, але він залишається сумісним із старим кодом та сторонніми бібліотеками.

os_log — сучасний стандарт

os_log — API з os.framework, представлений в iOS 10. os_log асинхронний: повідомлення ставиться в чергу та записується в буфер без блокування потоку, що викликає. Згідно з WWDC 2016, os_log в 50 разів швидший за NSLog у високонавантажених сценаріях. os_log також підтримує динамічне керування: повідомлення рівня DEBUG збираються лише в Debug-складанні, а в Release вони ігноруються без накладних витрат.

print() — лише Swift вивід

print() — найпростіший спосіб виведення в Swift. print записує в stdout (стандартний вивід), який Xcode перенаправляє в Console. print не додає метадані (час, рівень), але підтримує буферизацію stdout. Для швидкого налагодження print — зручний інструмент, але для постійного логування він поступається os_log за функціональністю та контролем.

import os.log

// NSLog — застарілий, блокуючий
NSLog("Application started")

// os_log — рекомендований, асинхронний
let log = OSLog(
    subsystem: "com.myapp",
    category: "lifecycle"
)
os_log("Application started", log: log)

// print — швидкий Swift-вивід
print("Application started")

Unified Logging: категорії, рівні та підсистеми

Unified Logging System (ULS) — наказна інфраструктура логування Apple, представлена в iOS 10 та macOS Sierra. ULS збирає повідомлення від усіх процесів системи в єдине сховище з можливістю віддаленого доступу через інструмент командного рядка log на Mac. Розробник використовує os_log для запису в ULS, а Console для читання.

Підсистеми та категорії

Кожен OSLog ідентифікується парою subsystem (наприклад, com.myapp.network) та category (наприклад, http, websocket). Підсистема — це домен застосунку (одна програма може мати кілька підсистем для різних модулів). Категорія — це компонент всередині підсистеми. Комбінація subsystem + category дозволяє гнучко фільтрувати логи в Console та log collect.

Рівні логування OSLog

log collect — віддалений збір логів

Команда log collect на Mac збирає архівні логи з підключеного iOS-пристрою в файл .logarchive. Цей файл можна відкрити в Console.app на Mac для детального аналізу, включаючи повідомлення os_log, краш-логи та системну діагностику. Для вмикання збору на пристрої потрібно увімкнути Режим розробника та підключити пристрій через USB.

Робота з Console: покрокове налагодження та аналіз краш-логів

Практична робота з Console включає три основні сценарії: активне логування під час розробки, аналіз краш-логів після падіння та віддалену діагностику через .logarchive. Для кожного сценарію є оптимальний набір інструментів та налаштувань.

Налаштування Console для розробки

Рекомендується створити окремий OSLog для кожного модуля застосунку з рівнями: debug (детальне налагодження), info (ключові переходи станів), error (винятки та збої). В Console Xcode увімкніть фільтр за підсистемою вашого застосунку, щоб виключити системні повідомлення, які створюють шум та відволікають від логіки застосунку.

Аналіз краш-логу

При падінні застосунку Xcode автоматично зупиняє виконання та показує потік, на якому відбувся краш, з повним stack trace в Console. Перший рядок краш-логу містить тип винятку (NSException, EXC_BAD_ACCESS) та причину. Вивчайте stack trace знизу вгору: останній викликаний метод — місце крашу. Для зашифрованих адрес (в Release) потрібна symbolication через dSYM.

// Приклад модульного налаштування OSLog
extension OSLog {
    static let uiLifecycle = OSLog(
        subsystem: "com.myapp.ui",
        category: "lifecycle"
    )
    static let network = OSLog(
        subsystem: "com.myapp.network",
        category: "http"
    )
    static let database = OSLog(
        subsystem: "com.myapp.data",
        category: "core-data"
    )
}

// Використання з рівнями
os_log("View did load", log: .uiLifecycle, type: .debug)
os_log("HTTP 200 received", log: .network, type: .info)
os_log("Failed to save: \(error.localizedDescription)",
    log: .database, type: .error)

Просунуті можливості: breakpoint-логи та кастомні формати

Console Xcode підтримує кілька просунутих функцій, які виходять за межі простого логування. Breakpoint-логи дозволяють виводити повідомлення в Console без зупинки виконання, а команди LLDB в Debugger Command дають повний контроль над форматуванням виведення.

Breakpoint-логи без зупинки

Ви можете налаштувати breakpoint так, щоб він виводив повідомлення в Console та автоматично продовжував виконання. Встановіть breakpoint на потрібному рядку, клікніть правою кнопкою → Edit Breakpoint → додайте Debugger Command: «po self» або «expr @import UIKit» + Debugger Command: «po self.view». Позначте Automatically continue after evaluating. Після запуску breakpoint буде виводити результат команди в Console при кожному досягненні рядка, не перериваючи потік.

Команди LLDB в Console

Console Xcode підтримує виконання довільних команд LLDB під час зупинки на breakpoint. po (print object) виводить опис об'єкта, p (print) — примитивні значення, а expr виконує вирази Swift/ObjC. Для форматованого виведення використовуйте p/CGRectGetWidth. LLDB-вивід відображається в Console одразу після досягнення breakpoint.

func processUserData(user: User) {
    // Breakpoint тут з Debugger Command:
    // po "User name: \(user.name)"
    // expr user.age = 30
    print("Processing user: \(user.name)")
}

// Приклад кастомного логування з послідовністю
func trackMethodCall(
    file: String = #file,
    function: String = #function
) {
    os_log("[\(function)] called",
        log: .uiLifecycle, type: .debug)
}

Інтеграція з Instruments

Console Xcode тісно інтегрована з Instruments — інструментом профілювання Xcode. При запуску застосунку через Product → Profile з шаблоном Logging всі повідомлення os_log записуються в трасу Instruments з позначками часу. Це дозволяє одночасно бачити логи, продуктивність та системні події на одній часовій шкалі, що критично для діагностики race condition та регресій продуктивності.