Long Polling vs WebSocket en Swift : que choisir pour iOS en 2025

Introduction : l'éternelle dilemme du développeur iOS

Imaginez : vous développez une application de messagerie ou une application boursière. L'utilisateur attend des notifications en temps réel, et vous devez choisir entre Long Polling ou WebSocket. En Swift, les deux approches ont leur place, mais chacune avec ses nuances. Dans cet article, nous ne nous contenterons pas de lister les avantages et inconvénients, mais nous analyserons des exemples de code réels, les performances, l'impact sur la batterie et nous vous donnerons un algorithme de choix clair. C'est parti !

Qu'est-ce que le Long Polling en Swift ? (et pourquoi ce n'est pas une « requête éternelle »)

Long Polling est une requête HTTP classique que le serveur ne ferme pas immédiatement, mais maintient ouverte jusqu'à ce qu'un nouvel événement se produise ou que le délai d'attente expire. En Swift, cela est implémenté via URLSession avec un timeoutIntervalForRequest personnalisé.

Beaucoup confondent Long Polling avec le polling classique (où le client interroge le serveur toutes les 5 secondes). La différence est qu'avec Long Polling, le serveur « pousse » lui-même les données dès qu'elles apparaissent, et le client envoie immédiatement une nouvelle requête après avoir reçu la réponse.

Exemple de Long Polling en Swift avec async/await

import Foundation\n\nclass LongPollingClient {\n    private let session: URLSession\n    private let baseURL = URL(string: "https://api.pythonlib.ru/events")!\n    private var isPolling = false\n    \n    init() {\n        let config = URLSessionConfiguration.default\n        config.timeoutIntervalForRequest = 60 // Délai d'attente long\n        config.waitsForConnectivity = true\n        self.session = URLSession(configuration: config)\n    }\n    \n    func startPolling() async {\n        isPolling = true\n        while isPolling {\n            do {\n                let (data, response) = try await session.data(from: baseURL)\n                guard let httpResponse = response as? HTTPURLResponse,\n                      httpResponse.statusCode == 200 else {\n                    continue\n                }\n                // Traitement des données reçues\n                if let events = try? JSONDecoder().decode([Event].self, from: data) {\n                    await handleEvents(events)\n                }\n            } catch {\n                // Si délai d'attente dépassé, on recommence simplement le cycle\n                if let urlError = error as? URLError, \n                   urlError.code == .timedOut {\n                    continue\n                }\n                // Autres erreurs — on journalise et on attend\n                print("Polling error: \\(error.localizedDescription)")\n                try? await Task.sleep(nanoseconds: 5_000_000_000)\n            }\n        }\n    }\n    \n    func stopPolling() {\n        isPolling = false\n    }\n    \n    private func handleEvents(_ events: [Event]) async {\n        // Mise à jour de l'interface utilisateur sur le thread principal\n        await MainActor.run {\n            NotificationCenter.default.post(name: .newEvents, object: events)\n        }\n    }\n}

Important : n'oubliez pas Task.sleep en cas d'erreurs, pour ne pas submerger le serveur de reconnexions infinies. Sur pythonlib.ru, nous avons testé cette approche avec une charge de 10 000 clients — le serveur tient bien, mais la latence augmente.

WebSocket en Swift : puissance native ou Starscream ?

Depuis iOS 13, Apple a ajouté la prise en charge native de WebSocket via URLSessionWebSocketTask. Cela signifie que vous pouvez oublier les bibliothèques tierces, bien que Starscream reste un choix populaire pour les projets nécessitant la prise en charge des anciennes versions d'iOS (12 et inférieures).

Exemple de WebSocket natif en Swift (iOS 13+)

import Foundation\n\nclass WebSocketManager: NSObject, URLSessionWebSocketDelegate {\n    private var webSocket: URLSessionWebSocketTask?\n    private let session: URLSession\n    \n    override init() {\n        let config = URLSessionConfiguration.default\n        config.timeoutIntervalForRequest = 60\n        self.session = URLSession(configuration: config)\n