You don't even have to make a single line change to your backend to fix this. You can fix this entirely on the frontend by just applying a digest hash on the password before sending to the backend for proper password hashing. This way you can even support "unlimited" length password.
That's a very much backwards incompatible change: password that used to work no longer does.
Sure, just put your 500M users through a forced-password reset.
Theoretically, it might also lead to weaker passwords depending on the hash size (that's how you support unlimited lengths by transforming a larger space into finite one) or any issues with the hashing algorithm uncovered in the future.
One thing to keep in mind is that the hash actually becomes the password, so I can imagine plenty of buggy implementations where a developer does not do what you advise ("proper password hashing"): "hey, it's already hashed, I can just store it as-is".
Limiting characters can also be a feature, so users can't use emojis in their password (this is so fun), to realize later they can't login, because they don't know how to input emojis from their desktop computer.
Hopefully passwords will be gone soon (at least that's my hope).
Don't get me wrong, it's a stupid limitation indeed -- but sometimes decisions like these are meant to stop users from doing stupider things :)
I'm no fan of oversimplification, but Apple's audience is everyone, not just power users. In that case, I'd prefer having advanced options surfaced to me as "advanced" so I can do what I want, but leave the simple experiences for the simple folk.
You might have half a point about emojis, but that's not what Apple is doing here.
Is there a reason I as a Swede should be limited from using my full native alphabet in my passwords for example?
As an example, you know how people sometimes suggest using a short sentence as a password? Here's a phrase in a local dialect, which means "and in the river there's an island"
Å i åa e ä ö
Notice how only 2 of those letters are available in ASCII.
ASCII only is not a feature, and I honestly doubt anyone would try to argue that it is if this was about any company other than Apple. Try to look past the "who" and focus on the "what".
Aren't those keyboards usually readily switchable with a standard US keyboard layout (e.g., in Windows, MacOS, or Linux)?
Do you have any direct experience with this?
My point is that 7-bit ASCII underlies virtually all other keyboard / character encodings. Among the few cases where it doesn't (e.g., IBM mainframe EBCDIC, independent of ASCII), the principle encoding remains the Latin alphabet, and can readily be converted using standard system utilities.
They aren't readily switchable unless explicitly configured to be, and yes, I am speaking from direct experience.
I get your point, I am just saying that it is not universally true, even if my example is a stretched one (Cyrillic keyboard users always configure Latin-based layouts too, but it's not a default, and it's easy to forget esp if you install from a fully live env configured with both).
If it's still not clear, you can end up on a login screen with an ASCII password you can't type in, especially so without the GUI.
