It's entirely possible where in Catalyst if a UIKeyCommand is registered that uses a non-modified letter, it overrides text input. Having said that, I can't imagine why Twitter for Mac would have solo-letter key commands registered during the login flow, and if they did then I can't imagine why they wouldn't also interfere during tweet composing. Or rather, I can imagine, but the scenarios I'm constructing would imply extremely contorted view controller hierarchies that make no sense.
Can’t imagine why this would cause it to delete all input in the field when one of those characters is typed in using “reveal password” mode though. If you enable reveal, type in a string containing b, and then switch off reveal mode and add another character, it deletes the whole password. If it was just dropping inputs that would be one thing but this seems to be aggressively refusing to allow them in the field.
It sounds like its specific to secure text fields, which I assume is why it doesn't interfere with tweeting. But thats a fair question about setting those up before login. My guess is those registrations aren't happening at the login VC level, or maybe in some global container VC. But I don't think that matters too much, because there are certainly use cases where you might want to show a secure text field even when logged in and you want shortcuts registered.
I am and that's why this is so surprising to me. No other app is reporting this type of behavior and Twitter is known for shitty Mac apps. I highly doubt that the regression could cause this unless it was done incorrectly to begin with. Otherwise, UIKit/AppKit would be doing the same for every other app. We may hear about that in the next day or two but, until that happens, I have a feeling this is all on Twitter.
That doesn't mean much if they implemented it in the exact same way they did for the full app. Unless we see this happening in other apps, I'll default to the implementation being the problem rather than the API itself.
