Apple update looks like Czech mate for locked-out iPhone user

4/12/2026 at 9:21:59 AM

after Apple removed a character from its Czech keyboard

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...

by userbinator

4/12/2026 at 9:33:28 AM

It’s wild that "verify existing passcodes remain inputtable" isn't the absolute first item on the QA checklist for any keyboard layout change. The Czech layout isn't exactly an obscure edge case.

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.

by shawnta

4/12/2026 at 10:11:29 AM

I agree with you and don't really get what Apple gets from removing a valid Czech character, but how would you test if all existing passcodes remain inputable without knowing the passcodes of all iPhone users?

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...

by Matl

4/12/2026 at 10:17:24 AM

You assume the worst case: every character that could ever have been entered is in use.

by brainwad

4/12/2026 at 10:17:45 AM

> how would you test if all existing passcodes remain inputable without knowing the passcodes of all iPhone users?

You basically can't ever remove an available character.

That includes emojis if they're allowed in IOS passwords.

by RobotToaster

4/12/2026 at 10:18:29 AM

Phased roll-out. You first introduce a version that still accepts all extant inputs but will actively warn that there are characters that will be removed in a future release.

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.

by bostik

4/12/2026 at 10:30:47 AM

Meh, I think you keep the old keyboard and set a password expiry. New passwords use the new keyboard. Or, if you're in a rush to remove the old code, _after_ next login you require password replacement and use the new onscreen keyboard from then.

by pbhjpbhj

4/12/2026 at 10:37:36 AM

AI slop bot go away

by nubg

4/12/2026 at 10:10:36 AM

Honestly of the big companies sometimes I feel like Apple is the worse offender in i18n questions

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

by raverbashing

4/12/2026 at 10:38:42 AM

The side of my brain that manages organizational changes wonders: how does Apple, a 50 year old company of tens of thousands of engineers and over a trillion USD market cap, manage to keep feature velocity high while not making more of these types of errors?

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?

by thephyber

4/12/2026 at 9:38:36 AM

> During in-house testing, which involved taking an iPhone 16 from iOS 18.5 to iOS 26.4.1, The Register found that Apple has kept the háček in the Czech keyboard, but removed the ability to use it in a custom alphanumeric passcode. The OS will not allow users to input the háček as a character. The key's animation triggers, as does the keyboard's key-tap sound, but the character is not entered into the string.

Sounds more like an actual bug than a decision to change the keyboard layout, if this happens only in the passcode screen?

by freehorse

4/12/2026 at 9:30:28 AM

> Byrne was hoping that the next update, 26.4.1, would introduce a fix for this, but its release this week has not helped.

Even if Apple restores the háček in a future update, wouldn't he still need to unlock the iPhone to install it?

by N19PEDL2

4/12/2026 at 10:15:47 AM

afaik you can update your locked iPhone with a Mac or Windows in iTunes... but it will still require a passcode after update, so ¯\_(ツ)_/¯

by bpavuk

4/12/2026 at 10:34:15 AM

Nope, the ”trust this computer” dialog needs you to enter your passcode before any other actions are possible

by nikanj

4/12/2026 at 9:45:37 AM

I think the biggest lesson here is to back up. The reason for losing access to the phone is amazingly dumb but it could have fallen down the stairs for basically the same effect.

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.

by PufPufPuf

4/12/2026 at 9:22:50 AM

I used to have an emoji password for my Android phone, and had the exact same issue after a reset! It's an odd but pretty terrible failure mode for locking oneself out...

by eab-

4/12/2026 at 9:55:52 AM

You say locking oneself out, but I decline to consider any situation where a password can be set but not later entered as one where the user bears even a modicum of fault.

by terribleperson

4/12/2026 at 9:02:39 AM

I lost all of my photos when I was a college student too. I was way too irresponsible to actually back anything up. Kind of a bitter lesson.

by _vertigo

4/12/2026 at 9:25:59 AM

As a non-English speaker I can really relate to this. I think the real mistake was Apple allowing to enter a non-ASCII password in the first place. E.g. on macOS the password fields have been locked to English character set, and I'm not sure why it changed on iOS.

by nasretdinov

4/12/2026 at 10:32:24 AM

Are you aware that billions of people live in countries where they could go on the whole life without seeing an ascii letter?

by tomaskafka

4/12/2026 at 10:38:48 AM

That's not really true in any country these days.

by jakeinspace

4/12/2026 at 9:40:43 AM

The "real mistake" is changing things that used to work.

by userbinator

4/12/2026 at 10:05:05 AM

You can use emojis as passwords, do you think that's a good idea? They work now, there's a good chance that they won't be the same forever. See what happened to the family emojis

by halapro

4/12/2026 at 10:30:31 AM

Passwords are more secure if they are higher entropy, so it makes sense to support a larger variety of characters, Czech or emoji.

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.

by thephyber

4/12/2026 at 10:30:13 AM

Did the underlying bits (hex/oct/… or whatever representation) actually change or just the visuals?

by Y-bar

4/12/2026 at 10:06:18 AM

Well, alphabets change (especially emojis), rules change, etc, so keeping a single subset of stable and known characters is unlikely to be a bad idea :)

by nasretdinov

4/12/2026 at 10:15:06 AM

Maybe.

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.

by Y-bar

4/12/2026 at 10:05:47 AM

But why should non-English speaking users be forced to use an ASCII password if the rest of the OS supports their language just fine?

by trinix912

4/12/2026 at 10:09:28 AM

If you remember what was the encodings situation before UTF-8 became the norm... Let's say it was really ugly. E.g. there were at least two popular encodings for Russian Cyrillic letters — CP1251 and KOI8-R, and it was _very_ common for applications getting it wrong. Restricting things like passwords (and ideally even file names) to ASCII this was a practical necessity rather than an inconvenience.

by nasretdinov

4/12/2026 at 10:34:42 AM

Well yes, but you can process all passwords as UTF-8, as most of strings are in mac/iOS anyways, to avoid these problems. Then just don’t break an established standard like the keyboard layout. Is that too much to ask for in 2026?

by trinix912

4/12/2026 at 10:10:18 AM

To avoid apple inevitably fucking up and breaking things like in this case. The risk to benefit ratio for allowing this is just very poor

by wqaatwt

4/12/2026 at 9:48:48 AM

Even if he did have a Mac with the continuity feature enabled, I suppose the lock-screen won’t accept a paste from the clipboard of a Mac. (If it did, he could enter the correct passcode in any text editor on his Mac, copy it to the clipboard on the Mac, then paste it into the lock-screen on his iPhone)

by PlunderBunny

4/12/2026 at 10:20:01 AM

Continuity has never worked on the lock screen and certainly not in the BFU state.

by Shank

4/12/2026 at 9:23:31 AM

This is completely unacceptable from Apple. You CANNOT remove a key from the keyboard that's being used as a password.

by jychang

4/12/2026 at 10:08:13 AM

Turns out they CAN and they WILL. The character has always been special on all Apple OSes.

by halapro

4/12/2026 at 9:40:37 AM

as if they cared

by type0

4/12/2026 at 10:06:43 AM

This really reads like a modern Ancient-Greek story about inscrutable gods who suddenly decide to complicate your life for some unclear reason and don't respond to any prayers and rituals.

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.

by inglor_cz

4/12/2026 at 9:59:37 AM

there was a time when I used a simple "§" in my password. turned out, some Android keyboards don't have the "§". Since then I play it safe with my passwords, using only characters I don't need a specialized keyboard for

by wolfi1

4/12/2026 at 9:46:46 AM

I assume you can use a physical keyboard on an iPhone like I can on Android via USB? Presumably you could buy a wired Czech keyboard to access the device?

Twice I have had the touchscreen fail on Android devices and been able to get what I needed off them using a USB mouse.

by donatj

4/12/2026 at 9:49:07 AM

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.

Makes sense why he didn't do this.

by tmjwid

4/12/2026 at 9:47:04 AM

You can, after you unlock it.

by GrayShade

4/12/2026 at 9:26:31 AM

Apple should get sued for this to oblivion, this is unacceptable.

by lousken

4/12/2026 at 10:10:57 AM

if you remove the hachek, there will be MANY locked out czech users. It's a symbol of national pride!

by formvoltron

4/12/2026 at 9:08:22 AM

It’s an annoying workaround, but could he connect a USB keyboard (via a USB to lightning adapter) with the ability to enter the character? Does the passcode screen accept input from attached keyboards?

by lilytweed

4/12/2026 at 9:10:33 AM

As mentioned in the article,

> 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.

by sheept

4/12/2026 at 9:12:19 AM

It's mentioned in the article. USB devices are blocked until the passcode has been entered.

by Deadsunrise

4/12/2026 at 9:29:05 AM

Why can't people read stuff before commenting?

by Myzel394

4/12/2026 at 9:44:10 AM

Well I only use alphanumeric US keyboard standards ever since I found out, that certain characters unique to a language different from yours causes you lock out or massive headaches on a used keyboard with almost no print ink left on the keyboard in a Internet cafe in an other country around 2002.

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.

by _the_inflator

4/12/2026 at 10:19:54 AM

I agree with the recommendation, but it's absurd to not blame Apple here. There is absolutely nothing acceptable about what Apple did in this case, it's a major fuck-up to break password input in this way, and for no reason whatsoever.

by tsimionescu