I have written a calculator app. Its main window is a UIView subclass that usually receives user input from the touchscreen, tapping on a virtual keyboard (not the standard pop-up keyboard). I recently added hardware keyboard support. In order to receive key events, I implemented canBecomeFirstResponder and made it always return YES, and I'm calling becomeFirstResponder whenever the main window becomes active, and resignFirstResponder when it becomes inactive. This is working fine except for one scenario: when running the app on an iPad, together with another app, using Split View or Slide Over, and the other app has keyboard focus on a text field, my app doesn't receive keyboard events, even when it's the foreground app. I have to go into the other app, and tap somewhere outside a text field, and then return to my app, before my app is getting key events again. If the user taps on an actual text field in my app, it gets focus just fine, of course, but apparently my UIView calling becomeFirstResponder is not enough to take away the focus from the other app. Is there a way to steal the focus from another app's text field in this scenario?

I have a calculator app, and I would like to add support for using it with a hardware keyboard. I understand I can receive keyboard events by making my view implement canBecomeFirstResponder and having it return YES, and then calling becomeFirstResponder when the view becomes active. The problem is: I don't want the pop-up keyboard to appear. The app has its own keyboard; the UI simulates a physical calculator, and handles tap events by figuring out which calculator key is pressed and then acting accordingly. So the pop-up keyboard would literally just get in the way. But I do want to receive key events from hardware keyboards. I'm thinking of making canBecomeFirstResponder check for the presence of hardware keyboards, and return NO if none are present. But I'm not sure how to deal with hardware keyboards being connected or disconnected while the calculator view is active, and I'm also concerned about the keyboard bar on iPads. Is it possible to get hardware keyboard events without anything interfering with my UI like that?

I have a MacOS app which I publish using Direct Distribution. A user has reported a crash which I am unable to reproduce. They have provided me with a crash log, but I can't figure out how to link this to the source code in my project. It seems like this is easy for apps distributed using Test Flight or the App Store, which I have done with the iOS version of my app, but I'm having no luck figuring out how to do this with my Direct Distribution app. Is it possible?

When I go from my app to the App Switcher by double-clicking the home button, the app is shown in the App Switcher view, still running. However, if I then kill the app by sliding it upward, it is killed without sceneDidEnterBackground ever having been called. This means the saved state ends up being whatever it was when the app was launched. In an older app, which uses applicationDidEnterBackground, this problem does not exist; the method is always called, regardless of how I exit it, including when the app is killed by sliding it upward in the App Switcher. Isn't sceneDidEnterBackground supposed to be called at the same moments as applicationDidEnterBackground in older apps? As far as I can see, it isn't, and I don't see how to get my app to write its state reliably. Saving state in sceneWillResignActive is not a good alternative, because in the App Switcher, the app is still running after that method is called, so whichever changes happen to its state after sceneWillResignActive is called would still be lost.