Also, I forgot to mention above. The bug resolution also had: Recent Similar Reports:None This despite the fact that my written description explicitly included this verbiage: Other reports of this bug are here: https://forums.developer.apple.com/forums/thread/762952 https://forums.developer.apple.com/forums/thread/731761

Is anyone seeing progress on their submitted bugs in Feedback Assistant? I just checked mine and was disappointed to see it updated with: Resolution:Investigation complete - Unable to diagnose with current information I submitted details about my phone/build. I told them very specifically how to repro the bug using the Apple-written example app 'SpokenWord'. I provided an MP4 showing that app running and manifesting the bug. I provided links to other reports of this same bug (other FB* submissions) in this thread. I'm not sure what is missing with respect to being able to diagnose it. Is anyone else having better luck than me? As of the latest beta (18.1 22B5075a), the 'dropping words' bug as reported here still occurs if requiresOnDeviceRecognition is set to true.

18.1 Beta 5 (22B5054e) does not fix it. Not quite. --- @jsnbro stated above "iOS 18.1 Beta 5 (22B5054e) seems to have resolved this issue and improved U.S. English language recognition & punctuation." I upgraded to 22B5054e to re-test. What I am seeing is not quite a fix. It seems to have reverted back to the behavior I saw (and reported in this thread on page 1) on iOS 17.6, specifically this: the bug does not manifest if you set requiresOnDeviceRecognition = false the bug does manifest if you set requiresOnDeviceRecognition = true As before I am using Apple's SpokenWord example app to test. My first bug report here was using: (Context: iphone12 running 17.6.1, XCode Version 15.4 (15F31d)) For this update: (Context: iphone12 running 18.1 Beta (22B5054e), XCode Version 16.0 (16A242d)) Tagging you, @DTS Engineer. Looks like your efforts are helping.

Also. FB15192539

I shared via Dropbox (should be publicly accessible) a quick video from my iPhone illustrating the issue: https://www.dropbox.com/scl/fi/ci16tz76q9trxsuv1k1dx/audioBug.MP4?rlkey=pkywy8hanqasxya5myca3ezq4&e=1&dl=0

I shared via Dropbox (should be publicly accessible) a quick video from my iPhone illustrating the issue: https://www.dropbox.com/scl/fi/ci16tz76q9trxsuv1k1dx/audioBug.MP4?rlkey=pkywy8hanqasxya5myca3ezq4&e=1&dl=0

Quick update now that iOS18 is released versus in beta. The nice workaround I documented above of setting requireOnDeviceRecognition to false no longer works. As of iOS18 the loss of words recognized after a brief pause always happens regardless of that flag being set to true or false. Apple folks: It would be nice to hear back from you on this. Do you concur that this reported behavior is a bug? Or, if by design, is there a recommended approach for coping with it?

Quick update now that iOS18 is released versus in beta. The nice workaround I documented above of setting requireOnDeviceRecognition to false no longer works. As of iOS18 the loss of words recognized after a brief pause always happens regardless of that flag being set to true or false. Apple folks: It would be nice to hear back from you on this. Do you concur that this reported behavior is a bug? Or, if by design, is there a recommended approach for coping with it?

(Context: iphone12 running 17.6.1, XCode Version 15.4 (15F31d)) I see exactly what the OP above reported when running the Apple SpokenWord sample with no changes. However, changing this one line from true to false fixes the problem: I'm fine with the quality of the recognition being different between local and remote (presumably because cloud might be better), but this is not that and this feels very broken. Valid, recognized text is simply being thrown away after brief (speaking) pauses in the local-required case but not in the local-not-required case. In addition, in the case of setting the flag to 'false' to not require local recognition, the workaround still fixes it even when I have completely disabled all network connectivity on the iPhone (ie. it cannot make a remote call and the recognition is, by definition, being done locally). Other notes of potential interest: even if the workaround fixes it, part of my requirement is that it can always work whether remote calls are possible or not. Hence, why I set the flag to require local to true in the first place. as reported above the "isFinal" flag is never set to true during the time the earlier results are discarded i'm hearing that ios18 is even worse, specifically that setting the requiresOnDeviceRecognition to false does not help as a workaround. I have not yet verified this on ios18 because it is in beta at this time. Example to repro the bug: [with requiresOnDeviceRecognition = true] speaking "add 1+2+3+4+ (go as long as you want with no brief pauses)" results in exactly what was spoken. Doing the same with a brief pause followed by "5+6" results in all text preceding "5+6" being thrown away. By "brief pause" I mean 1 1/2 to 2 seconds. [with requiresOnDeviceRecognition = false] speaking the exact same as above with a pause as long as 2 minutes (maybe longer - I stopped testing at 2 mins) before adding "5+6" results in the full spoken text being returned (ie. the result contains "add 1+2+3+4+5+6". Again, this works even if iPhone networking is completely disabled.

(Context: iphone12 running 17.6.1, XCode Version 15.4 (15F31d)) I see exactly what the OP above reported when running the Apple SpokenWord sample with no changes. However, changing this one line from true to false fixes the problem: I'm fine with the quality of the recognition being different between local and remote (presumably because cloud might be better), but this is not that and this feels very broken. Valid, recognized text is simply being thrown away after brief (speaking) pauses in the local-required case but not in the local-not-required case. In addition, in the case of setting the flag to 'false' to not require local recognition, the workaround still fixes it even when I have completely disabled all network connectivity on the iPhone (ie. it cannot make a remote call and the recognition is, by definition, being done locally). Other notes of potential interest: even if the workaround fixes it, part of my requirement is that it can always work whether remote calls are possible or not. Hence, why I set the flag to require local to true in the first place. as reported above the "isFinal" flag is never set to true during the time the earlier results are discarded i'm hearing that ios18 is even worse, specifically that setting the requiresOnDeviceRecognition to false does not help as a workaround. I have not yet verified this on ios18 because it is in beta at this time. Example to repro the bug: [with requiresOnDeviceRecognition = true] speaking "add 1+2+3+4+ (go as long as you want with no brief pauses)" results in exactly what was spoken. Doing the same with a brief pause followed by "5+6" results in all text preceding "5+6" being thrown away. By "brief pause" I mean 1 1/2 to 2 seconds. [with requiresOnDeviceRecognition = false] speaking the exact same as above with a pause as long as 2 minutes (maybe longer - I stopped testing at 2 mins) before adding "5+6" results in the full spoken text being returned (ie. the result contains "add 1+2+3+4+5+6". Again, this works even if iPhone networking is completely disabled.