Potential Structural Swift Concurrency Issue: unsafeForcedSync called from Swift Concurrent context

Thanks for bringing this over to the Apple Developer Forums.

On Swift Forums you wrote:

This isn’t actually crashing the app

Ah, confusing. There are multiple instances of code like this and some of them trap using fatalError(…) while others just log.

Is there a way I can set a breakpoint to catch this where it happens?

Try this:

(lldb) br set -s libswiftos.dylib -n os_log

I’m not 100% sure it’ll hit this breakpoint but, if it does, the backtrace should help you understand how you got there.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I've seen this error message too when running a very simple SwiftUI app (built using Xcode 26.0 (17A324)) on my device (iPhone 16 running iOS 26.0 (23A341)):

1. Start the app
2. Wait 10 seconds
3. Send the app to the background.

No other user interaction is necessary.

The LLDB statement you provided does catch the location of the error message. But the stack trace is not helpful, as non of my code is involved.

But what I've seen is that the error message is written to the console when the app is sent for the first time to the background. It doesn't appear anymore afterwards.

The call stack I've captured is:

#0	0x00000001a74e1280 in os_log ()
#1	0x00000001914d4218 in ___lldb_unnamed_symbol7481 ()
#2	0x000000018b2855c0 in ___lldb_unnamed_symbol14749 ()
#3	0x00000001914dc944 in ___lldb_unnamed_symbol7669 ()
#4	0x00000001914dce24 in ___lldb_unnamed_symbol7677 ()
#5	0x00000001de688520 in partial apply forwarder for closure #1 (Swift.UnsafeMutablePointer<Swift.Optional<Observation.ObservationTracking._AccessList>>) -> τ_0_0 in Observation.generateAccessList<τ_0_0>(() -> τ_0_0) -> (τ_0_0, Swift.Optional<Observation.ObservationTracking._AccessList>) ()
#6	0x00000001de67fc18 in withUnsafeMutablePointer ()
#7	0x00000001de67fb40 in Observation.generateAccessList<τ_0_0>(() -> τ_0_0) -> (τ_0_0, Swift.Optional<Observation.ObservationTracking._AccessList>) ()
#8	0x00000001de67ff00 in withObservationTracking ()
#9	0x00000001914dad74 in ___lldb_unnamed_symbol7647 ()
#10	0x0000000181785ef0 in merged closure #1 (Builtin.RawUnsafeContinuation) -> () in Swift.withCheckedContinuation<τ_0_0>(isolation: isolated Swift.Optional<Swift.Actor>, function: Swift.String, _: (Swift.CheckedContinuation<τ_0_0, Swift.Never>) -> ()) async -> τ_0_0 ()
#11	0x000000018178605c in (1) suspend resume partial function for Swift.withCheckedThrowingContinuation<τ_0_0>(isolation: isolated Swift.Optional<Swift.Actor>, function: Swift.String, _: (Swift.CheckedContinuation<τ_0_0, Swift.Error>) -> ()) async throws -> τ_0_0 ()
#12	0x00000001914dcc30 in ___lldb_unnamed_symbol7676 ()
#13	0x00000001914aa7f8 in ___lldb_unnamed_symbol6613 ()
#14	0x00000001817afe60 in (2) await resume partial function for Swift.withTaskCancellationHandler<τ_0_0>(operation: () async throws -> τ_0_0, onCancel: @Sendable () -> (), isolation: isolated Swift.Optional<Swift.Actor>) async throws -> τ_0_0 ()
#15	0x00000001914da668 in ___lldb_unnamed_symbol7643 ()
#16	0x00000001914adb30 in ___lldb_unnamed_symbol6682 ()

The unnamed symbols are from AXCoreUtilities.

The log with its meta data is:

Potential Structural Swift Concurrency Issue: unsafeForcedSync called from Swift Concurrent context.
Type: Fault | Timestamp: 2025-09-30 22:09:09.104033+02:00 | Process: TicTacToe | Library: AXCoreUtilities | Subsystem: com.apple.Accessibility | Category: AXCommon | TID: 0x621c23

interferon, It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

You wrote:

How much should I worry about this error?

That depends on what the backtrace looks like. If the backtrace leads to your code, that’s something you should worry about. If the backtrace only shows system code, that makes this log noise, as defined here.

I've seen this error message too when running a very simple SwiftUI app

I tried that here in my office and didn’t see the log. Specifically:

1. Using Xcode 26.0.1 on macOS 15.6.1, I created a new project from the macOS > App target, choosing SwiftUI as the language.
2. I ran that on my iOS 26.0 (23A341) test device (by a strange coincidence, it’s also an iPhone 16).
3. I waited for 10 seconds.
4. Then swiped up from bottom to send it to the background.

And it’s a bummer I can’t reproduce it because I might be able to learn more from seeing it in action.

Any idea what I might be doing differently from you?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I had the same issue and was able to find the cause using the os_log breakpoint!

Seems like this fires when AVSpeechSynthesisVoice is initialized inside of an asynchronous context.

this fires when AVSpeechSynthesisVoice is initialized inside of an asynchronous context.

Yeah, that’s the sort of thing I saw expecting.

And with that hint I was able to reproduce this trivially:

1. Using Xcode 26.0 on macOS 26.0, create a new project from the macOS > App template, choosing SwiftUI as the UI.

2. Add this code to the VStack in ContentView.swift:

   Button("Test") {
       Task {
           let voice = AVSpeechSynthesisVoice(language: nil)
           print(voice)
       }
   }
   

3. Choose Product > Run.

4. Click the Test button.

I’m not sure whether I’d consider that a bug or not, but it definitely warrants deeper consideration from the engineering team responsible for that code. Please file a bug about this, making sure to include a reference to this forums thread and also attach a sysdiagnose log taken shortly after reproducing the issue.

I’d appreciate you posting your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks, Quinn.

I think I normally wouldn't have worried too much about this, but since I'm in the midst of the Swift 6 concurrency migration, I was worried it was related to something in my code.

I think the message should state more clearly that it's an internal speech synthesizer issue, not really a "structural Swift Concurrency issue".

I filed FB20484368.

Thanks again for your help!

I filed FB20484368.

Thanks.

I was worried it was related to something in my code.

You are right to be worried here. While the problem isn’t with your code, the issue could affect your code. Lemme explain…

Actually, that explanation got way too long so I’ve moved the first part of it here: Waiting for an Async Result in a Synchronous Function

You can think of the unsafeForcedSync code as being like the mySynchronous(…) function from that post, except that it checks whether it’s being called from a Swift async function and logs if that’s the case. That log is not just noise: It tells you that you’re potentially exposing yourself to Swift concurrency thread pool exhaustion, and hence to a deadlock. But what you do about it is one of those classic engineering trade-offs. Do you leave it for Apple to resolve? Or do you take ‘heroic measures’ to move this work out of your Swift async function?

My inclination is to just leave it to Apple, but I wanted to explain the fundamentals so that you can make an informed choice.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"