> For the same reason, plugging in an external keyboard is also a no-go since freshly updated iPhones are placed in what's known as a Before First Unlock state, which prevents wired accessories from working until the passcode is entered.
I wonder what the thought process (or perhaps lack thereof) at Apple was. Did no one of the likely-somewhat-large team who did that think "wait, this could lock out our users who may have used that character"?
In the immortal words of Linus Torvalds: "WE DO NOT BREAK USERSPACE!"
Now one of the ways in might be those companies who claim to be able to break iPhone security for law enforcement and the like, but I'm not sure if they'd be willing to do it (at any price) unless you could somehow trick them into thinking you had some "interesting" data on there...
The USB keyboard suggestion mentioned in the other comments likely won't work either because of USB Restricted Mode. After an hour of being locked, iOS disables data over the Lightning/USB-C port until the device is unlocked. It’s a perfect, recursive failure: you can't unlock the phone because the character is missing, and you can't plug in a hardware keyboard because the phone is locked.
Treating the passcode keyboard as a transient UI element that can be "cleaned up" rather than a hard security dependency is a massive architectural oversight. If the OS allows a character to be used in a passcode, that glyph needs to be permanently accessible in a fallback mode, no matter what the localization team decides to prune.
The one way to do this that I could see is to include both the new keyboard and the old one and if someone fails to unlock with the new one auto report that to Apple (not the code, just that the unlock failed and that the keyboard might be the problem), then auto revert to the old keyboard on the next unlock attempt...
You basically can't ever remove an available character.
That includes emojis if they're allowed in IOS passwords.
Then you wait. Then you roll out a version where the new functionality is flipped on by default, but where you still allow to explicitly toggle to the old one. Then you wait some more.
And then - only then - you roll out a release where the old functionality has been removed entirely.
Sure they have most of their stuff translated but some rough edges make me feel they do the bare minimum:
- Their ISO keyboard sucks. Sure their overall quality makes it good but of the major brands their Enter key is the most flimsy attempt at it
- Some long standing bugs https://discussions.apple.com/thread/250299816?sortBy=rank (which I had the impressions they were made worse in localized version or at least if you used a non American date format)
- General weirdness with translation missing sometimes
It seems paramount that the OS should not allow password input of any characters which it theater takes away. At the very minimum if this is absolutely necessary to make this breaking change, the user should be warned several times that a character in the password is no longer valid and maybe even prevent the OS from upgrading before the password is changed to a forward-compatible one.
But there is already a known pattern on how to handle this which I was taught (before the original iPhone even) in university CS studies:
If the manner of entering credentials has to change,
Then on first entry, offer the old method,
And, because you now (temporarily) have the plaintext credentials, you can now inspect it and test if anything need to change for the future,
And then set a flag, or require user action , or just re-encode, to use the new method as inspection determines.
Even if Apple restores the háček in a future update, wouldn't he still need to unlock the iPhone to install it?
Sounds more like an actual bug than a decision to change the keyboard layout, if this happens only in the passcode screen?
Be aware of characters not passwords. I feel bad for the guy but not really blame Apple here.
English is my second language and ANSI etc is following a basic character usage. Everything must boil down to 0 and 1 in the end or American English.
It is a de facto standard and maybe knowing about it is as crucial as recognizing the difference between the imperial and metric system before heading for the moon. It is a life saver.
And do your could backups cross-provider. You never know what the "big players" are going to pull, and your lifetime customer value is less than the cost of a single support call.
Twice I have had the touchscreen fail on Android devices and been able to get what I needed off them using a USB mouse.
Makes sense why he didn't do this.
People are afraid of AI, but human organizations can be quite opaque as well.
That said, as a Czech, I wouldn't use any accentuated characters in my passwords. Anything beyond 7-bit ASCII is just asking for trouble.
The bug seems low likelihood but high severity for the few affected users. Other than simply never changing the login keyboard (or any of the keyboard code) or having nearly 100% test coverage, how does a company not accidentally have more of these types of issues?
_vertigo•1h ago