Console dans Xcode : concepts clés, sortie de données et débogage

Qu'est-ce que la Console dans Xcode

La Console fait partie du Debug Area dans Xcode, située dans le panneau inférieur de l'éditeur (View → Debug Area → Activate Console, raccourci Cmd + Maj + Y). La Console affiche toute la sortie texte de l'application en cours d'exécution : messages de NSLog, os_log, print, avertissements d'exécution et vidages d'exceptions automatiques en cas de plantage de l'application.

La Console fonctionne à la fois dans le simulateur et sur un appareil physique. Dans le simulateur, les messages arrivent instantanément via un tube local ; sur un appareil, ils arrivent via une connexion USB avec un retard de 1–3 images. Pour les applications de production, la Console sur l'appareil n'est pas disponible — les développeurs comptent sur Crashlytics ou Unified Logging avec collecte à distance via log collect.

Contrairement à l'application système Console.app sur Mac, la fenêtre Console dans Xcode affiche uniquement les logs de l'application en cours d'exécution (avec capacité de filtrage). Console.app collecte les logs de tous les processus sur Mac, y compris les simulateurs iOS. Cependant, pour déboguer les applications iOS, les développeurs utilisent la Console intégrée de Xcode en raison de son intégration avec le débogueur LLDB.

API de journalisation : NSLog, os_log et print

Trois API principales sont disponibles pour le développeur iOS pour la sortie dans la Console : NSLog (obsolète), os_log (recommandé) et print (Swift uniquement). Chacune a ses propres caractéristiques en termes de performances, de formatage et de compatibilité avec Unified Logging System.

NSLog — Journalisation classique

NSLog est une fonction de Foundation, disponible en Objective-C et Swift. NSLog affiche un message avec un horodatage, un nom de processus et un PID. Inconvénients : NSLog écrit dans le tampon système de manière synchrone, bloquant le thread actuel pendant l'écriture. Avec des appels fréquents (par exemple, dans une boucle), NSLog crée un retard notable. Apple ne recommande pas NSLog pour les nouveaux projets, mais il reste compatible avec le code existant et les bibliothèques tierces.

os_log — Standard moderne

os_log est une API de os.framework, introduite dans iOS 10. os_log est asynchrone : le message est mis en file d'attente et écrit dans le tampon sans bloquer le thread appelant. Selon la WWDC 2016, os_log est 50 fois plus rapide que NSLog dans les scénarios à charge élevée. os_log prend également en charge le contrôle dynamique : les messages de niveau DEBUG sont collectés uniquement dans les builds Debug, et dans Release, ils sont ignorés sans surcharge.

print() — Sortie Swift uniquement

print() est la méthode de sortie la plus simple en Swift. print écrit dans stdout (sortie standard), que Xcode redirige vers la Console. print n'ajoute pas de métadonnées (heure, niveau), mais prend en charge la mise en tampon de stdout. Pour un débogage rapide, print est un outil pratique, mais pour une journalisation permanente, il est inférieur à os_log en termes de fonctionnalités et de contrôle.

import os.log

// NSLog — obsolète, bloquant
NSLog("Application started")

// os_log — recommandé, asynchrone
let log = OSLog(
    subsystem: "com.myapp",
    category: "lifecycle"
)
os_log("Application started", log: log)

// print — sortie Swift rapide
print("Application started")

Unified Logging : catégories, niveaux et sous-systèmes

Unified Logging System (ULS) est l'infrastructure de journalisation complète d'Apple, introduite dans iOS 10 et macOS Sierra. ULS collecte les messages de tous les processus système dans un stockage unique avec capacité d'accès à distance via l'outil en ligne de commande log sur Mac. Les développeurs utilisent os_log pour écrire dans ULS et la Console pour lire.

Sous-systèmes et catégories

Chaque OSLog est identifié par une paire de subsystem (par exemple, com.myapp.network) et category (par exemple, http, websocket). Le sous-système est le domaine de l'application (une application peut avoir plusieurs sous-systèmes pour différents modules). La catégorie est un composant au sein du sous-système. La combinaison subsystem + category permet un filtrage flexible des logs dans la Console et log collect.

Niveaux de journalisation OSLog

log collect — Collecte à distance des logs

La commande log collect sur Mac rassemble les logs archivés d'un appareil iOS connecté dans un fichier .logarchive. Ce fichier peut être ouvert dans Console.app sur Mac pour une analyse détaillée, y compris les messages os_log, les logs de crash et les diagnostics système. Pour activer la collecte sur l'appareil, vous devez activer le mode Développeur et connecter l'appareil via USB.

Travailler avec la Console : débogage pas à pas et analyse des logs de crash

Le travail pratique avec la Console comprend trois scénarios principaux : la journalisation active pendant le développement, l'analyse des logs de crash après un plantage et le diagnostic à distance via .logarchive. Chaque scénario dispose d'un ensemble optimal d'outils et de configurations.

Configuration de la Console pour le développement

Il est recommandé de créer un OSLog séparé pour chaque module d'application avec des niveaux : debug (débogage détaillé), info (transitions d'état clés), error (exceptions et échecs). Dans la Console Xcode, activez le filtrage par le sous-système de votre application pour exclure les messages système qui créent du bruit et distraient de la logique de l'application.

Analyse des logs de crash

Lorsque l'application plante, Xcode arrête automatiquement l'exécution et affiche le thread où le plantage s'est produit, avec une trace de pile complète dans la Console. La première ligne du log de plantage contient le type d'exception (NSException, EXC_BAD_ACCESS) et la raison. Étudiez la trace de pile de bas en haut : la dernière méthode appelée est l'emplacement du plantage. Pour les adresses cryptées (en Release), une symbolication via dSYM est nécessaire.

// Exemple de configuration modulaire 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"
    )
}

// Utilisation avec niveaux
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)

Fonctionnalités avancées : logs de points d'arrêt et formats personnalisés

La Console Xcode prend en charge plusieurs fonctionnalités avancées qui vont au-delà de la simple journalisation. Les logs de points d'arrêt permettent d'envoyer des messages à la Console sans arrêter l'exécution, et les commandes LLDB dans Debugger Command offrent un contrôle complet sur le formatage de la sortie.

Logs de points d'arrêt sans arrêt

Vous pouvez configurer un point d'arrêt pour afficher un message dans la Console et continuer l'exécution automatiquement. Placez un point d'arrêt sur la ligne souhaitée, faites un clic droit → Edit Breakpoint → ajoutez Debugger Command : « po self » ou « expr @import UIKit » + Debugger Command : « po self.view ». Cochez Automatically continue after evaluating. Après le lancement, le point d'arrêt affichera le résultat de la commande dans la Console chaque fois que la ligne est atteinte, sans interrompre le thread.

Commandes LLDB dans la Console

La Console Xcode prend en charge l'exécution de commandes LLDB arbitraires pendant l'arrêt sur un point d'arrêt. po (print object) affiche la description d'un objet, p (print) affiche les valeurs primitives, et expr exécute des expressions Swift/ObjC. Pour une sortie formatée, utilisez p/CGRectGetWidth. La sortie LLDB apparaît dans la Console immédiatement après avoir atteint le point d'arrêt.

func processUserData(user: User) {
    // Point d'arrêt ici avec Debugger Command :
    // po "User name: \(user.name)"
    // expr user.age = 30
    print("Processing user: \(user.name)")
}

// Exemple de journalisation personnalisée avec séquence
func trackMethodCall(
    file: String = #file,
    function: String = #function
) {
    os_log("[\(function)] called",
        log: .uiLifecycle, type: .debug)
}

Intégration avec Instruments

La Console Xcode est étroitement intégrée à Instruments — l'outil de profilage de Xcode. Lors de l'exécution de l'application via Product → Profile avec le modèle Logging, tous les messages os_log sont enregistrés dans la trace Instruments avec des horodatages. Cela permet de visualiser simultanément les logs, les performances et les événements système sur une seule chronologie, ce qui est essentiel pour diagnostiquer les conditions de concurrence et les régressions de performances.