Journalisation dans les applications Swift : bonnes pratiques pour les débutants

Formateur Python en ligne pour débutants

Apprenez Python facilement sans surcharge théorique. Résolvez des tâches pratiques avec vérification automatique et écrivez du code directement dans le navigateur.

Start Course

Journalisation dans les applications Swift : bonnes pratiques pour les débutants



La journalisation est l'un des outils les plus importants dans l'arsenal du développeur. Sans elle, le débogage d'erreurs complexes en production devient une divination. Dans cet article, nous allons examiner les meilleures pratiques de journalisation pour les applications Swift sous iOS et macOS, en commençant par les bases et en terminant par des techniques avancées. Vous apprendrez non seulement à afficher du texte dans la console, mais à construire un système qui vous aidera à trouver et corriger rapidement les bugs.



Pourquoi ne pas utiliser print() en production ?



De nombreux développeurs débutants utilisent print() pour afficher des informations de débogage. Cela fonctionne en phase de développement, mais dans une application prête, cette approche crée de nombreux problèmes :



  • Aucun contrôle des niveaux : vous ne pouvez pas filtrer uniquement les erreurs ou uniquement les avertissements.
  • Baisse des performances : print() bloque le thread de manière synchrone, ce qui peut provoquer des lags notables dans l'interface utilisateur.
  • Absence de catégorisation : tous les messages sont mélangés, impossible de savoir de quel module provient le message.
  • Pas de persistance : la sortie de print() n'est pas sauvegardée sur l'appareil de l'utilisateur, vous ne pourrez pas analyser les logs après un crash de l'application.
  • Problèmes de sécurité : un print() oublié par inadvertance peut afficher des données sensibles dans la console.


Au lieu de print(), utilisez os_log du framework Unified Logging (disponible depuis iOS 10 / macOS 10.12).



Configuration de OSLog : exemple de base



Pour commencer, importez le framework os.log et créez un objet logger pour votre module :



import os.log

let logger = Logger( subsystem: "com.yourapp.networking", category: "API")

func fetchUsers() { logger.info("Début du chargement des utilisateurs...") // Logique de la requête logger.debug("\\(usersCount) utilisateurs reçus")}


Analyse des paramètres :

  • subsystem — généralement l'identifiant de votre application (bundle ID). Permet de regrouper les logs par application.
  • category — le nom du module ou du composant (par exemple, "UI", "Network", "Database").


Dans Xcode, vous pouvez filtrer les logs par subsystem et category dans la console, ce qui simplifie grandement l'analyse.



Niveaux de journalisation : quand utiliser quoi ?



Unified Logging prend en charge 6 niveaux de journalisation. Choisir le bon niveau est la moitié du succès :



  • debug — pour le débogage pendant le développement. N'est pas sauvegardé sur l'appareil de l'utilisateur (sauf si un profilage spécial est activé).
  • info — pour les événements importants qui peuvent être utiles lors de l'analyse (par exemple, ouverture d'un écran, requête réussie).
  • notice — niveau standard. Utilisé pour les événements qui ne sont pas des erreurs mais qui méritent attention.
  • error — pour les erreurs gérées (par exemple, échec du chargement des données, mais l'application continue de fonctionner).
  • fault — pour les pannes critiques qui entraînent un crash de l'application ou une perte de données.
  • critical — utilisé rarement, pour des situations particulièrement graves (par exemple, corruption de la base de données).


import os.log

let logger = Logger(subsystem: "com.yourapp", category: "general")

logger.debug("Uniquement pour le débogage : \\(someVariable)")logger.info("L'utilisateur a ouvert l'écran du profil")logger.notice("Scénario non standard détecté")logger.error("Erreur réseau : \\(error.localizedDescription)")logger.fault("Erreur critique : l'application a planté")

Blogs

Book Recommendations