When I tried to type in using these two input methods, I have to type several times because the first few letters always disappear. I guess it happens to all kanji input methods.
2 Likes
This has been seen in the private beta team testing too. But frustratingly, I can’t reproduce it!
I was living in Japan for the past three months, using the romaji keyboard every day, and never saw it happen. Then I managed to reproduce it once using the kana keyboard, but then couldn’t repeat it after that.
I’m guessing it’s a SwiftUI bug somehow, because that view was rebuilt in SwiftUI recently. And the code never modifies the search text, it only reads it. But hopefully there’ll be some workaround for it. I’ll have another attempt at it soon.
Oh, just working a hunch: Let me know if the problem still happens if you wait a few seconds after opening the view before entering text.
My current suspicion is that it’s due to some delayed event that happens just after view open, which causes the view to rebuild and the partially entered text to disappear. Although if that were the case you’d expect it to happen with all keyboards, not just the pinyin / romaji / kana ones.
I also experience the exact same phenomenon.
I am using a Japanese keyboard. It happens whether I type in kana or romaji.
I think there are two types of symptoms.
- First keystroke after moving to the search screen: It is always lost, no matter how long I wait before type.
- After that : The keystroke when the search result is updated is lost.
1 Like
Thanks for the info @ikuhiromorita!
I managed to reproduce it once with the kana keyboard, but never with romaji. But sounds like it’s much more consistent for others. But so far no obvious reason why. Hmm.
Hi Matt, it seems that I’ve encountered a new type of typing problem. When using the Chinese, Simplified - Shuangpin (Xiaohe Shuangpin) input method, I always failed to type the Chinese characters.
Oh no! This bug! It’s also been reported by one of the beta testers in Japan, I think early last year.
I only ever managed to reproduce the problem one time (I also use Japanese keyboard because I live in Japan part of each year). Which means that it’s very hard for me to find what’s causing the bug! If I can’t reproduce it I can’t track it down 
It will be interesting to see if the bug also exists in Arc Editor app, which will hopefully be going into beta some time in the next month. I suspect it’s a weird UI code interaction that’s … well, I don’t really know. There’s no obvious clues in the code at all. But it surely must be something in UI code…
As a workaround… hmm… I’m really not sure. I wish I could reproduce the problem so I could at least find a way to work around it! I’ll have another attempt at it today.
Oh I just realised this is in a thread about the existing bug. I should’ve scrolled up 
So what you’re describing this time is something slightly different? Yeah, it does look like it. But presumably it’s caused by the same underlying problem. Ok, I’ll do a bunch of testing today. There’s got to be a way to catch the bug in action…
This problem got worse when I update iOS from 17 to 18.3 today. Originally the Chinese Pinyin can anyway be input in many tries, but in iOS 18.3, when I input character more than 3, the app will lag for a sceond then lost Chinese Pinyin input style. Now I can only edit the place in another app and copy words into ACR app.
Oh Japanese is also my language, in Japanese input, this bug dosen’t exist.
Ooh, this could explain why I couldn’t replicate the bug myself (it’s only happened once to me in Japanese input).
Though initially it was first reported by Japanese users. But now it seems it’s ok in Japanese but not in Chinese, even though nothing in the app has changed! It feels very much like an iOS bug. But that’s no help to any of us - we still need to find a way to fix it or work around it.
I’ll do some Chinese input testing in the Arc Editor beta. Because that one’s a ground up rewrite in pure SwiftUI hopefully it’s not going to run into the bug that’s possibly the result of old UIKit and new SwiftUI interacting badly together.