Console no Xcode: conceitos-chave, saída de dados e depuração

O que é o Console no Xcode

O Console faz parte do Debug Area no Xcode, localizado no painel inferior do editor (View → Debug Area → Activate Console, atalho Cmd + Shift + Y). O Console mostra toda a saída de texto do aplicativo em execução: mensagens de NSLog, os_log, print, avisos de tempo de execução e dumps automáticos de exceção quando o aplicativo falha.

O Console funciona tanto no simulador quanto em um dispositivo físico. No simulador, as mensagens chegam instantaneamente através de um pipe local; em um dispositivo, elas chegam via conexão USB com um atraso de 1–3 quadros. Para aplicativos de produção, o Console no dispositivo não está disponível — os desenvolvedores contam com Crashlytics ou Unified Logging com coleta remota via log collect.

Diferente do aplicativo de sistema Console.app no Mac, a janela do Console no Xcode mostra apenas logs do aplicativo atual em execução (com capacidade de filtragem). O Console.app coleta logs de todos os processos no Mac, incluindo simuladores iOS. No entanto, para depurar aplicativos iOS, os desenvolvedores usam o Console integrado do Xcode devido à sua integração com o depurador LLDB.

APIs de registro: NSLog, os_log e print

Três APIs principais estão disponíveis para o desenvolvedor iOS para saída no Console: NSLog (obsoleto), os_log (recomendado) e print (apenas Swift). Cada uma tem suas próprias características em termos de desempenho, formatação e compatibilidade com o Unified Logging System.

NSLog — Registro clássico

NSLog é uma função do Foundation, disponível em Objective-C e Swift. O NSLog exibe uma mensagem com carimbo de data/hora, nome do processo e PID. Desvantagens: o NSLog escreve no buffer do sistema de forma síncrona, bloqueando a thread atual durante a escrita. Com chamadas frequentes (por exemplo, em um loop), o NSLog cria um atraso perceptível. A Apple não recomenda o NSLog para novos projetos, mas ele permanece compatível com código legado e bibliotecas de terceiros.

os_log — Padrão moderno

os_log é uma API do os.framework, introduzida no iOS 10. o os_log é assíncrono: a mensagem é enfileirada e escrita no buffer sem bloquear a thread de chamada. De acordo com a WWDC 2016, o os_log é 50 vezes mais rápido que o NSLog em cenários de alta carga. O os_log também suporta controle dinâmico: mensagens de nível DEBUG são coletadas apenas em builds Debug, e em Release são ignoradas sem sobrecarga.

print() — Saída apenas Swift

print() é o método de saída mais simples em Swift. O print escreve no stdout (saída padrão), que o Xcode redireciona para o Console. O print não adiciona metadados (hora, nível), mas suporta buffer de stdout. Para depuração rápida, o print é uma ferramenta conveniente, mas para registro permanente ele fica aquém do os_log em funcionalidade e controle.

import os.log

// NSLog — obsoleto, bloqueante
NSLog("Application started")

// os_log — recomendado, assíncrono
let log = OSLog(
    subsystem: "com.myapp",
    category: "lifecycle"
)
os_log("Application started", log: log)

// print — saída Swift rápida
print("Application started")

Unified Logging: categorias, níveis e subsistemas

Unified Logging System (ULS) é a infraestrutura de registro abrangente da Apple, introduzida no iOS 10 e macOS Sierra. O ULS coleta mensagens de todos os processos do sistema em um único armazenamento com capacidade de acesso remoto através da ferramenta de linha de comando log no Mac. Os desenvolvedores usam o os_log para escrever no ULS e o Console para ler.

Subsistemas e categorias

Cada OSLog é identificado por um par de subsystem (por exemplo, com.myapp.network) e category (por exemplo, http, websocket). O subsistema é o domínio do aplicativo (um aplicativo pode ter vários subsistemas para diferentes módulos). A categoria é um componente dentro do subsistema. A combinação subsystem + category permite filtragem flexível de logs no Console e no log collect.

Níveis de registro do OSLog

log collect — Coleta remota de logs

O comando log collect no Mac reúne logs arquivados de um dispositivo iOS conectado em um arquivo .logarchive. Este arquivo pode ser aberto no Console.app no Mac para análise detalhada, incluindo mensagens os_log, logs de crash e diagnósticos do sistema. Para ativar a coleta no dispositivo, é necessário ativar o Modo Desenvolvedor e conectar o dispositivo via USB.

Trabalhando com o Console: depuração passo a passo e análise de logs de crash

O trabalho prático com o Console inclui três cenários principais: registro ativo durante o desenvolvimento, análise de logs de crash após uma falha e diagnóstico remoto via .logarchive. Cada cenário tem um conjunto ideal de ferramentas e configurações.

Configurando o Console para desenvolvimento

Recomenda-se criar um OSLog separado para cada módulo do aplicativo com níveis: debug (depuração detalhada), info (transições importantes de estado), error (exceções e falhas). No Console do Xcode, ative o filtro pelo subsistema do seu aplicativo para excluir mensagens do sistema que criam ruído e distraem da lógica do aplicativo.

Análise de logs de crash

Quando o aplicativo falha, o Xcode para automaticamente a execução e mostra a thread onde ocorreu a falha, com um stack trace completo no Console. A primeira linha do log de falha contém o tipo de exceção (NSException, EXC_BAD_ACCESS) e o motivo. Estude o stack trace de baixo para cima: o último método chamado é o local da falha. Para endereços criptografados (em Release), é necessária a symbolication através de dSYM.

// Exemplo de configuração modular do 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"
    )
}

// Uso com níveis
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)

Recursos avançados: logs de breakpoint e formatos personalizados

O Console do Xcode suporta vários recursos avançados que vão além do registro simples. Logs de breakpoint permitem enviar mensagens para o Console sem parar a execução, e comandos LLDB no Debugger Command oferecem controle total sobre a formatação da saída.

Logs de breakpoint sem parada

Você pode configurar um breakpoint para exibir uma mensagem no Console e continuar a execução automaticamente. Coloque um breakpoint na linha desejada, clique com o botão direito → Edit Breakpoint → adicione Debugger Command: “po self” ou “expr @import UIKit” + Debugger Command: “po self.view”. Marque Automatically continue after evaluating. Após a execução, o breakpoint exibirá o resultado do comando no Console cada vez que a linha for alcançada, sem interromper a thread.

Comandos LLDB no Console

O Console do Xcode suporta a execução de comandos LLDB arbitrários enquanto parado em um breakpoint. po (print object) exibe a descrição de um objeto, p (print) exibe valores primitivos, e expr executa expressões Swift/ObjC. Para saída formatada, use p/CGRectGetWidth. A saída do LLDB aparece no Console imediatamente após atingir o breakpoint.

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

// Exemplo de registro personalizado com sequência
func trackMethodCall(
    file: String = #file,
    function: String = #function
) {
    os_log("[\(function)] called",
        log: .uiLifecycle, type: .debug)
}

Integração com Instruments

O Console do Xcode está intimamente integrado com o Instruments — a ferramenta de perfilamento do Xcode. Ao executar o aplicativo através de Product → Profile com o template Logging, todas as mensagens os_log são registradas no trace do Instruments com carimbos de data/hora. Isso permite visualizar simultaneamente logs, desempenho e eventos do sistema em uma única linha do tempo, o que é crítico para diagnosticar condições de corrida e regressões de desempenho.