[Bug]: Swift iOS: going back from a thread with the keyboard open leaves a blank keyboard-height area in the home thread list

[scriptease]

Area

apps/mobile (experimental SwiftUI client, apps/swift-ios, #5178)

Steps to reproduce

1. Open a thread from the home thread list on iPhone.
2. Tap the composer so the keyboard is visible.
3. Go back to the home list while the keyboard is still up (back button or swipe back).

Expected behavior

The keyboard goes away and the thread list uses the full screen height again.

Actual behavior

The bottom area where the keyboard was stays as a blank region. The list is cut off at the old keyboard top edge and the empty area below it never fills back in, so the list shows only about the top 60% of the screen. The compose FAB stays at the cut-off edge.

Likely cause: the keyboard height inset or safe area is not reset when the thread is popped with the keyboard showing (see HomeThreadCollectionView in apps/swift-ios/Features/Workspace/).

Impact

Minor bug or occasional failure

Version or commit

t3code/rebuild-mobile-app-swift @ 8ad853c

Environment

iPhone, iOS, SwiftUI client build

Workaround

Open any thread and go back again with the keyboard closed. The list then lays out at full height.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Thanks for the report. I checked t3code/rebuild-mobile-app-swift @ 8ad853c (apps/swift-ios is not on main yet; it ships with the open PR #5178).

The code fits what you're describing:

• HomeThreadCollectionView (apps/swift-ios/Features/Workspace/HomeThreadCollectionView.swift:57-59) handles no keyboard events itself. It sets keyboardDismissMode = .interactive and a fixed contentInset / verticalScrollIndicatorInsets (bottom 74). It doesn't observe keyboardWillHide, use keyboardLayoutGuide, or reset any inset. No file in apps/swift-ios observes keyboard notifications except Features/Keyboard/FeatureCommandPaletteController.swift.
• The home sidebar (apps/swift-ios/Features/Workspace/WorkspaceView.swift:300-322) is a ZStack(alignment: .bottomTrailing) that holds threadList and composeButton (the FAB), with no .ignoresSafeArea(.keyboard). That leaves it under SwiftUI's automatic keyboard avoidance. If the keyboard safe-area inset is still applied when the pop transition ends, and isn't recomputed once the keyboard is gone, the whole stack stays shrunk by the keyboard's height. That would explain both the blank area and the FAB sitting at the cut-off edge.

Possible fix directions (not yet tested): add .ignoresSafeArea(.keyboard, edges: .bottom) on the home sidebar (the home screen has no text input that needs avoidance, apart from search at the top), or dismiss the composer's focus before the pop starts.

Labeling as a bug in the experimental Swift client.

[scriptease]

Root cause and fix

This regressed in cf57cc6ca ("feat(swift-ios): complete orchestrator v2 mobile parity"). It reproduces every time on unmodified 8ad853cf1.

Cause

• featureKeyboardCommands(...) (apps/swift-ios/Features/Keyboard/FeatureKeyboardRegistration.swift) wraps the workspace NavigationSplitView (Features/Workspace/WorkspaceView.swift) in a UIViewControllerRepresentable (FeatureKeyboardHost). That representable hosts the content in a second UIHostingController nested inside the root hosting controller.
• Both hosting layers avoid the keyboard. In compact width, when the keyboard comes up while the sidebar column is off-screen (a thread is pushed), the sidebar column gets laid out for the keyboard. It is not resized when the keyboard hides.
• Measured with LLDB after the repro: the sidebar NavigationStackHostingController view is 484pt and the split view controller view is 778pt. The missing ~294pt is the keyboard height minus the bottom safe area. The white area is the root _UIHostingView background showing through below the shrunken column.

Fix: the outer representable ignores the keyboard safe area, so only the nested hosting controller avoids the keyboard:

--- a/apps/swift-ios/Features/Keyboard/FeatureKeyboardRegistration.swift
+++ b/apps/swift-ios/Features/Keyboard/FeatureKeyboardRegistration.swift
@@ -22,6 +22,9 @@ extension View {
             onPaletteQueryChange: onPaletteQueryChange,
             onCommand: onCommand
         )
+        // The hosted controller avoids the keyboard itself. Avoiding it here
+        // too leaves off-screen columns sized for a keyboard that has hidden.
+        .ignoresSafeArea(.keyboard)
     }
 }

Verified on an iPhone 17 simulator (iOS 27, Debug) and on a physical iPhone (Release):

• The list fills the screen after going back.
• The thread composer still sits directly above the keyboard.
• Sidebar search still pushes the list above the keyboard.

Tried, did not help

• Resigning first responder in WorkspaceView.closeSelectedThread().
• .ignoresSafeArea(.keyboard) on the sidebar view. The shrinking happens at the column-container level, above the sidebar's own modifiers.