Thanks for those crash reports.
Are you able to find a JSON crash report (.ips) for this? If so, please post it, because it may allow me to learn more about the issue.
In the absence of that then, yeah, at first blush this is looks like an Apple problem rather than a problem with your code. Consider the crashing thread from your first crash report:
Thread 22 name:
Thread 22 Crashed:
0 CoreFoundation … __CFCheckCFInfoPACSignature + 4 (CFRuntime.c:559)
1 CoreFoundation … CFRunLoopSourceSignal + 28 (CFRunLoop.c:4312)
2 Foundation … performQueueDequeue + 484 (NSThread.m:1063)
3 Foundation … __NSThreadPerformPerform + 88 (NSThread.m:1077)
4 CoreFoundation … __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (CFRunLoop.c:1970)
5 CoreFoundation … __CFRunLoopDoSource0 + 172 (CFRunLoop.c:2014)
6 CoreFoundation … __CFRunLoopDoSources0 + 332 (CFRunLoop.c:2059)
7 CoreFoundation … __CFRunLoopRun + 840 (CFRunLoop.c:2969)
8 CoreFoundation … CFRunLoopRunSpecific + 572 (CFRunLoop.c:3434)
9 Foundation … -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 (NSRunLoop.m:375)
10 TextToSpeech … -[TTSSpeechThread main] + 308 (TTSSpeechThread.m:63)
11 Foundation … __NSThread__start__ + 732 (NSThread.m:991)
12 libsystem_pthread.dylib … _pthread_start + 136 (pthread.c:931)
13 libsystem_pthread.dylib … thread_start + 8 (:-1)
Frame 10 is interesting. It indicates that the text-to-speech subsystem has an NSThread subclass that it uses for… well… something. Frames 9 through 5 indicate that this thread is running a run loop. Frames 4 through 0 indicate that the run loop is handling a run loop source, which is then crashing in frame 0 due to a PAC check. Typically this means that something has got corrupted.
Now, frame 3 is super interesting. This suggests that the run loop source is actually the result of Foundation’s thread perform feature, for example, a call to the perform(_:on:with:waitUntilDone:)) method. This gels with my understanding of how this thread works, that is, text-to-speech serialises work on that thread via perform(_:on:with:waitUntilDone:).
So, there are a couple of possibilities here:
- There’s a logic bug within the text-to-speech subsystem.
- There’s some sort of general memory corruption bug, and the text-to-speech subsystem is an innocent bystander.
I suspect it’s actually the first one, because this forums thread suggests that this issue is affecting multiple apps. However, that’s just a guess. Memory management issues are notoriously tricky.
If you run your app under the standard memory debugging tools, does it help make this issue more reproducible?
Oh, one last thing: All of those crash reports are from iOS 18 and earlier. Have you seen this reported on iOS 26?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"