You could do the same thing with a button+mouse on a desktop. The dot for the typed character appearing immediately is different from alphanumeric keyboard behavior, because you can't register any key press before releasing the touch (or key) there, due to composition.
In my opinion, this is sensible behavior and your vision sounds like it would be a nightmare in reality to me, accidentally pressing neighbouring keys or tapping instead of swiping all the time.
Is this any different on Android? I've used Android for most of my smartphone life.
And I can't remember how often I was relieved to be able to cancel an accidental tap by swiping away, when I accidentally tapped a link while scrolling for example.
This is even the default for mouse buttons, no?
It happens, while rarely, still regularly, that I notice I pressed the wrong button just after the mousedown, but before the mouseup. And since I can remember, I was happy that the UI was made so I could then just hold the mouse button and move out of that button to cancel.
Just verified your description of the lock screen code buttons. Not a bug, but the behavior you describe would feel buggy to me.
There are plenty of UX annoyances on iOS though, that is not what I want to deny. I also prefer GBoard over apples builtin onscreen keyboard.
I think it would slow me down even more if it didn't have this behavior, because of typing in extra unintended numbers?
I don't have any issues with typing my passcode in quickly, and tbh hadn't noticed the tweak with the immediate feedback on "tapdown" (and the possibility of the number disappearing).
Would have to try, but I still feel I prefer the current behavior to what you suggested, and I'm pretty sure it's intentional.
Anyway, thanks for bringing this up, hadn't noticed! I'll admit, for me this is good interaction design.
The simplest comparison point is the calculator app which behaves exactly as you described: if you put your finger down on the number 9, a 9 won’t show up until you lift up your finger. OTOH, if it worked like the Lock Screen, a 9 would show up, but would then be removed if you moved your finger away and lifted up. But again, nowhere else works this way.
If you think this is good interaction design, do you thus think the calculator app has bad interaction design? That it should instead be adding numbers immediately and then retroactively removing them?
It's just that I usually attempt to enter that code quickly if I have to, so I never consciously noticed it.
It seems great to me because when I enter my code slowly, I'm probably having input problems anyway (e.g. rain, thin gloves, tiredness).
And in these situations, the behavior felt so natural to me that I only now notice it.
I agree it may seem weird from a coherence standpoint, but the character appearing on keydown like it does just felt natural to me, just like a Win98 native button-down state.
These buttons don't behave like physical push-button phone buttons.
Regarding the calculator, the use case is the exact opposite, and I wasn't arguing against this regular "keypress" behavior anyway, just against the original suggested "keydown" behavior, which I'd consider a nightmare when used for tapping an on-screen keyboard.
The "bastardized" version on the iOS lock screen just has suited me well for this use case, especially when talking about numeric lock codes