Middle iOS (Swift) — IOS-Interviewfragen

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

@State ist ein Wert, den eine View besitzt und verändert. @Binding ist eine Referenz auf den @State von jemand anderem, nach unten gereicht, damit eine Kind-View schreiben kann. @ObservedObject beobachtet einen Referenztyp, der Änderungen published, und wird anderswo besessen. Der verwandte Fehler ist @ObservedObject, wo eigentlich @StateObject nötig wäre – das Objekt wird dann bei jeder Neuzeichnung neu erzeugt.

Wie unterscheidet sich `async/await` von Completion Handlern?

Beide drücken dieselbe Suspendierung aus, aber await hält den Code linear, und Fehler wandern über throws statt über einen Fehlerparameter, den man vergessen kann zu prüfen. Der Compiler erzwingt zudem Structured Concurrency: Die Kinder eines Tasks werden mit ihm zusammen abgebrochen. Die Migrationsfalle ist der Aufruf einer async-Funktion aus synchronem Kontext, wofür ein explizites Task nötig ist.

Was garantiert `@MainActor`?

Dass der annotierte Code auf dem Main Thread läuft – geprüft vom Compiler, nicht nur per Konvention. UI-Arbeit muss auf dem Main Thread laufen, und vor Actors war das eine Laufzeit-Assertion, die man durch einen Absturz entdeckte. Eine View-Model mit @MainActor zu markieren ist meist einfacher, als an jeder Aufrufstelle zu dispatchen.

Warum braucht es `reuseIdentifier`, und was geht ohne sorgfältige Wiederverwendung kaputt?

Weil eine Table- oder Collection-View nur einen kleinen Pool an Zellen vorhält und diese beim Scrollen neu bindet, statt eine pro Zeile zu allozieren. Kaputt geht Zustand, der von der vorherigen Nutzung an der Zelle hängen bleibt – ein Bild aus Zeile drei taucht plötzlich in Zeile vierzig auf. prepareForReuse und das Abbrechen laufender Bildanfragen sind die Fixes.

Wie findest du die Ursache eines Memory Leaks auf iOS?

Der Memory Graph Debugger zeigt, was noch lebt und wer es hält – das benennt den Zyklus meist direkt. Leaks und Allocations in Instruments beantworten dieselbe Frage über die Zeit. Häufige Übeltäter sind Closures, die self stark einfangen, ein als strong statt weak deklariertes Delegate und nie entfernte Observer.

Wie hältst du das Scrollen flüssig?

Nichts Teures auf dem Main Thread während des Scrollens: Bilder abseits des Main Threads dekodieren, das dekodierte Ergebnis cachen statt der Rohdaten, und Layout vermeiden, das bei jedem Frame neu berechnet wird. Off-Screen-Rendering durch Schatten und Masken ist der leise Übeltäter – ein Corner Radius mit masksToBounds auf vielen Zellen kostet mehr, als es aussieht.

Wie behandelst du Fehler in der Netzwerkschicht sinnvoll?

Modelliere sie: ein typisierter Fehler, der zwischen fehlender Konnektivität, einem 5xx vom Server, einem selbstverschuldeten 4xx und einem Decoding-Fehler unterscheidet – denn jeder verdient eine eigene Meldung und eine eigene Retry-Policy. Einen 400er endlos zu wiederholen ist der Fehlerfall. Decoding-Fehler sollten in der Entwicklung besonders laut sein und niemals still verschluckt werden.