fix: make getTopWindow more robust

[thespacemanatee]

📜 Description

This PR updates the top window retrieval method:

Old: UIApplication.shared.windows.last (deprecated in iOS 15+)
New: UIWindowScene-based approach

Differences:

• UIApplication.shared.windows.last:
  • It accesses all windows associated with the application.
  • The last window in this array isn't always the topmost or key window, especially in more complex app setups.
  • This approach is deprecated as of iOS 15, though it still works in many cases.
• UIWindowScene:
  • Iterates through all connected scenes to find the active foreground scene
  • Ensures selection of the correct key window in multi-window environments (e.g., Split View in iPadOS)
  • Provides more reliable behaviour in complex app configurations that utilize multiple UIWindowScenes

💡 Motivation and Context

Closes #618

In our case, this change was required to get the children of the OverKeyboardView to show. Without it, they were still rendered, but invisible. This change should enhance the reliability across different iOS versions and device types.

📢 Changelog

iOS

• Get the last key window in the current UIWindowScene as opposed to the last window of all windows associated with the app

🤔 How Has This Been Tested?

It works on my company project. Did not manage to get the example app to compile on my machine. Could be due to the (lack of) provisioning profiles.

📝 Checklist

• CI successfully passed
• I added new mocks and corresponding unit-tests if library API was changed

[kirillzyusko]

The changes looks good to me, but may I ask you to slightly re-work this part?

I would like to have this code somewhere isolated, because potentially we may want to get an access to main window in future, so I would move this code to an extension:

extension UIApplication {
    var activeWindow: UIWindow? {
        if #available(iOS 13.0, *) {
            for scene in connectedScenes {
                if scene.activationState == .foregroundActive,
                   let windowScene = scene as? UIWindowScene,
                   let keyWindow = windowScene.windows.first(where: { $0.isKeyWindow }) {
                    return keyWindow
                }
            }
            return nil
        } else {
            return windows.last { $0.isKeyWindow }
        }
    }
}

And then use it like:

return keyboardWindow ?? UIApplication.shared.activeWindow

Not sure if this code works - just wanted to show the idea. Hope you can test these modifications in your project 👀

[thespacemanatee]

Will try and let you know!

[thespacemanatee]

@kirillzyusko Looks like it functionally works the same, but I found a new issue that I'm not sure if is the result of this PR, or also present in the existing code.

In my app, I have routes guarded behind an auth check, and the Screens rendered in the Navigator change based on the auth state. When I open the OverKeyboardView for the first time, it works, and navigation events such as push can be done and OverKeyboardView still works. But if the user logs out, the Screens are remounted and the next time I try to open this OverKeyboardView, the children become invisible again.

Do you think this PR should be put on hold until I figure out the fix for that as well?

EDIT: I would like to know if you can reproduce this as well, by adding more complicated routes to the example if you have the time 🙏

[kirillzyusko]

Ah, sad to hear that it still has issues 😔

Would you mind to submit a new issues and describe hte problem? Just want to track it somewhere so that I know that I'll not forget about the problem and will return to it :)

[thespacemanatee]

@kirillzyusko let me create an issue when I get some time this week! Thanks man

[kirillzyusko]

And yeah, if possible, please fix swiftlint and swiftformat jobs 👀

I think running swiftformat should be enough and swiftlint should be fixed automatically

[thespacemanatee]

@kirillzyusko Xcode also complains about using UIApplication.shared.keyWindow, I haven't tested it yet but replacing this with the activeWindow extension removes the warning and should achieve the same thing.

[kirillzyusko]

Yes @thespacemanatee I'm also constantly getting these warnings 🙈

I would split changes in two parts anyway 🙃 Like merge these changes and then open a second PR that will repace a single line.

In this case it'll be easier to manage 😊

[kirillzyusko]

Merged @thespacemanatee 🙌

Would you mind to submit a PR that we discussed here?