Skip to content

3.0.0

Latest

Choose a tag to compare

@kylebrowning kylebrowning released this 21 Oct 02:24
2d46368

iOS 16 and 17 support

BLESwift 3.0.0 lowers the minimum platforms to iOS 16, macOS 13, watchOS 9, tvOS 16, and visionOS 1, and fixes a stack-overflow crash in long-running apps. It is a major release: public APIs that took a DispatchSerialQueue now take DispatchQueue. Code that passes a DispatchSerialQueue still compiles unchanged.

Changed

  • Breaking: every public API that took or exposed a DispatchSerialQueue now uses
    DispatchQueue (BackendRegistry factories, ProviderConfiguration factories,
    CoreBluetoothBackends, Central(adopting:connectedPeripherals:callbackQueue:),
    Central(backend:queue:…), PeripheralHost(backend:queue:…), the
    queue of every fake, virtual, and composite backend). The queue must be serial; a
    concurrent queue traps on iOS 17 and later. Code that passed a DispatchSerialQueue
    keeps working unchanged.
  • Breaking (floors lowered): minimum platforms are now iOS 16, macOS 13, watchOS 9,
    tvOS 16, visionOS 1 (were iOS 18, macOS 15, watchOS 11, tvOS 18, visionOS 2). The
    back-deployment code lives in two internal modules, BLESwiftCompat17 and
    BLESwiftCompat16, documented in the "Back-deployment" article.
  • Breaking: VirtualRadio.knownDeviceIDs is no longer public; it was an implementation
    detail.

Fixed

  • A long-running app crashed with EXC_BAD_ACCESS (a stack overflow) after some thousands of
    CoreBluetooth events — within minutes of a scan with allowDuplicates: true. Each delegate
    proxy stored its event handler directly as a Mutex value, and every read of a
    function-typed Mutex value wrapped the stored closure in two more reabstraction thunks
    (swiftlang/swift#91348), until calling it overflowed the stack. The handlers, and
    BackendRegistry's factories, now sit inside a struct. (#53)
  • VirtualPeripheralRemote (BLESwiftProvider) and LinkPeripheral (BLESwiftSimulatorLink)
    could report isNotifying on a characteristic whose service had just been removed: the
    answer to a notify request that landed after the didModifyServices re-armed the pruned
    characteristic. The notification state is now re-armed only while the characteristic is
    still discovered. (#42)