Logging em aplicações Swift: melhores práticas na prática

Logging em aplicações Swift: melhores práticas na prática

Logging não é apenas escrever mensagens no console. No desenvolvimento profissional para iOS/macOS, um logging configurado corretamente torna-se uma ferramenta indispensável para depuração, monitoramento e análise do comportamento da aplicação em produção. Neste artigo, vamos analisar as melhores práticas de logging em Swift, explorar ferramentas modernas (os_log, SwiftyBeaver) e escrever exemplos de código reais que você pode implementar no seu projeto ainda hoje.

Por que print() é ruim para produção

Muitos desenvolvedores iniciantes usam print() para depuração. No entanto, em aplicações de produção, isso leva a problemas:

• Desempenho: print() bloqueia a thread de forma síncrona, atrasando a UI.
• Segurança: Dados sensíveis (tokens, senhas) podem vazar para os logs do sistema.
• Falta de filtragem: Você não consegue separar mensagens de debug de error.
• Sem estrutura: Cada mensagem é apenas uma string sem metadados (nível, categoria, arquivo, função).

Em vez de print(), use o framework do sistema os_log (Unified Logging) ou bibliotecas de terceiros, como SwiftyBeaver.

Melhor prática #1: Uso de os_log (Unified Logging System)

A partir do iOS 10 / macOS 10.12, a Apple recomenda usar os_log do framework OSLog. Este é um mecanismo embutido que funciona de forma assíncrona, não afeta o desempenho e coleta metadados automaticamente.

Configuração básica do os_log

import OSLog

// Criando um logger para o módulo "Network"let networkLogger = Logger(subsystem: "com.yourapp.network", category: "HTTP")

// Logando diferentes níveisnetworkLogger.debug("Requisição enviada: \\(url)")networkLogger.info("Resposta recebida: \\(statusCode)")networkLogger.error("Erro de conexão: \\(error.localizedDescription)")networkLogger.fault("Erro crítico: perda de dados")

Vantagens do os_log:

• Assíncrono: Não bloqueia a main thread.
• Níveis: debug, info, error, fault — podem ser filtrados no console do Xcode.
• Segurança: Dados sensíveis são automaticamente mascarados em builds de release.
• Integração com Console.app: Todos os logs estão disponíveis no dispositivo do usuário (com a permissão dele).

Níveis dinâmicos para depuração

Para conveniência, você pode criar um wrapper que permite ativar/desativar logs de debug dependendo do esquema de build:

import OSLog

struct AppLogger {    private static let subsystem = "com.yourapp.main"        static let general = Logger(subsystem: subsystem, category: "General")    static let network = Logger(subsystem: subsystem, category: "Network")    static let database = Logger(subsystem: subsystem, category: "Database")        static func debug(_ message: String, file: String = #file, function: String = #function, line: Int = #line) {        #if DEBUG        let fileName = (file as NSString).lastPathComponent        general.debug("[\\(fileName):\\(line)] \\(function) - \\(message)")        #endif    }}

// UsoAppLogger.debug("Usuário tocou no botão de login")AppLogger.network.info("Chamada à API iniciada")

Melhor prática #2: SwiftyBeaver — logging flexível para projetos complexos

Se você precisa de funcionalidades avançadas (logging em arquivo, envio para servidor, saída colorida no console), dê uma olhada no SwiftyBeaver. É uma das bibliotecas de logging mais populares em Swift.

Instalação via Swift Package Manager

// Em Package.swift ou via Xcode -> File -> Add Packages// URL: ht