迁移至Swift 6后macOS SwiftUI应用启动崩溃，如何调试？

我正在将一个小型SwiftUI macOS应用迁移至开启strict concurrency的Swift 6，已修复所有编译期错误，但应用现在启动即崩溃，仅得到以下崩溃信息：

libdispatch.dylib`_dispatch_assert_queue_fail:
    0x10033c974 <+0>:   pacibsp 
    0x10033c978 <+4>:   sub    sp, sp, #0x50
    0x10033c97c <+8>:   stp    x20, x19, [sp, #0x30]
    0x10033c980 <+12>:  stp    x29, x30, [sp, #0x40]
    0x10033c984 <+16>:  add    x29, sp, #0x40
    0x10033c988 <+20>:  adrp   x8, 70
    0x10033c98c <+24>:  add    x8, x8, #0xd27            ; "not "
    0x10033c990 <+28>:  adrp   x9, 69
    0x10033c994 <+32>:  add    x9, x9, #0x541            ; ""
    0x10033c998 <+36>:  stur   xzr, [x29, #-0x18]
    0x10033c99c <+40>:  cmp    w1, #0x0
    0x10033c9a0 <+44>:  csel   x8, x9, x8, ne
    0x10033c9a4 <+48>:  ldr    x10, [x0, #0x48]
    0x10033c9a8 <+52>:  cmp    x10, #0x0
    0x10033c9ac <+56>:  csel   x9, x9, x10, eq
    0x10033c9b0 <+60>:  stp    x9, x0, [sp, #0x10]
    0x10033c9b4 <+64>:  adrp   x9, 70
    0x10033c9b8 <+68>:  add    x9, x9, #0xcf6            ; "BUG IN CLIENT OF LIBDISPATCH: Assertion failed: "
    0x10033c9bc <+72>:  stp    x9, x8, [sp]
    0x10033c9c0 <+76>:  adrp   x1, 70
    0x10033c9c4 <+80>:  add    x1, x1, #0xcc1            ; "%sBlock was %sexpected to execute on queue [%s (%p)]"
    0x10033c9c8 <+84>:  sub    x0, x29, #0x18
    0x10033c9cc <+88>:  bl     0x10037eac0               ; symbol stub for: asprintf
    0x10033c9d0 <+92>:  ldur   x19, [x29, #-0x18]
    0x10033c9d4 <+96>:  str    x19, [sp]
    0x10033c9d8 <+100>: adrp   x0, 70
    0x10033c9dc <+104>: add    x0, x0, #0xd2c            ; "%s"
    0x10033c9e0 <+108>: bl     0x10037ac8c               ; _dispatch_log
    0x10033c9e4 <+112>: adrp   x8, 103
    0x10033c9e8 <+116>: str    x19, [x8, #0x428]
->  0x10033c9ec <+120>: brk    #0x1
Thread 3: EXC_BREAKPOINT (code=1, subcode=0x10033c9ec)

崩溃似乎发生在App的init方法中：

struct FocalApp: App {
    @NSApplicationDelegateAdaptor(AppDelegate.self) var delegate
    @StateObject var timerViewModel = TimerViewModel.shared
    @StateObject var settingsManager = SettingsManager.shared

    init() { // 崩溃发生在此处：断点已触发，但未进入闭包
        UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound]) { (success, error) in }
    }
}

调试与解决方法 #

• 理解崩溃本质：
  _dispatch_assert_queue_fail是GCD队列断言失败，意味着代码中存在块（block）被要求在特定队列执行，但实际运行在错误队列上的情况。Swift 6严格并发模式下，系统对队列合规性的检查更严格，之前隐式的队列违规现在会直接触发崩溃。

• 定位问题根源：
  你的init方法中调用了UNUserNotificationCenter.requestAuthorization，该方法的回调默认会在主线程执行，但SwiftUI App的init阶段，主线程可能尚未完成初始化，或者当前执行队列并非主线程，导致回调的队列断言触发失败。此外，@StateObject修饰的单例（TimerViewModel、SettingsManager）的初始化逻辑也可能存在队列违规。

• 修复步骤：

  1. 迁移权限请求时机：
     将通知权限请求移到onAppear修饰符中，此时App已完成初始化，主线程状态稳定：

     struct FocalApp: App {
         @NSApplicationDelegateAdaptor(AppDelegate.self) var delegate
         @StateObject var timerViewModel = TimerViewModel.shared
         @StateObject var settingsManager = SettingsManager.shared
     
         var body: some Scene {
             WindowGroup {
                 ContentView()
                     .onAppear {
                         UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound]) { success, error in
                             // 处理授权结果
                         }
                     }
             }
         }
     }
     

  2. 强制指定主线程执行：
     如果必须在init中执行，显式将操作包在主线程队列中，避免队列不匹配：

     init() {
         DispatchQueue.main.async {
             UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound]) { success, error in }
         }
     }
     

  3. 检查单例初始化逻辑：
     给单例添加主线程断言，确保初始化在主线程执行：

     class TimerViewModel: ObservableObject {
         static let shared = TimerViewModel()
         private init() {
             assert(Thread.isMainThread, "TimerViewModel必须在主线程初始化")
             // 其他初始化逻辑
         }
     }
     

• 额外调试技巧：

  • 在Xcode的Debug Navigator中查看崩溃线程的完整调用栈，找到触发断言的具体代码位置（可关闭Show Debugging Workflow > Always Show Disassembly回到Swift代码栈）。
  • 启用Xcode的Thread Sanitizer，帮助检测并发相关的队列违规和数据竞争问题。

内容的提问来源于stack exchange，提问作者Niek