Compilation errors with Reference code related to Swift concurrency

[inzan]

Affected Skill

core-bluetooth

Reference File (if applicable)

skills/core-bluetooth/references/ble-patterns.md

What is incorrect?

Hi - thanks for sharing this skill. Just a small issue to report.

The CoreBluetooth reference code will not compile under Swift 6.2 with strict concurrency enabled. Passing non-sendable CoreBluetooth types across an actor hop is not allowed. For example below, a CBPeripheral is passed from nonisolated domain to MainActor. Even though underneath CoreBluetooth is using main queue, the compiler can't verify this so I end up getting "Sending 'peripheral' risks causing data races" wherever it passes a CB type into the Task block.

nonisolated func centralManager(
    _ central: CBCentralManager,
    didDiscover peripheral: CBPeripheral,
    advertisementData: [String: Any],
    rssi RSSI: NSNumber
) {
    Task { @MainActor in
        let name = peripheral.name ?? "Unknown"
        let device = DiscoveredDevice(
            id: peripheral.identifier,
            name: name,
            rssi: RSSI.intValue,
            peripheral: peripheral
        )
        if !discoveredDevices.contains(where: { $0.id == device.id }) {
            discoveredDevices.append(device)
        }
    }
}

If you'd like I could make a small PR to fix, I think the fastest way would just be to do something like

@preconcurrency import CoreBluetooth

Thanks again!

Apple Documentation References

https://developer.apple.com/documentation/Swift/Sendable

Key Section: The "Overview" section explicitly states: "You can safely pass values of a sendable type from one concurrency domain to another..." and details what the compiler requires for structures, actors, and classes to pass those checks.

Environment

XCode 26
Swift 6.2 with Strict Concurrency

Prompt or Context (optional)

No response

[dpearson2699]

@inzan thanks for the report. I checked the affected reference snippet in skills/core-bluetooth/references/ble-patterns.md against the current repo target toolchain I have locally:

• Xcode 26.5 / Apple Swift 6.3.2
• iPhoneOS 26.5 SDK
• -swift-version 6
• -strict-concurrency=complete
• -warn-concurrency
• -require-explicit-sendable

With the surrounding BLEViewModel context and delegate conformances included, the snippet typechecks cleanly for me under those settings.

I do not want to dismiss this as invalid, though. The Apple Sendable documentation supports the general concurrency rule: values that cross concurrency domains need to be safe to send. That explains why this class of diagnostic can happen. It does not, by itself, prove that this specific CoreBluetooth delegate snippet must fail in every current compiler configuration. CoreBluetooth is also an Objective-C framework, and Swift's preconcurrency migration behavior can affect how imported framework types are diagnosed.

So the distinction is: the docs support why the compiler could reject this pattern, but my local Swift 6.3.2 check shows the current repo-target snippet does compile under complete strict concurrency.

Could you share the exact Xcode build number and full compiler diagnostic, ideally with a minimal project or package that reproduces it under Swift 6.2? If this is Swift 6.2-specific, we can either document @preconcurrency import CoreBluetooth as a compatibility workaround or adjust the sample to avoid the diagnostic.

[inzan]

XCode Version 26.4 (17E192)
swift-driver version: 1.148.6 Apple Swift version 6.3 (swiftlang-6.3.0.123.5 clang-2100.0.123.102)
-swift-version 6
-strict-concurrency=complete

BLEPatterns.zip

Here's the compiler output:

~/Dev/Scratch/BLEPatterns/BLEPatterns/ContentView.swift:66:29: error: sending 'central' risks causing data races
isBluetoothOn = central.state == .poweredOn

~/Dev/Scratch/BLEPatterns/BLEPatterns/ContentView.swift:66:29: note: task-isolated 'central' is captured by a main actor-isolated closure. main actor-isolated uses in closure may race against later nonisolated uses
            isBluetoothOn = central.state == .poweredOn
                            ^~~~~~~
~/Dev/Scratch/BLEPatterns/BLEPatterns/ContentView.swift:77:35: error: sending 'peripheral' risks causing data races
            let name = peripheral.name ?? "Unknown"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
~/Dev/Scratch/BLEPatterns/BLEPatterns/ContentView.swift:77:35: note: task-isolated 'peripheral' is captured by a main actor-isolated closure. main actor-isolated uses in closure may race against later nonisolated uses
            let name = peripheral.name ?? "Unknown"
                       ~~~~~~~~~~~^~~~
~/Dev/Scratch/BLEPatterns/BLEPatterns/ContentView.swift:96:33: error: sending 'peripheral' risks causing data races
            peripheral.delegate = self
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
~/Dev/Scratch/BLEPatterns/BLEPatterns/ContentView.swift:96:33: note: task-isolated 'peripheral' is captured by a main actor-isolated closure. main actor-isolated uses in closure may race against later nonisolated uses
            peripheral.delegate = self
            ~~~~~~~~~~~~~~~~~~~~^~~~~~

[dpearson2699]

Thanks for the repro. The underlying Core Bluetooth guidance is still correct, but the Swift 6 concurrency sample should be revised. The bug is the sample’s nonisolated delegate methods plus Task { @MainActor } bridge, not the statement that Core Bluetooth uses the main queue when initialized with queue: nil.

I was able to reproduce the same diagnostics from the attached project under Xcode 26.6 / Apple Swift 6.3.3 with -swift-version 6 and complete strict concurrency. @preconcurrency import CoreBluetooth does make the repro compile, but I’m going to treat that as a compatibility escape hatch rather than the primary pattern.

I’ll update the reference sample to keep delegate handling on the @MainActor view model when using queue: nil, removing the nonisolated + Task hop that captures non-Sendable Core Bluetooth objects.