Long Polling vs WebSocket in Swift: Was man 2025 für iOS wählen sollte

Einleitung: Die ewige Dilemma des iOS-Entwicklers

Stellen Sie sich vor: Sie schreiben einen Messenger oder eine Börsen-App. Der Nutzer wartet auf Echtzeit-Benachrichtigungen, und Sie stehen vor der Wahl – Long Polling oder WebSocket? In Swift haben beide Ansätze ihre Daseinsberechtigung, aber jeder mit seinen eigenen Nuancen. In diesem Artikel listen wir nicht nur Vor- und Nachteile auf, sondern analysieren echte Codebeispiele, Leistung, Akkuauswirkungen und geben einen klaren Entscheidungsalgorithmus. Los geht's!

Was ist Long Polling in Swift? (und warum es keine "Endlosanfrage" ist)

Long Polling ist eine klassische HTTP-Anfrage, die der Server nicht sofort schließt, sondern offen hält, bis ein neues Ereignis eintritt oder ein Timeout abläuft. In Swift wird dies über URLSession mit einem benutzerdefinierten timeoutIntervalForRequest implementiert.

Viele verwechseln Long Polling mit normalem Polling (bei dem der Client den Server alle 5 Sekunden abfragt). Der Unterschied besteht darin, dass der Server beim Long Polling die Daten selbst "schiebt", sobald sie verfügbar sind, und der Client sofort nach Erhalt der Antwort eine neue Anfrage sendet.

Long Polling Beispiel in Swift mit 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 // Langer Timeout\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                // Verarbeitung der empfangenen Daten\n                if let events = try? JSONDecoder().decode([Event].self, from: data) {\n                    await handleEvents(events)\n                }\n            } catch {\n                // Bei Timeout einfach neuen Zyklus starten\n                if let urlError = error as? URLError, \n                   urlError.code == .timedOut {\n                    continue\n                }\n                // Andere Fehler – protokollieren und warten\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        // UI im Hauptthread aktualisieren\n        await MainActor.run {\n            NotificationCenter.default.post(name: .newEvents, object: events)\n        }\n    }\n}

Wichtig: Vergessen Sie nicht Task.sleep bei Fehlern, um den Server nicht mit endlosen Wiederverbindungen zu überlasten. Auf pythonlib.ru haben wir diesen Ansatz mit einer Last von 10k Clients getestet – der Server hält sich gut, aber die Latenz steigt.

WebSocket in Swift: Native Leistung oder Starscream?

Mit iOS 13 hat Apple native WebSocket-Unterstützung über URLSessionWebSocketTask hinzugefügt. Das bedeutet, dass Sie Drittanbieter-Bibliotheken vergessen können, obwohl Starscream weiterhin eine beliebte Wahl für Projekte ist, die ältere iOS-Versionen (12 und niedriger) unterstützen müssen.

Beispiel für natives WebSocket in 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