Auto Layout: Was ist es, adaptives Layout von iOS-Oberflächen

Was ist Auto Layout?

Auto Layout ist Apples adaptives Layout-System, das mathematische Einschränkungen (constraints) zur Positionierung von UI-Elementen verwendet. Im Gegensatz zum frame-basierten Layout, bei dem jedes Element feste Koordinaten x, y, width, height hat, beschreibt Auto Layout Beziehungen zwischen Elementen: «der Button befindet sich 8pt vom rechten Rand des Eltern-Elements» oder «die Breite des Textfelds entspricht der halben Bildschirmbreite». Der Mechanismus basiert auf dem Cassowary-Algorithmus, entwickelt an der University of Washington (Greg J. Badros, 1999) und implementiert von Apple in iOS 6. Cassowary löst ein System linearer Ungleichungen mit Prioritäten — Required (1000), Default High (750), Default Low (250) — und ermöglicht so die Verwaltung von Constraint-Konflikten. Auto Layout unterstützt drei Größentypen: intrinsic (natürliche Größe des Elements, bestimmt durch den Inhalt), explicit (explizit festgelegte Einschränkung) und compressible/stretchable (elastischer Modus durch Content Hugging Priority und Compression Resistance Priority).

Intrinsic Content Size und Prioritäten

Jedes UI-Element in Auto Layout hat eine Intrinsic Content Size — eine natürliche Größe, die durch seinen Inhalt bestimmt wird. Bei UILabel hängt dies von Text und Schriftart ab, bei UIImageView von den Bildabmessungen. Content Hugging Priority (Widerstand gegen Dehnung) und Compression Resistance Priority (Widerstand gegen Stauchung) steuern das Verhalten des Elements bei Änderung des verfügbaren Platzes. Standardwerte: 251 für hugging und 749 für compression resistance. Wenn zwei Elemente um Platz konkurrieren, bestimmt die Priorität, welches zuerst gedehnt wird. Das Verständnis dieser Prioritäten ist der Schlüssel zur Behebung von Ambiguous Layout (mehrdeutigem Layout), das Xcode im Debugger hervorhebt.

Anatomie eines Constraints

Ein Constraint wird durch die Gleichung beschrieben: view1.attribute = multiplier × view2.attribute + constant. Zu den Attributen gehören leading, trailing, top, bottom, centerX, centerY, width, height, firstBaseline, lastBaseline. Multiplier wird für proportionale Beziehungen verwendet (Breite von view1 = 0.5 × Breite von superview). Constant legt einen festen Versatz fest (leading = superview.leading + 16). Interface Builder-Tools ermöglichen die visuelle Erstellung von Constraints per Strg-Ziehen, aber komplexe Layouts erfordern eine programmgesteuerte Erstellung über NSLayoutConstraint oder VFL (Visual Format Language), die Apple seit iOS 9 durch NSLayoutConstraint ersetzt empfiehlt.

Wie Constraints in iOS funktionieren

Das Constraint-System wird als lineares Programmierproblem gelöst: Der Cassowary-Algorithmus findet die optimale Anordnung aller Elemente, die alle Einschränkungen unter Berücksichtigung ihrer Prioritäten erfüllt. Wenn Constraints sich widersprechen, tritt ein Unsatisfiable Layout auf — eine Ausnahme, die Xcode mit einer detaillierten Konfliktbeschreibung protokolliert. Wenn nicht genügend Constraints zur Bestimmung der Position mindestens eines Elements vorhanden sind, tritt Ambiguous Layout auf — Elemente werden an beliebigen Positionen angezeigt. Apple empfiehlt einen Mindestsatz: Für jedes Element müssen position (x, y) und size (width, height) festgelegt werden — explizit oder über intrinsic content size. Constraints können erstklassig sein: Das führende Element (z. B. superview) und das folgende (untergeordnete View) bilden eine Hierarchie.

Cassowary-Algorithmus und Prioritäten

Cassowary verwendet die Sequential Quadratic Programming-Methode zur Lösung von Systemen linearer Ungleichungen. Jeder Constraint hat eine Priorität von 1 bis 1000. Required (1000) ist eine zwingende Einschränkung; wenn sie nicht erfüllt werden kann, stürzt die App mit NSConstraintException ab. Default High (750) ist empfohlen; Default Low (250) ist am wenigsten wichtig. Bei einem Konflikt lockert Cassowary die Einschränkungen mit niedrigerer Priorität. Wenn beispielsweise zwei Elemente eine feste Breite benötigen, der Bildschirm jedoch zu schmal ist, wird der Constraint mit niedrigerer Priorität gelockert. In Xcode Debug View Hierarchy (Debugging-Tool, verfügbar seit Xcode 6) werden nur Probleme mit Required-Constraints hervorgehoben — andere werden fehlerfrei behandelt.

UIStackView: automatische Verwaltung von Constraints

UIStackView ist ein Container, der in iOS 9 (2015) eingeführt wurde und automatisch Constraints für verschachtelte arrangedSubviews erstellt und verwaltet. UIStackView unterstützt zwei Achsen: horizontal und vertikal. Die distribution-Einstellungen bestimmen die Platzverteilung: fill (proportionale Füllung entsprechend hugging priority), fillEqually (gleiche Größen), fillProportionally (proportional zur intrinsic content size), equalSpacing (gleiche Abstände), equalCentering (gleiche Abstände zwischen Mittelpunkten). Alignment legt die Ausrichtung quer zur Achse fest: fill, leading, center, trailing (für horizontal) oder fill, top, center, bottom (für vertikal). UIStackView verwaltet automatisch Abstände, Basislinienausrichtung und Dynamic-Type-Anpassung.

import UIKit

class StackViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let stack = UIStackView()
        stack.axis = NSLayoutConstraint.Axis.vertical
        stack.distribution = .fillEqually
        stack.spacing = 8
        stack.translatesAutoresizingMaskIntoConstraints = false
        
        let label = UILabel()
        label.text = "Auto Layout Guide"
        label.font = UIFont.preferredFont(forTextStyle: .headline)
        
        let button = UIButton(type: .system)
        button.setTitle("Apply", for: .normal)
        
        stack.addArrangedSubview(label)
        stack.addArrangedSubview(button)
        view.addSubview(stack)
        
        NSLayoutConstraint.activate([
            stack.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            stack.centerYAnchor.constraint(equalTo: view.centerYAnchor),
            stack.leadingAnchor.constraint(greaterThanOrEqualTo: view.leadingAnchor, constant: 16),
            stack.trailingAnchor.constraint(lessThanOrEqualTo: view.trailingAnchor, constant: -16)
        ])
    }
}

Der Code erstellt einen vertikalen UIStackView mit zwei Elementen (UILabel und UIButton), gleichmäßig verteilt (fillEqually) mit 8pt Abstand. Der Stack wird auf dem Bildschirm zentriert mit einem Mindestabstand von 16pt zu den Rändern. translatesAutoresizingMaskIntoConstraints = false ist bei der programmgesteuerten Erstellung von Constraints erforderlich — ohne ihn funktioniert Auto Layout nicht. Bei IT Sectr wird UIStackView in 80% der iOS-Projektbildschirme zur Erstellung adaptiver Formulare, Einstellungslisten und Karten verwendet.

Verschachtelte Stack Views

UIStackViews können verschachtelt werden: ein horizontaler Stack innerhalb eines vertikalen ist ein Standardmuster für komplexe Layouts. Der äußere Stack verwaltet Zeilen, der innere Stack verwaltet Spalten innerhalb jeder Zeile. Die Kombination von axis, alignment und distribution auf jeder Ebene bietet praktisch unbegrenzte Flexibilität ohne eine einzige manuelle Einschränkung. Apple empfiehlt UIStackView als primäres Layout-Werkzeug in UIKit und greift nur in Fällen, die nicht von Stacks abgedeckt werden, auf manuelle NSLayoutConstraint zurück: überlappende Views, präzise Pixelpositionierung, benutzerdefinierte bounds-Animation.

NSLayoutConstraint: programmgesteuerte Erstellung von Einschränkungen

NSLayoutConstraint ist eine programmgesteuerte API zur Erstellung einzelner Einschränkungen im Code. Jeder Constraint wird über einen Initialisierer mit Parametern erstellt: item, attribute, relatedBy, toItem, attribute, multiplier, constant. Seit iOS 9 hat Apple die Anchor API eingeführt — eine lesbarere Syntax über die Eigenschaften view.leadingAnchor, view.trailingAnchor, view.topAnchor, view.bottomAnchor, view.centerXAnchor, view.centerYAnchor, view.widthAnchor, view.heightAnchor. Die Anchor API setzt automatisch relatedBy = .equal und verwendet First Item/Second Item aus den Anchors, wodurch der Code im Vergleich zu klassischem NSLayoutConstraint um 40% reduziert wird.

import UIKit

class ConstraintViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let childView = UIView()
        childView.backgroundColor = .systemBlue
        childView.translatesAutoresizingMaskIntoConstraints = false
        view.addSubview(childView)
        
        NSLayoutConstraint.activate([
            childView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 24),
            childView.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 16),
            childView.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -16),
            childView.heightAnchor.constraint(equalToConstant: 120),
            childView.bottomAnchor.constraint(lessThanOrEqualTo: view.bottomAnchor, constant: -24)
        ])
    }
}

Der Code positioniert childView mit Abständen von safeAreaLayoutGuide (top) und den Bildschirmrändern (leading/trailing). lessThanOrEqualTo für bottom stellt sicher, dass die View die untere Grenze nicht überschreitet. Die Anchor API löst eine Kompilierungszeitausnahme aus, wenn Anker inkompatibel sind (z. B. leadingAnchor gemischt mit rightAnchor), was Laufzeitfehler verhindert. Apple empfiehlt die Anchor API als Standard für programmgesteuertes Auto Layout seit iOS 9.

Safe Area und Layout Margins in Auto Layout

Safe Area ist der Bildschirmbereich, der nicht von Systemelementen — Dynamic Island, Notch, Status Bar, Home Indicator, abgerundeten Ecken — überdeckt wird. In iOS 11 ersetzte Apple topLayoutGuide/bottomLayoutGuide durch safeAreaLayoutGuide, der sich automatisch an die Geräteausrichtung und das Vorhandensein von Bildschirmausschnitten anpasst. Layout Margins sind standardmäßige interne View-Abstände (16pt unter iOS, 20pt unter iPadOS). Für UILayoutGuide können benutzerdefinierte directionalLayoutMargins unter Berücksichtigung der RIGHT-TO-LEFT-Lokalisierung festgelegt werden. Auto Layout respektiert automatisch die Safe Area bei Verwendung von safeAreaLayoutGuide in Ankern.

Anpassung an Dynamic Island und Notch

Bei Geräten mit Dynamic Island (iPhone 14 Pro und neuer) und Notch (iPhone X–13) schließt die Safe Area oben 44pt im Hochformat aus (59pt mit Dynamic Island im aktiven Zustand). Home Indicator fügt unten 34pt hinzu. Für eine korrekte Anpassung sollten alle oberen Constraints an safeAreaLayoutGuide.topAnchor und nicht an view.topAnchor gebunden werden. Untere Constraints sollten an safeAreaLayoutGuide.bottomAnchor oder view.bottomAnchor mit einem Abstand für Home Indicator gebunden werden. Bei IT Sectr testen wir alle Bildschirme auf den Simulatoren iPhone SE (2022), iPhone 14 Pro Max und iPad Pro 12.9″ — drei Geräte, die alle Safe-Area-Varianten abdecken.

Häufige Auto-Layout-Fehler

Die häufigsten Fehler bei der Arbeit mit Auto Layout: vergessenes translatesAutoresizingMaskIntoConstraints = false, widersprüchliche Required-Constraints (Priorität 1000), Ambiguous Layout (unzureichende Constraints zur Positionsbestimmung), falsche Content Hugging Priority für mehrzeilige UILabel und Vermischung von leading/trailing mit left/right-Ankern. Xcode 15+ zeigt Layout-Probleme im Runtime Issue Navigator an und bietet automatische Korrekturen. Für komplexe Layouts verwenden Sie Debug View Hierarchy: gelbe Markierungen zeigen ambiguous layout, rote unsatisfiable an.