iOS-Interviews testen dein Verständnis vom Swift-Typsystem, von ARC und Speicherverwaltung sowie deine Fähigkeit, über UI-Zustand nachzudenken – und garantiert taucht mindestens eine Frage auf, bei der sich ein Retain-Cycle offen vor dir versteckt. Es folgen die am häufigsten gestellten Fragen, jede mit einer Musterantwort. Senior: Architektur, Trade-offs, Mentoring und Entscheidungsfindung.
Danach, wie komplex die App tatsächlich ist. Apples MVC reicht für einen Screen, der eine einzelne Sache anzeigt und bearbeitet; MVVM lohnt sich, wenn View-Zustand komplex genug ist, um ihn separat zu testen; eine unidirektionale Architektur zahlt sich aus, wenn Zustand über viele Screens geteilt wird und Bugs entstehen, weil er aus dem Takt gerät. Gleich die schwerste Lösung zu wählen kostet jahrelang Geschwindigkeit.
Erst messen – die Build-Timing-Übersicht zeigt, welche Dateien dominieren, meist eine Handvoll mit teurer Typinferenz. Dann: explizite Typen, wo Inferenz teuer ist, Modularisierung, damit eine Änderung nur ein Modul neu baut, und weniger Whole-Module-Optimierung im Debug-Build. Pauschale Ratschläge ohne Messung bewegen meist nichts.
Starte bei Häufigkeit und Gruppierung im Crash-Report – welche OS-Versionen, welche Geräte, welche App-Version und was der Nutzer gerade tat. Füge Breadcrumb-Logging um den vermuteten Pfad hinzu und ship es, denn der schnellste Weg, etwas Seltenes zu reproduzieren, ist, die betroffene Nutzergruppe zu instrumentieren. Einen Fix zu raten und zu shippen bringt nichts, wenn sich die Rate nicht ändert.
Lightweight Migration erledigt additive Änderungen automatisch; alles, was Daten transformiert, braucht ein Mapping-Model und einen getesteten Pfad von jeder Version, die noch im Umlauf ist. Was dabei oft vergessen wird: Nutzer überspringen Versionen – jemand aktualisiert von einem zwei Jahre alten Release, also muss die Migrationskette von jeder einzelnen funktionieren, nicht nur von der letzten.
Indem du davon ausgehst, dass alte Versionen unbegrenzt weiterleben: Die API muss abwärtskompatibel bleiben, Features, die eine Client-Änderung voraussetzen, brauchen ein serverseitiges Flag, und alles Entfernte muss von Clients toleriert werden, die es weiterhin aufrufen. Ein Kill Switch lohnt sich, bevor er gebraucht wird. Phased Rollout begrenzt den Schaden eines Fehlers, den du noch nicht gefunden hast.
Business-Logik und alles mit einer Regel – Preise, Validierung, State Machines – als Unit-Tests, weil sie schnell und stabil sind. Eine kleine Zahl von UI-Tests über die kritischen Pfade, die niemals brechen dürfen, im Wissen, dass sie langsam und gelegentlich flaky sind. Zu testen, dass ein Button blau ist, ist der Punkt, an dem Testsuiten zur reinen Wartungslast werden.
Im echten Interview sprichst du unter Druck. Cam stellt genau diese Fragen, bewertet jede Antwort und zeigt dir genau, was du verbessern musst.
Senior iOS (Swift)-Interview üben →