SwiftUI safe area stays offset after keyboard dismissal with “Reduce Motion” + “Prefer Cross-Fade” enabled (iOS 26)

Question

naschkatze OP

Created 6d

Replies 3

Boosts 2

Participants 2

I’m seeing a layout issue in SwiftUI on iOS 26 that only reproduces with specific Accessibility Motion settings.

Steps to reproduce 1. Open Settings → Accessibility → Motion.

2.	Enable Reduce Motion and Prefer Cross-Fade Transitions.

3.	Launch an app with a SwiftUI TextField.

4.	Tap the field to show the keyboard.

5.	Dismiss the keyboard (tap outside, swipe down, etc.).

Expected: After the keyboard is dismissed, the view’s bottom safe area / layout should return to normal.

Actual:

The view continues to reserve space equal to the keyboard height — as if the keyboard were still visible. UI anchored to the safe area remains shifted upward until the view is reloaded.

Boost

Answer 1

johans OP

2d

Seeing the same thing, here's a small reproduction:

import SwiftUI

struct ContentView: View {
    @State private var text = ""
    @FocusState private var isTextFocused
    @Environment(\.accessibilityReduceMotion) private var reduceMotion

    var body: some View {
        List {
            TextField("Input", text: $text)
                .focused($isTextFocused)
                .onSubmit {
                    isTextFocused.toggle()
                }
            Text("Focus the text field then dismiss the keyboard")
            Text("Observe how the safe area doesn't change when dismissing the keyboard in iOS 26 with the below accessibility settings enabled.")
            Label("Reduce Motion? \(reduceMotion ? "true": "false")", systemImage: "accessibility")
            Label(
                "Prefer Cross-Fade Transitions? \(UIAccessibility.prefersCrossFadeTransitions ? "true": "false")",
                systemImage: "accessibility"
            )
        }
        .scrollDismissesKeyboard(.immediately)
        .textFieldStyle(.roundedBorder)
        .border(.red)
        .safeAreaInset(edge: .bottom) {
            HStack {
                Text("This is in the safe area insets")
                Spacer()
                Button("Close Keyboard") {
                    isTextFocused.toggle()
                }
                .buttonStyle(.borderedProminent)
            }
            .padding()
            .border(.teal)
        }
    }
}

It also happens when you have a sheet open and with a focused textfield/visible keyboard and you call the DismissAction, then even the parent view gets the wrong safe area.

It's almost as if someone forgot to reset/update a value alongside the keyboard animation when the different "prefer cross-fade transitions" keyboard animation run.

0

Answer 2

johans OP

2d

Feedback FB20749624

0

Answer 3

johans OP

1d

One thing that makes this bug extremely annoying is that affects not only the view where the keyboard is presented, but also other views. This makes it difficult to come up with a workaround that works consistently as it affects multiple views in the hierachy.

As an example, I have a view that presents two sheets both with a button in the safeAreaInset (think filtering the content), sheet 2 has an input field that when has receives focus obviously triggers the bug (with the accessibility settings on), but it also messes with the safe area in sheet 1. Extremely infuriating!

0