Surveillance et journalisation des applications Swift : débogage sans douleur

Votre application fonctionne-t-elle parfaitement ? Vérifions

Avez-vous déjà mis une application Swift en production en priant pour qu'elle ne plante pas ? Moi oui. Et chaque fois qu'un utilisateur écrivait « ça a planté », je me sentais comme un chaton aveugle. La journalisation et la surveillance sont ces yeux et ces oreilles qui transforment le chaos en ordre. Sans elles, vous devinez ce qui a mal tourné. Avec elles, vous voyez chaque étape.

Dans cet article, nous allons voir comment configurer la surveillance des applications Swift pour que vous dormiez sur vos deux oreilles. Pas de théorie sèche — seulement du code vivant, des cas réels et des astuces que j'ai accumulées au fil des ans. C'est parti !

Pourquoi la journalisation en Swift ne se résume pas à print()

Le premier réflexe de tout développeur est de mettre un print("tout est cassé ici") à chaque coin de rue. Et ça marche… jusqu'à ce que vous publiiez l'application. En production, print disparaît dans le vide, et l'utilisateur reste seul face au bug. Il nous faut quelque chose de plus.

La journalisation moderne des applications Swift repose sur des données structurées, des niveaux de priorité et la possibilité de collecte à distance. Apple nous offre un outil puissant — OSLog. Il est léger, rapide et intégré directement dans le système. Voyons comment l'apprivoiser.

OSLog : niveau de base

Importons le framework et créons un logger :

import OSLog\n\nlet logger = Logger(\n    subsystem: "com.pythonlib.monitoring",\n    category: "network"\n)\n\nfunc fetchUserData() {\n    logger.info("Début du chargement des données utilisateur")\n    // ... code de la requête ...\n    logger.debug("Réponse reçue : \\(response.statusCode)")\n}

Notez subsystem et category. Ce sont vos balises pour le filtrage. Quand vous avez 50 modules, vous pouvez isoler uniquement les logs réseau ou uniquement les logs de base de données — sans bruit inutile.

Niveaux de journalisation : quand crier, quand murmurer

OSLog prend en charge six niveaux. Voici comment les utiliser :

\n
• debug — pour le développement, désactivé en release (sauf activation explicite).
\n
• info — informations utiles qui n'encombrent pas la console.
\n
• notice — événements importants, comme un démarrage réussi.
\n
• error — erreurs pouvant être traitées.
\n
• fault — pannes critiques pouvant entraîner un plantage de l'application.
\n

Exemple avec une erreur réelle :

func handleApiError(_ error: Error) {\n    logger.error("Erreur API : \\(error.localizedDescription, privacy: .public)")\n    // privacy: .public — pour voir le texte dans les logs, sinon il sera masqué\n}

Surveillance des applications Swift : métriques et performances

Les logs, c'est le passé. La surveillance des applications Swift, c'est le présent. Vous voulez savoir ce qui se passe maintenant : combien de mémoire votre code consomme, si l'animation ralentit, si le taux d'images chute.

Apple fournit MetricKit — un framework pour collecter des diagnostics sur les appareils des utilisateurs. Il recueille les rapports de crash, les données de batterie et les métriques de démarrage. Mais pour une surveillance complète, on fait souvent appel à des services tiers.

Intégration de Crashlytics (Firebase) — rapide et efficace

Crashlytics reste la référence de l'industrie. Voici une configuration minimale :

import FirebaseCrashlytics\n\n// Quelque part au démarrage de l'application\nCrashlytics.crashlytics().setUserID("user_123")\nCrashlytics.crashlytics().setCustomValue(true, forKey: "is_premium")\n\n// Journalisation des erreurs non fatales\ndo {\n    try riskyOperation()\n} catch {\n    Crashlytics.crashlytics().record(error: error)\n    logger.error("Erreur non fatale : \\(error)")\n}

Point important : ne journalisez pas les données personnelles de l'utilisateur sans consentement. Utilisez setUserID uniquement si vous disposez d'un identifiant anonymisé.

Envoi des m