iOS 26 Migration: Was bricht, was wartet, wann und ob ihr jetzt prüfen solltet

Running on vs. Building with iOS 26 SDK: der häufigste Denkfehler

Bevor es um Risiken geht, lohnt sich eine Unterscheidung, die in der Praxis erstaunlich oft fehlt oder als allgemein bekannt angesehen wird. Doch so selbsterklärend ist sie gar nicht.

Running on iOS 26 bedeutet: Die App läuft auf einem Gerät mit iOS 26. Das passiert automatisch, wenn Apple ausrollt. Kein Dev-Aufwand nötig, solange die App funktioniert [1].

Building with iOS 26 SDK bedeutet: Die App wird mit dem iOS 26 SDK kompiliert. Das ist die eigentliche Pflicht ab dem 28. April 2026. Wer ein Update einreicht, das mit einem älteren SDK gebaut wurde, bekommt eine Rejection [1].

Die Unterscheidung klingt selbstverständlich. Ist sie aber nicht für alle Beteiligten. Teams, die hören, die App laufe problemlos auf iOS 26, ziehen daraus manchmal den falschen Schluss, dass nichts zu tun sei. Und Teams, die von der SDK-Pflicht hören, ohne den Kontext zu kennen, geraten manchmal in unnötige Aufregung über Apps, die technisch völlig in Ordnung sind.

Der richtige Ausgangspunkt sollte hier liegen: Wann wurde eure App zuletzt mit einem aktuellen SDK gebaut, und plant ihr in den nächsten Monaten ein Update? Die Antwort bestimmt die Dringlichkeit.

Kein Sonderfall: iOS 26 folgt bekannten Mustern

Die ehrlichste Einschätzung zur iOS 26 Migration lautet für uns „Migrating to iOS 26 is no different from any other major version update”. Apple folgt seit Jahren einer vorhersehbaren Logik. APIs werden lang als deprecated markiert, bevor sie entfernt werden. Neue Design-Systeme werden eingeführt, bevor sie zum Standard werden. Xcode-Anforderungen steigen schrittweise.

Aus aktiver Projektarbeit mit mehreren iOS-Apps gleichzeitig hat sich ganz klar kristallisiert: In vielen Fällen hat der Kern der Apps mit dem iOS 26 SDK ohne große Überraschungen kompiliert. Eine App, die noch zu über 80 Prozent auf Objective-C-Code aus den frühen 2010er-Jahren läuft, hat den ersten Build-Versuch nach initialem Audit problemlos überstanden.

Was tatsächlich bricht - und was nicht

Deprecated APIs: einschätzen, nicht überreagieren

Je älter und ungewarteter eine Codebase, desto höher die Wahrscheinlichkeit, auf Aufrufe zu stoßen, die jetzt entfernt wurden oder sich im Verhalten verändert haben. Ein Beispiel, das immer wieder auftaucht, ist UIWebView. In der Praxis haben alle aktiv gewarteten Apps längst auf WKWebView migriert. Wer das noch nicht getan hat, hat größere Probleme als iOS 26.

Relevant für neuere Apps: Xcode 18 ist Pflicht. Swift Strict Concurrency erzwingt sauberere asynchrone Codestrukturen. Bestehender Code, der das nicht erfüllt, produziert Build-Fehler statt Warnungen. CI/CD-Pipelines, die bisher reibungslos liefen, können dadurch blockiert werden [4].

Third-Party-SDKs: der unterschätzte Risikofaktor

Bibliotheken, die nicht mehr aktiv gewartet werden, können unter iOS 26 brechen. Nicht theoretisch, sondern konkret. In einem Projekt haben wir eine Third-Party-Bibliothek ersetzt, die nicht mehr kompatibel war. Je mehr externe Abhängigkeiten eine App hat, desto höher die Wahrscheinlichkeit, dass mindestens eine davon Probleme macht.

Besonders kritisch: Bibliotheken, die seit mehr als zwei Jahren kein Update bekommen haben oder deren Maintainer das Projekt aufgegeben haben. Ein Dependency-Scan ist deshalb der erste und wichtigste Schritt in jedem Migration Audit.

UIKit oder SwiftUI? Warum das euren Aufwand bestimmt

Eine Frage, die den Migrationsaufwand maßgeblich beeinflusst: Ist eure App eher auf UIKit-Basis gewachsen, oder habt ihr den Switch zu SwiftUI bereits vollzogen?

UIKit-Apps haben häufig tiefere Abhängigkeiten von älteren APIs. Das erhöht die Wahrscheinlichkeit, auf deprecated Calls zu stoßen. Gleichzeitig sind UIKit-Codebasen meist stabiler getestet. Liquid Glass lässt sich mit dem Opt-out-Flag sauber umschiffen, ohne das gesamte UI anzufassen.

SwiftUI-Apps profitieren davon, dass Apple SwiftUI aktiv weiterentwickelt und Liquid-Glass-Unterstützung dort natürlicher eingebettet ist. Aber SwiftUI-Codebasen, die in den letzten Jahren gewachsen sind, haben oft eigene technische Schulden durch SwiftUI-spezifische Muster, die sich zwischen den Major-Versionen verändert haben.

Es gibt kein generell einfacheres Szenario. Aber je nach Ausgangslage liegt der Schwerpunkt des Audits an anderen Stellen.

Liquid Glass: Opt-out, aktiv oder strategisch einplanen?

Liquid Glass ist Apples neue Design-Sprache. Glass-Layer, Blur-Effekte, Tiefenstaffelung, dynamische Materialien. Apps, die sich stark vom System-Look unterscheiden, wirken schneller veraltet. Das erzeugt Druck. Aber (großes Aber): Liquid Glass ist kein Zwang.

Apple hat einen Opt-out-Flag in der App-Konfiguration eingebaut. Das neue Design-System lässt sich vollständig deaktivieren. UI bleibt unverändert, App bleibt vollständig iOS-26-konform [2].

Wer Liquid Glass aktiv einsetzen will, muss verstehen, was das bedeutet. Kein visuelles Update, systemischer Design-Change:

• Spacing & Dichte: HIG bevorzugt luftigere Ränder um gläserne Flächen. Hit-Areas bleiben min. 44×44 pt. Tab-Bar mit ultraThinMaterial + zusätzlichem Innenabstand für Labels [2].
• Komponenten-Priorisierung: NavBars, Bottom Bars, Sheets, Segmented Controls bekommen andere Ebenen. Content bleibt bewusst solide. Glas gehört in die Chrome, nicht auf Content.
• Tokens & States: Statt Hex-Werten Tokens für Farbe, Material, Elevation. States (hover/focus/pressed) brauchen eigene Opazitäten, sonst schwimmt die UI.
• Performance: Blur ist günstig, aber in Scrollern kritisch (Offscreen-Rendering). Materialflächen als Header/Footer in Listen, nicht pro Zelle.
• Accessibility ist Pflicht: Glas-Layer sind Kontrast-Fallen. Markenfarben können auf dynamischen Hintergründen die WCAG-Vorgabe von 4,5:1 verlieren [3]. Dynamic Type muss auf Materials funktionieren. „Transparenz reduzieren” muss respektiert werden. Dark Mode: Material-Tönungen wechseln.

Kurz: Wer Liquid Glass richtig macht, baut eine saubere Komponentenbibliothek mit Tokens und definierten States. Wer es halbherzig macht, kauft sich technische Schulden und Accessibility-Probleme.

Cross-Platform: realistische Einordnung

Viele Apps werden heute nicht mehr nativ gebaut. Was iOS 26 für Flutter, React Native oder Compose Multiplatform bedeutet, hängt sehr stark vom individuellen Framework ab.

React Native / .NET MAUI: Viele System-Materials werden automatisch über native Controls vererbt. Feinsteuerung, konsistente Elevation und komplexe Übergänge bleiben manuelle Arbeit.

Flutter / Compose Multiplatform: Eigene Renderer (z. B. Skia) bedeuten, dass Designelemente nachgebaut oder über externe Pakete eingebunden werden müssen. Flutter unterstützt Liquid Glass vorerst nicht offiziell. Teams sind auf Community-Lösungen angewiesen.

Der größere Kontext: Google setzt mit Material 3 Expressive eine ähnliche Richtung ein [5]. Was lange als Vorteil galt - ein gemeinsames Design für iOS und Android - wird zur Grundsatzfrage: Zwei eigenständige Designs? Cross-Platform mit bewussten Abstrichen? Die Antwort hängt von Business-Zielen, iOS-Anteil und Ressourcen ab. Aber die Frage muss gestellt werden, bevor mit der Implementierung begonnen wird.

Kurz: Je stärker vom nativen iOS-System entkoppelt, desto teurer wird Liquid Glass.

Entscheidungshilfe: Wann ein Audit sinnvoll ist

Audit jetzt angehen

• App wurde länger nicht angefasst und ein Update ist in den nächsten Monaten geplant.
• Viele Third-Party-Abhängigkeiten, einige davon älter.
• Consumer-App mit Store-Fokus, Featuring ist ein KPI.
• Rebranding oder Redesign ist ohnehin geplant, also lassen sich Aufwände bündeln.

Eher warten oder mit Opt-out arbeiten

• Internes B2B-Tool ohne Store-Fokus, kein Update geplant.
• Strikte Cross-Platform-Parity ist Pflicht.
• Kleines Team, UI-Schulden haben Priorität.

Klärt also am besten vorab: Wann soll das nächste Update eingereicht werden? Ist UIKit oder SwiftUI die Basis? Wie viele externe Bibliotheken sind im Einsatz? Die Antworten bestimmen die Dringlichkeit. Externe Agenturen können bei der Einschätzung auch behilflich sein.

Was ein iOS 26 Migration Audit liefert

Ein Migration Audit beantwortet drei Fragen: Was kompiliert? Was bricht? Was kostet es, es zu fixen? Das Ergebnis ist eine schriftliche Priorisierungsliste, keine Blackbox.

Phase 1 - Erster technischer Check (1-2 Tage)

Kompilierbarkeit mit iOS 26 SDK unter Xcode 18+. Dependency-Scan aller Third-Party-Bibliotheken. Erste Einschätzung zu deprecated API-Aufrufen und CI/CD-Kompatibilität. Nach ein bis zwei Tagen gibt es ein klares Bild: Läuft der Build durch, und wo liegen die größten Blocker?

Phase 2 - Deep Dive (2 weitere Tage)

Runtime-Tests auf aktuellen iOS-26-Geräten. Layout-Prüfung unter dem neuen Design-System. Liquid-Glass-Einschätzung: Opt-out ausreichend, oder gibt es strategische Gründe für eine aktive Integration? Accessibility-Check: Kontraste auf Materials, Dynamic Type, Reduce-Transparency-Fallbacks, Dark Mode. Swift-Concurrency-Analyse: Wo entstehen Build-Fehler und wie groß ist der Umfang?

Phase 3 - Priorisierung und Roadmap (2 weitere Tage)

Das eigentliche Deliverable: eine schriftliche Priorisierungsliste mit Aufwandsschätzung pro Maßnahme. Was blockiert den nächsten App-Store-Upload? Was muss vor dem nächsten Release erledigt sein? Was lässt sich bündeln?

Wer nur das Grundbild braucht, ist nach Phase 1 informiert. Eine vollständige Einschätzung mit Roadmap dauert bis zu einer Woche. Beides sind ehrliche Zeitrahmen - die ohne Blick in die Codebase nicht präziser angegeben werden können.

Fazit

iOS 26 Migration ist keine Krise. Sie ist eine Aufgabe. Wer den Unterschied zwischen „running on” und „building with” kennt, weiß sofort, ob und wie dringend Handlungsbedarf besteht. Wer dann strukturiert vorgeht, weiß nach Phase 1 in ein bis zwei Tagen, wo er steht.

Deprecated APIs, Third-Party-Abhängigkeiten, Liquid Glass — alle drei identifizierbar, alle drei lösbar. Der Opt-out-Flag gibt die Flexibilität, compliant zu werden, ohne ein Redesign-Projekt anzufangen, das gerade nicht passt.

Und wer noch nicht weiß, ob die App eher UIKit oder SwiftUI ist: Das ist die erste Frage, die gestellt werden sollte. Die Antwort bestimmt alles andere.

iOS 26 compliant? Appsolut.

Ihr wollt wissen, wo eure App steht? Wir schauen rein.

Discovery Call mit Christian buchen

Quellen

1. Apple Inc. (2026). App Store submission requirements. Apple Developer.

2. Apple Inc. (2026). Materials — Visual design — Human Interface Guidelines. Apple Developer.

3. World Wide Web Consortium. (2023). WCAG 2.2 success criterion 1.4.3: Contrast (minimum). W3C.

4. Apple Inc. (2026). Xcode 18 release notes. Apple Developer.

5. Google. (2025). Building with Material 3 Expressive. Material Design.