Ok, the touch keyboard is using Ezra SIL.
Sometimes, the device can’t display diacritics properly if they don’t have a character to attach to. The keyboard includes an empty character (◌) U+25CC that precedes the letter which is not showing up here or on my machine for this keyboard. Keyman has been making changes in recent versions (and to the code) to make the diacritics show up better, and something might have gotten broken.
I just checked, and the font has and can display that character. It can display (◌) on a key by itself. Keyman is having issues merging U+25CC and the diacritic. It looks like maybe the empty character doesn’t combine/display properly in RTL. U+25CC is an intervening LTR character. For RTL languages like this one, it seems we need to add the RTL marker U+200F before to make “U+200F U+0255 Diacritic”. If we do that, it works properly. For those more familiar with RTL, I’m not sure if we need to add U+200E at the end so that XML document (which is LTR) doesn’t get broken.
I understand why it’s on the Keycap, to give it something to hang on to.
When you add a 25CC manually on a LTR keyboard as was done here, it does display on devices (and this is what I prefer in my keyboard).
I think that the web logic is to choose the direction of the first character. This works for the base characters. It just fails to combine 25CC with a RTL diacritic without the 200F. The diacritic is landing off the key. It displays properly with the 25CC on devices if you add the U+200F to each display character.
It’s worth noting that the only thing that has changed here is the iOS version. Keyman hasn’t changed its presentation of the keyboard recently, and the Hebrew keyboard hasn’t changed either – it still displays just fine on earlier versions of iOS.
That said, 25CC has always been an unreliable method of giving a base to unattached marks, across many scripts. In fact, anything that relies on the renderer to do something consistent and sensible has been problematic, and behaviour differs across platforms and platform versions. For an example with Lao, see my blog.
It’s very likely that adding 200F to the OSK will cause it to break on other platforms, or even on other versions of iOS. Similarly, removing 25CC will probably cause marks to render off the key on some platforms.
The only way we have been able to make this work consistently everywhere is to create a custom font for the on screen keyboard which combines the dotted circle glyph (or anything, really) with each glyph that needs a base, each as its own PUA character. We do this for Lao and Khmer already – see khmer_angkor - #1710 for an example. Here’s the set of PUA characters we created for that keyboard – in each case, the dotted circle is a part of the glyph, not something added by a renderer:
Yes, a font seems like a more long-term solution. I was looking at the short-term for a broken output.
No character may be an iOS-only error, but note that in the debugger and Android, the 25CC doesn’t show up as expected on keys with a RTL diacritic (it only shows the diacritic). This may be usable, but it’s not what the keyboard designer has defined.