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

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.

Feedback FB20749624

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!

Has this been solved? I am having exactly the same behaviour.

Same stale inset here, with a trigger that needs no accessibility settings: a rotation while a plain TextField is focused. Filed as FB24706384 with a 37-line repro project (no third-party code).

Steps, starting in portrait:

1. Root screen has .safeAreaInset(edge: .bottom) with a bar.
2. Push a screen with a TextField and focus it (portrait keyboard, 335 pt).
3. Rotate to landscape - the keyboard re-shows at the landscape height (208 pt).
4. Go back while still in landscape.
5. Rotate to portrait. Layout is correct at this point.
6. Background the app, then foreground it.

Three things that line up with what you describe:

• UIWindow.safeAreaInsets.bottom and rootViewController.view.safeAreaInsets.bottom stay correct the whole time (34 portrait, 20 landscape). Only SwiftUI's view-level inset is wrong.
• The keyboard was hidden with a well-formed notification at 14.68, and the value SwiftUI later installs is that notification's height - in the orientation that is no longer current.
• The bad value is installed on didEnterBackground, not on foreground.

Two workarounds that measured clean here, since the thread has none:

1. Remove .keyboard from UIHostingController.safeAreaRegions whenever no keyboard is presented and restore it on keyboardWillShow. This keeps automatic keyboard avoidance working, and it also fixed a second variant we hit through an SFSafariViewController keyboard. Gate the removal on there being no first responder: when foregrounding back onto an editing screen, keyboardWillShow arrives before sceneDidBecomeActive, so removing it unconditionally breaks avoidance.
2. .ignoresSafeArea(.keyboard, edges: .bottom) - but only applied outside .safeAreaInset. Applied before the inset, on the inset's own content, or on the NavigationStack, the bug remains, which makes the modifier look ineffective. That one cost us a while.

Does your case also survive a background/foreground cycle once the safe area is offset? If it does, this looks like one defect with (at least) three entry points - yours, this one, and FB20386257, where an out-of-process WebView keyboard leaves the same inset behind.

import SwiftUI

@main
struct ReproApp: App {
    var body: some Scene { WindowGroup { RootView() } }
}

struct RootView: View {
    var body: some View {
        NavigationStack {
            ZStack {
                Color.red.ignoresSafeArea()
                NavigationLink("Open details") { DetailsView() }
                    .buttonStyle(.borderedProminent)
            }
            .safeAreaInset(edge: .bottom, spacing: 0) {
                Text("Bottom label")
                    .frame(maxWidth: .infinity)
                    .padding(.vertical, 12)
                    .background(.blue)
            }
        }
    }
}

struct DetailsView: View {
    @State private var text = ""

    var body: some View {
        ZStack(alignment: .top) {
            Color.green.ignoresSafeArea()
            TextField("Type here", text: $text)
                .textFieldStyle(.roundedBorder)
                .padding()
        }
    }
}

Hello, thank you for reporting.

I have made sure your reports are seen by the relevant engineering teams.

They would like you to confirm if the issue is resolved on the latest 27 beta. Please confirm these details in the discussion section of your Feedback report or do so in this thread.

 Travis