Thanks for the post, I do not see any questions besides the comments about what is not working and I would like to go over the details for each and find out the issues you are encountering and how to reproduce those.
Instead of looking for a specific "hinge" API, the system reports the physical hinge and reserved areas, like rounded corners or a camera housing, through safeAreas. If your keyboard spans both screens, the hinge acts as an "unsafe" area in the middle of your view. You can always change that.
If needsInputModeSwitchKey was returning false or behaving unpredictably, it's often because the view hierarchy hasn't fully resolved, or the keyboard wasn't configured as a primary language keyboard. To ensure the renders properly and hands off control to iOS, you should check this property in viewDidLoad
The regression where the text field loses focus and the keyboard dismisses usually happens if the extension crashes, takes too long to layout, or manually resigns first responder during a bounds change. The key to keeping the keyboard alive rather than tearing down and rebuilding your views.
I would be very interested to see a focused sample showing how you handle each item and see how you hit those issues you have described.
Do you get the same results with just the relevant code in a small test project?
If so, please share a link to your test project.
That'll help us better understand what's going on.
If you're not familiar with preparing a test project, take a look at
Creating a test project.
Looking forward to your focused sample.
Albert WWDR
