Setting styles can break keyboard/sheet layout (via forceRefreshAppearance)

[michaelkirk]

Firstly, I'm not sure if this is a bug in maplibre, a bug in SwiftUI, or something in the interaction between.

I'm experiencing a problem in my own app which I've narrowed down to this method in maplibre-navigation-ios:

func forceRefreshAppearance() {
    for window in UIApplication.shared.windows {
        for view in window.subviews {
            view.removeFromSuperview()
            window.addSubview(view)
        }
    }
    
    self.delegate?.styleManagerDidRefreshAppearance?(self)
}

It's called when the Style is updated. Style determines map rendering but also UIKit widgets via UIAppearance.

I'm assuming the motivation for the above implementation is from https://developer.apple.com/documentation/uikit/uiappearance :

iOS applies appearance changes when a view enters a window, but it doesn’t change the appearance of a view that’s already in a window. To change the appearance of a view that’s currently in a window, remove the view from the view hierarchy and then put it back.

Note that we're removing views from not just our own application windows, but all windows (including the keyboard window). I've fixed this problem in my app by reworking this method to ignore the keyboard window. (PR: #51)

Steps to Trigger Behavior

I think it's something like:

1. add a map and an input field to the view hierarchy
2. make input field first responder to present keyboard
3. present another MapView modally
4. dismiss the modal mapview
5. make input field first responder again

You can see the steps to reproduce in my app here (bug shown at 16s):

broken-keyboard-layout.mov.mp4

Link to Minimal Reproducible Example

I'm sorry I don't have a good minimal reproduction yet

Expected Behavior

Presenting another mapview should not cause layout issues with keyboard presentation.

Actual Behavior

When the keyboard is presented, the view layout gets real wonky, making most of my views non-visible.

Screenshots (if applicable)

Should look like this:

I suspect it's related to keyboard presentation/offset. Once the app gets into this state (by presenting a second MapView), if I hide/show the keyboard (cmd+k) you can see the view go from normal looking to broken:

keyboard-presenting.mov.mp4

Note these videos are from the simulator, but I've reproduced the issue on a physical device as well.

Version(s) affected

• Platform: iOS
• OS version: tested on 16.4 (simulator), 17.5.1 (physical device: iPhone SE)
• Device type: [e.g. iPhone6] iPhone SE
• Emulator/ Simulator: Reproduced on both simulator and device
• Development OS: 14.5 (23F79)
• maplibre-navigation-ios Version [e.g. 7.0.9]: 3ffaa51 (3.0.0-beta.1)
• MapLibre GL version [e.g. 6.3.0]: 6.4.1

Additional context

I suspect that this problem might only manifest if you change styles when a keyboard is already presented. Normally this might not happen if you're using just one map, but in my case I have a first map for searching and finding a destination, and then modally present a second map for navigation purposes (I'm following #41 in hopes of getting rid of this second MapView).

The initialization of the map sets styles which is considered a "change", and fires the above problematic method that removes all views from all windows.