It looks like Apple has added some new API(s) to SFSpeechRecognition My app, which is currently listed on App Store does feature speech recognition. Yet, trying to use it under iOS 18.0 throws errors: -[SFSpeechRecognitionTask localSpeechRecognitionClient:speechRecordingDidFail:]_block_invoke Ignoring subsequent local speech recording error: Error Domain=kAFAssistantErrorDomain Code=1101 "(null)" What happens is that after several words are transcribed and displayed, the next sentence results in previous words disappearance. That's probably what that portion of the error text - "Ignoring subsequent local speech recording error: Error Domain=kAFAssistantErrorDomain Code=1101 "(null)" means. The problem occurs ONLY when the app is running under iOS 18.0 Even when it's compiled in Xcode 16.0 using iOS 17.5 everything works fine. Any suggestions?
Speech Recognition Problem in iOS 18.0
The follow-up to the previous post. It looks likes during dictation if I make even a short break - 1-2 seconds, the previously transcribed words disappear and the transcription starts anew. Let me reiterate, that does NOT happen under iOS 17. The app downloaded from the store functions as expected. Yet the very same code compiled under iOS 18 shows the problem: even a 2-second pause in talking truncates the previously transcribed text and starts anew. The quickest and simplest test is to run Apple demo app 'Spoken Word' Any insights would be greatly appreciated.
One more attempt to get an answer, or at least a cofirmation that the problem does exist. If somebody willing to spend just couple of minutes to run Apple own demo app 'SpokenWord' - https://developer.apple.com/documentation/speech/recognizing_speech_in_live_audio?language=objc - under iOS 18.0 Here's what I ask: start dictation and make a natural pause - say, 1-2 seconds. What you are going to see is that the previously transcribed text is completely truncated and the transcription starts anew. Once again: it's Apple own demo app
@iaborodin Did you get anywhere with this? I’m looking into fixes and workarounds now with some urgency. Happy to chat, you can reach me at 34534543456789098767654 @ mailer.city.
@34534543456789098767654 No, I haven't found a solution to the problem - intermittent truncation of transcribed dictation. So, I reverted to Apple standard way - using its keyboard dictation functionality, which works as expected. By the way, for some unclear reason(s) after a few instances, the error messages that I mentioned in initial post stopped appearing.
(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.
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?
I just wanted to mention that I’m also experiencing this issue and haven’t found a great working solution. I’ve reached out to Apple.
It's also worth noting that I've only seen this happen on iOS 18.0: After you finish speaking and pause, the transcribe function is called again, causing a duplicate transcript. This usually results in the following transcription overwriting the previous one.
@Squids "I’ve reached out to Apple"
Me too :), but so far no response.
Same problem here.
Same here.. I wonder if this problem occurs with all devices. Only 15 ProMax is working correctly, as far as I tested.
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 got an email back from DTS team and they told me to submit a bug report via the Feedback Assistant (https://feedbackassistant.apple.com) which I've done under the Developer Technologies & SDKs topic.
I encourage everyone else to submit one as well. Hopefully if enough people submit a report they'll take a look at this bug.
What was that bug number?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Sure thing, it's FB15166325
Also. FB15192539