SwiftUI Scroll Edge Effect: Soft vs. Hard und die Änderung in iOS 27

Bauen Sie eine App mit Xcode 27 neu, und ihre Navigationsleisten sehen womöglich plötzlich anders aus. Wo Inhalt früher sanft unter der Toolbar verblasste, gibt es jetzt eine feste Linie und ein massiveres Band. An Ihrem Code hat sich nichts geändert. Geändert hat sich der Standard des Scroll Edge Effect in SwiftUI, also der Behandlung, die iOS dort anwendet, wo scrollender Inhalt auf eine Bar trifft.

Dieser Leitfaden erklärt, was der Scroll Edge Effect ist, wie sich .soft und .hard unterscheiden, was sich zwischen iOS 26 und iOS 27 geändert hat und wie Sie in SwiftUI und UIKit den gewünschten Look wählen. Er basiert auf Apples Dokumentation und WWDC25-Sessions, der Antwort eines Apple-Ingenieurs in den Developer Forums und Berichten von Entwicklern, darunter @sarunw. Die Änderung in iOS 27 steht nicht in Apples Release Notes, behandeln Sie sie also als beobachtetes Verhalten, das sich zwischen Releases ändern kann.

Was ist der Scroll Edge Effect in SwiftUI?

Der Scroll Edge Effect kam in iOS 26 als Teil von Liquid Glass. Toolbars sitzen nicht mehr auf einem deckenden Hintergrund; ihre Elemente schweben über Ihrem Inhalt. Damit diese Elemente lesbar bleiben, behandelt das System den Inhalt, der unter ihnen scrollt. Apples WWDC25-Session Build a SwiftUI app with the new design nennt ihn einen dezenten Weichzeichner- und Verlaufseffekt für Inhalt unter System-Toolbars.

Unter System-Bars erhalten Sie ihn automatisch. Apple bittet darum, zusätzliche Hintergründe oder Abdunklungsebenen hinter Bar-Elementen zu entfernen, weil sie den Effekt stören. Auch eigene Bars können mitmachen: SwiftUIs safeAreaBar(edge:alignment:spacing:content:), neu in iOS 26, zeigt Inhalt als eigene Bar neben einer View, und Scroll Views darunter erhalten einen Edge Effect wie unter einer System-Bar.

Sie steuern den Effekt mit scrollEdgeEffectStyle(_:for:), ebenfalls neu in iOS 26. Der Modifier gilt für Scroll Views überall innerhalb der View, die Sie modifizieren, Sie können ihn also an einen Container statt an jede einzelne Scroll View setzen.

Was ist der Unterschied zwischen .soft und .hard?

ScrollEdgeEffectStyle hat drei Werte. Apple definiert sie so:

Apples eigenes Beispiel für eine dichte Oberfläche ist die Kalender-App. In der UIKit-Fassung der Session sagt Apple, der harte Stil ähnle den Standard-Bar-Hintergründen aus iOS 18. Hier das Beispiel aus der SwiftUI-Session:

ScrollView {
    // Inhalt
}
.scrollEdgeEffectStyle(.hard, for: .top)

Warum sieht der Scroll Edge Effect in iOS 27 anders aus?

Zwei Dinge haben sich geändert, und man verwechselt sie leicht.

Der Standard hat sich geändert. @sarunw fasst es zusammen: In iOS 26 ist der Standard des Scroll Edge Effect .soft, in iOS 27 .hard. Entwickler sahen dasselbe in ihren eigenen Apps. Das Projekt Shellbee meldete einen Bug, als Bars in der gesamten App nach einem iOS-27-Build flach wurden, und DevelopersIO stellte dasselbe für eine eigene safeAreaBar fest. Genau genommen ist der Standard weiterhin .automatic; geändert hat sich, wozu er aufgelöst wird. DevelopersIO berichtet außerdem, dass eine mit Xcode 26.6 gebaute und unter iOS 27 ausgeführte App den alten Look behielt, die Änderung folgt also dem SDK, mit dem Sie bauen. Der Autor fand keinen Hinweis in den Release Notes von iOS 27 oder Xcode 27.

Die Stile selbst haben sich geändert. @sarunw merkt an, dass .hard in beiden Versionen nicht gleich ist. In iOS 26 ist es fast eine massive Bar, und Text dahinter ist unlesbar. In iOS 27 bleibt die Trennlinie, aber Inhalt scheint weiterhin durch. Im Dark Mode beschreibt er dieselbe Aufteilung: .soft verblasst, .hard schneidet ab, und der Stil in iOS 27 wirkt ausgewogener. Apple hat auch .soft geändert. In den Developer Forums schrieb ein Apple-Ingenieur, dass sich der .soft-Stil in iOS 27 erheblich verändert hat.

Warum der Wechsel? Apple hat sich öffentlich nicht dazu geäußert. Dieselbe Forenantwort merkt an, dass viele Apps .soft explizit gewählt haben, wo .automatic angemessener gewesen wäre, und dass .soft nicht der Standard des Betriebssystems ist.

Wie hole ich den Scroll-Edge-Verlauf aus iOS 26 in iOS 27 zurück?

Wenn Ihr Design vom Verlauf abhängt, fordern Sie ihn an. Die Lösung von @sarunw ist ein einziger Modifier:

List(items) { item in
    ItemRow(item: item)
}
.scrollEdgeEffectStyle(.soft, for: .top)

Wenn Sie noch Versionen vor iOS 26 unterstützen, verpacken Sie ihn in eine Verfügbarkeitsprüfung, damit Sie ihn überall mit einem Aufruf anwenden können:

extension View {
    @ViewBuilder
    func softTopScrollEdge() -> some View {
        if #available(iOS 26.0, *) {
            scrollEdgeEffectStyle(.soft, for: .top)
        } else {
            self
        }
    }
}

Drei Einschränkungen. Erstens merkt der Fix von Shellbee an, dass ein am App-Root gesetzter Stil NavigationStacks, die als Sheets oder Full-Screen Covers präsentiert werden, nicht erreichte; wenden Sie ihn also in jedem davon an. Zweitens ist „zurück“ nicht exakt: Da .soft in iOS 27 neu gestaltet wurde, erhalten Sie den weichen Look von iOS 27, keine pixelgenaue Kopie von iOS 26. Drittens empfiehlt Apples Ingenieur .automatic überall dort, wo es Ihren Designanforderungen genügt, und weist darauf hin, dass .soft nicht zu jedem Design passt.

Außerdem gab es einen Kompatibilitätsfehler. Ein Thread in den Developer Forums berichtete, dass .soft in iOS-27-Betas über einer safeAreaBar vollständig transparent dargestellt wurde, aber nur in Apps, die mit dem iOS 26 SDK gebaut waren. Apple sagte, iOS 27.2 werde den neuen .soft-Stil für diese Apps verfügbar machen, und ein späterer Beitrag im Thread meldet den Fehler in iOS 27.2 Beta 4 als behoben. Wenn Sie einen gegen iOS 26 gelinkten Build ausliefern, prüfen Sie ihn unter iOS 27.2.

Wie setze oder verberge ich den Scroll Edge Effect für eine Kante?

Der zweite Parameter von scrollEdgeEffectStyle(_:for:) ist ein Edge.Set, Sie wählen also, für welche Kanten ein Stil gilt: eine Kante, mehrere oder .all. Der Fix von DevelopersIO für die eigene untere Bar zielt nur auf diese Kante:

ScrollView {
    DayList()
}
.scrollEdgeEffectStyle(.soft, for: .bottom)
.safeAreaBar(edge: .bottom) {
    DayPicker()
}

Der Autor merkt an, dass der Modifier wie hier an einer äußeren View sitzen kann, die die Scroll View umschließt.

Um den Effekt zu entfernen, verwenden Sie scrollEdgeEffectHidden(_:for:), neu in iOS 26. Beide Parameter haben Standardwerte, der Modifier ohne Argumente verbirgt also jede Kante:

ScrollView {
    PhotoGrid()
}
.scrollEdgeEffectHidden(true, for: .bottom)

Verbergen Sie ihn nur, wenn über dieser Kante nichts Angeheftetes liegt oder Ihr eigenes Design die Steuerelemente bereits lesbar hält. Sonst landen Glas-Buttons über unbehandeltem Inhalt.

Wie ändere ich den Scroll Edge Effect in UIKit?

UIKit hat dasselbe Modell, ebenfalls neu in iOS 26. Jede UIScrollView stellt topEdgeEffect, bottomEdgeEffect, leftEdgeEffect und rightEdgeEffect bereit. Jede davon ist ein UIScrollEdgeEffect mit einem style von .automatic, .soft oder .hard und einem Flag isHidden, das standardmäßig false ist.

tableView.topEdgeEffect.style = .soft
collectionView.bottomEdgeEffect.isHidden = true

Für eigene Views über der Kante einer Scroll View, etwa eine Reihe von Buttons, verwendet Apples Session Build a UIKit app with the new design die UIScrollEdgeElementContainerInteraction. Untergeordnete Views des Containers wie Labels, Bilder und Steuerelemente formen dann den Edge Effect.

let interaction = UIScrollEdgeElementContainerInteraction()
interaction.scrollView = scrollView
interaction.edge = .bottom
buttonContainer.addInteraction(interaction)

Die meisten Berichte über die geänderte Standardeinstellung in iOS 27 stammen aus SwiftUI-Projekten, und im oben genannten Forenthread sieht auch ein UIKit-Entwickler den .soft-Fehler. Prüfen Sie UIKit-Screens also ebenfalls unter iOS 27, statt anzunehmen, dass sie nicht betroffen sind.

Wie funktioniert der Scroll Edge Effect mit der vertikalen Bar des iPhone Duo?

Auf dem iPhone Duo verschieben Apps, die mit dem iOS 27.1 SDK gebaut sind, Navigations- und Toolbar-Elemente in eine vertikale Bar entlang einer Seitenkante. Apples Tech Talk Raise the bar with iPhone Duo sagt, dass eine vertikale Bar standardmäßig keinen Scroll Edge Effect hat, genau wie horizontale Bars, und dass sie einen Hintergrund erhält, wenn „Transparenz reduzieren“ aktiviert ist. Apple bittet darum, eigene Views in der Bar in beiden Fällen lesbar zu halten. Unser Leitfaden zur vertikalen Toolbar auf dem iPhone Duo erklärt, wann Bars vertikal werden.

Apple dokumentiert nicht, wie scrollEdgeEffectStyle mit .leading oder .trailing mit der vertikalen Bar zusammenspielt, bauen Sie dort also nicht auf Annahmen. Im Hochformat des inneren Displays bleiben die Bars horizontal, ein Stil für .top zählt also auf demselben Gerät, das im Querformat eine vertikale Bar zeigt. Prüfen Sie beide Ausrichtungen und halten Sie Inhalt mit den richtigen Safe Areas und Content Margins von der Bar fern.

Die wichtigsten Punkte

• Der Scroll Edge Effect, neu in iOS 26, hält Liquid-Glass-Bars über scrollendem Inhalt lesbar. Setzen Sie ihn mit scrollEdgeEffectStyle(_:for:) und verbergen Sie ihn mit scrollEdgeEffectHidden(_:for:).
• .soft ist eine weichgezeichnete Grenze und .hard eine nahezu deckende; Apple empfiehlt .hard für dichte Oberflächen.
• Entwickler berichten, dass iOS-27-Builds den automatischen Effekt oben zu .hard auflösen, und beide Stile sehen in iOS 27 anders aus.
• Um einen Verlauf zu behalten, wenden Sie .scrollEdgeEffectStyle(.soft, for: .top) an, auch innerhalb modaler NavigationStacks.
• In UIKit verwenden Sie topEdgeEffect.style und isHidden an jeder Kante einer UIScrollView.
• Auf dem iPhone Duo haben vertikale Bars standardmäßig keinen Scroll Edge Effect, prüfen Sie also beide Ausrichtungen.

Mehr dazu, wie Toolbars in iOS 26 ihre Elemente gruppieren und gestalten, lesen Sie in unserem Leitfaden zur SwiftUI-Toolbar mit Liquid Glass. Apps und Spiele, die das Gerät bereits optimal nutzen, finden Sie unter Built for the fold.