GraphQL vs REST in Swift: Was iOS-Entwickler im Jahr 2025 wählen sollten

Einleitung: REST vs GraphQL – die alte Schlacht in der neuen Welt von Swift

Vor langer Zeit, in der Ära von Objective-C und der Dispatch-by-Selector-Programmierung, war die Wahl zwischen REST und GraphQL nicht so brisant. REST war der König und JSON sein treuer Knappe. Aber die Zeiten haben sich geändert. Swift wurde zu einer Sprache mit einem starken Typsystem, async/await, Codable und leistungsstarken Frameworks wie Apollo iOS kamen hinzu. Jetzt stellt sich die Frage „REST oder GraphQL?“ anders: „Was bringt meinem Swift-Projekt mehr Nutzen?“.

In diesem Artikel werden wir nicht Wikipedia nacherzählen. Wir nehmen ein reales Beispiel einer iOS-App für eine Bildungsplattform (ja, genau die PythonLib) und schauen uns an, wie sich jeder Ansatz im Swift-Code verhält. Sie erfahren, wann REST immer noch die Oberhand hat und wann GraphQL der wahre Retter ist.

Kurz und knapp: Worin sich REST von GraphQL unterscheidet

Für diejenigen, die gerade erst in das Thema einsteigen – die grundlegenden Konzepte.

• REST – ein Architekturstil, bei dem jede Ressource (Benutzer, Kurs, Lektion) ihre eigene URL hat. Sie erhalten eine feste Datenstruktur, die der Server Ihnen geben möchte. Oft – eine ganze Menge Überflüssiges.
• GraphQL – eine Abfragesprache. Sie entscheiden selbst, welche Felder Sie benötigen. Ein einziger Einstiegspunkt (/graphql) und eine einzige Anfrage können mehrere REST-Anfragen ersetzen.

Auf dem Papier sieht GraphQL wie eine silberne Kugel aus. Aber in Swift-Projekten gibt es Nuancen, die wir uns jetzt in der Praxis ansehen werden.

Beispiel 1: Benutzerprofil und seine Kurse abrufen

REST-Ansatz in Swift (URLSession + Codable)

Angenommen, wir haben eine klassische REST-API. Um das Profil und die Kursliste anzuzeigen, sind zwei Anfragen nötig:

// Modellestruct UserProfile: Codable {    let id: Int    let name: String    let email: String    let avatarURL: String}

struct Course: Codable {    let id: Int    let title: String    let progress: Double}

// Netzwerkschichtfunc fetchUserProfile(userId: Int) async throws -> UserProfile {    let url = URL(string: "https://api.pythonlib.ru/users/\\(userId)")!    let (data, _) = try await URLSession.shared.data(from: url)    return try JSONDecoder().decode(UserProfile.self, from: data)}

func fetchCourses(userId: Int) async throws -> [Course] {    let url = URL(string: "https://api.pythonlib.ru/users/\\(userId)/courses")!    let (data, _) = try await URLSession.shared.data(from: url)    return try JSONDecoder().decode([Course].self, from: data)}

// Verwendunglet profile = try await fetchUserProfile(userId: 42)let courses = try await fetchCourses(userId: 42)

Alles einfach und vorhersehbar. Aber es gibt ein Problem: Wir erhalten alle Felder des Profils, auch wenn wir nur den Namen und die E-Mail benötigen. Und außerdem – zwei Netzwerkanfragen. Bei einer langsamen Verbindung ist das schmerzhaft.

GraphQL-Ansatz in Swift (Apollo iOS)

Jetzt dasselbe, aber über GraphQL. Zuerst definieren wir die Abfrage in einer .graphql-Datei:

query GetUserWithCourses($userId: ID!) {    user(id: $userId) {        id        name        email        courses {            id            title            progress        }    }}

Apollo generiert automatisch typisierten Swift-Code. In Xcode sieht das so aus:

import Apollo

let apolloClient = ApolloClient(url: URL(string: "https://api.pythonlib.ru/graphql")!)

func fetchUserWithCourses(userId: Int) async throws -> GetUserWithCoursesQuery.Data {    return try await withCheckedThrowingContinuation { continuation in        apolloClient.fetch(query: GetUserWithCoursesQuery(userId: userId)) { result in            switch result {            case .success(let graphQLResult):                if let data = graphQLResult.data {                    continuation.resume(returning: data)                } else if let errors = graphQLResult.errors {