IOS-Interviewfragen

Welches Problem lösen Optionals, und wie entpackst du eines sicher?

Ein Optional macht "dieser Wert kann fehlen" zu einem Teil des Typs, sodass der Compiler dich zwingt, den leeren Fall zu behandeln, statt zur Laufzeit abzustürzen wie bei einem Null-Pointer. Sicheres Entpacken bedeutet if let oder guard let für einen Wert, den du im weiteren Verlauf brauchst, Nil-Coalescing (??) für einen Standardwert und optionales Chaining, wenn dich nur der Erfolgsfall interessiert. Force Unwrapping mit ! ist ein Versprechen an den Compiler, dass der Wert existiert – akzeptabel bei Outlets und Programmierfehlern, aber niemals bei Netzwerkdaten.

Was ist der Unterschied zwischen struct und class in Swift? Womit fängst du standardmäßig an?

Structs sind Werttypen: Eine Zuweisung kopiert sie, sie können nicht erben und werden nach Möglichkeit auf dem Stack alloziert. Classes sind Referenztypen mit Identität, Vererbung, deinit und ARC-Overhead. Die Swift-Konvention ist, mit einem struct zu starten und erst dann zu einer class zu greifen, wenn du Referenzsemantik brauchst – gemeinsam genutzter veränderlicher Zustand, Objective-C-Interoperabilität oder ein Lebenszyklus, den du beobachten musst.

Wie funktioniert ARC, und wodurch entsteht ein Retain-Cycle?

ARC zählt, wie viele starke Referenzen auf ein Objekt zeigen, und gibt es frei, sobald der Zähler null erreicht – das sind zur Kompilierzeit eingefügte retain/release-Aufrufe, kein Garbage Collector zur Laufzeit. Ein Retain-Cycle entsteht, wenn zwei Objekte gegenseitig starke Referenzen aufeinander halten, sodass keiner der Zähler je null erreicht: klassisch ist ein View Controller, der eine Closure besitzt, die self stark einfängt. Aufgelöst wird das mit [weak self] oder [unowned self] in der Capture List.

Wann verwendest du weak, wann unowned?

Beide erhöhen den Retain-Count nicht. weak macht die Referenz optional und setzt sie auf nil, sobald das Objekt deallokiert wird – sicher also, wenn das andere Objekt womöglich zuerst stirbt, wie es bei Delegates der Standardfall ist. unowned ist nicht optional und geht davon aus, dass das referenzierte Objekt dich überlebt; stimmt diese Annahme nicht, stürzt die App ab. Nutze unowned nur, wenn die Lebenszeitbeziehung wirklich garantiert ist, und weak, sobald du dir nicht sicher bist.

Was ist der Unterschied zwischen @State, @Binding, @StateObject und @ObservedObject?

@State ist lokaler, der View gehörender Zustand vom Werttyp; SwiftUI speichert ihn außerhalb der Struct, damit er Neuzeichnungen übersteht. @Binding ist eine lesbare und schreibbare Referenz auf Zustand, der jemand anderem gehört – so kann eine Kind-View den Wert des Parents ändern. @StateObject erstellt und besitzt ein observable Objekt vom Referenztyp und wird genau einmal initialisiert. @ObservedObject beobachtet ein Objekt, das anderswo besessen wird – setzt du es dort ein, wo eigentlich @StateObject gebraucht wird, wird das Objekt bei jeder Neuzeichnung neu erzeugt und verliert seinen Zustand stillschweigend.

Wie entscheidet SwiftUI, ob eine View neu gerendert wird?

Eine View ist eine leichtgewichtige Struct, die die UI beschreibt; SwiftUI baut ihren body immer dann neu auf, wenn sich eine gelesene Abhängigkeit ändert, vergleicht das Ergebnis dann mit dem vorherigen Baum und wendet nur die Unterschiede auf das zugrunde liegende Rendering an. Abhängigkeiten sind die Property Wrapper, die eine View tatsächlich liest, plus die Environment. Performance-Probleme entstehen fast immer dadurch, dass Zustand zu weit oben im Baum platziert ist, sodass eine unabhängige Änderung einen großen Teilbaum invalidiert.

Was ändert async/await im Vergleich zu Completion Handlern und GCD?

async/await lässt sich asynchroner Code von oben nach unten lesen, sodass Fehlerbehandlung mit ganz normalem try/catch funktioniert und es weder eine "Pyramide des Grauens" noch einen vergessenen Completion-Pfad gibt. Der Compiler erzwingt, dass await nur in einem async-Kontext vorkommt, und Structured Concurrency bindet die Lebensdauer von Kind-Tasks an den Parent, sodass sich eine Cancellation automatisch durchsetzt. GCD bleibt relevant für Legacy-Code und feingranulare Queue-Kontrolle, aber neuer Code sollte standardmäßig async/await nutzen, während Combine echten Strömen von Werten über die Zeit vorbehalten bleibt.

Was ist eine escaping Closure, und warum gibt es dieses Keyword?

Eine Closure ist escaping, wenn sie gespeichert und erst aufgerufen wird, nachdem die Funktion bereits zurückgekehrt ist – zum Beispiel ein Completion Handler eines Netzwerkaufrufs. Swift verlangt die @escaping-Annotation, weil eine non-escaping Closure aggressiver optimiert werden kann und self nicht versehentlich stark einfangen kann. Die Annotation ist gleichzeitig das Signal, über Capture-Semantik nachzudenken: Genau in escaping Closures entstehen Retain-Cycles.

Erkläre den UIViewController-Lifecycle. Wo platzierst du Layout-Code?

viewDidLoad läuft einmalig, nachdem die View-Hierarchie geladen ist, und ist der Ort für einmaliges Setup. viewWillAppear und viewDidAppear laufen bei jeder Präsentation und eignen sich für Arbeit, die sich wiederholen muss, etwa Daten neu laden oder eine Animation starten. Layout, das von den finalen Frame-Größen abhängt, gehört in viewDidLayoutSubviews, weil die Bounds in viewDidLoad noch nicht final sind – Frame-Berechnungen dort zu platzieren ist ein sehr häufiger Fehler, der sich erst bei einer anderen Bildschirmgröße zeigt.

Wie entscheidest du zwischen Core Data, SwiftData und einfachen Dateien?

Core Data rechtfertigt seine Komplexität, wenn du relationale Daten hast und Queries, Faulting sowie Change Tracking über einen großen Objektgraphen brauchst. SwiftData ist der moderne, Swift-native Wrapper über demselben Stack und für neue Apps auf aktuellen OS-Versionen die Standardwahl. Für eine Handvoll Einstellungen reicht UserDefaults; für einen Cache dekodierter Modelle sind einfache Codable-Dateien oder ein leichtgewichtiger Key-Value-Store weit einfacher zu durchschauen als ein vollwertiger Persistent Container.

Wie diagnostizierst du einen langsamen App-Start oder ein Memory Leak?

Für die Startzeit nutzt du das App-Launch-Template in Instruments, um zu sehen, was vor dem ersten Frame läuft; die üblichen Übeltäter sind synchrone Disk- oder Netzwerkarbeit in didFinishLaunching und schwere, eifrig aufgebaute Dependency-Graphen. Für Leaks zeigt der Memory Graph Debugger Objekte, die eigentlich deallokiert sein sollten, und wer noch auf sie zeigt – das legt Retain-Cycles direkt offen. Das Leaks-Instrument fängt klassische Leaks ab, aber der Graph ist bei Zyklen besser, weil er die haltende Referenz benennt.

Was testest du auf iOS, und was testest du bewusst nicht?

Unit-Tests decken Business-Logik, View Models und reine Transformationen ab – alles mit Ein- und Ausgabe und ohne UIKit-Abhängigkeit. XCUITest deckt eine kleine Zahl kritischer End-to-End-Flows ab, etwa Login und Kauf, weil UI-Tests in großer Zahl langsam und instabil sind. Was sich meist nicht lohnt, ist das Testen von Apples Framework-Verhalten und pixelgenauem Layout; Snapshot-Tests können dabei helfen, brechen aber bei jedem OS-Versionssprung, deshalb hält man sie wenige und bewusst eingesetzt.