You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PR #273 highlighted a real gap for Apple developers: consuming already-built SimpleBLE binaries from a native Xcode project is different from consuming SimpleBLE through CMake. CMake users get transitive usage requirements from simpleble::simpleble, but native Xcode users who manually add a static or dynamic library do not automatically get the required headers, Apple frameworks, runtime libraries, or permission guidance.
Goal
Add and document an Apple-native package format for SimpleBLE, likely an XCFramework and, if useful, package metadata for Swift Package Manager and/or CocoaPods. The goal is to make native Xcode consumption work without asking users to reverse-engineer CMake link interfaces.
Requirements to evaluate
Choose the smallest Apple package format that works for SimpleBLE's supported Apple platforms.
Include public SimpleBLE headers and the built library artifacts in the package.
Preserve or clearly declare required Apple system dependencies:
macOS: Foundation, CoreBluetooth, IOBluetooth, IOKit, Objective-C runtime linkage, and the C++ runtime as needed.
iOS: Foundation, CoreBluetooth, Objective-C runtime linkage, and the C++ runtime as needed.
Decide whether the package should be static, dynamic, or both, and document the tradeoffs.
Document required app-level Bluetooth permission keys, such as NSBluetoothAlwaysUsageDescription; the package cannot set these for the consuming app.
Provide native Xcode usage instructions that distinguish this package path from the recommended CMake path.
Add or update release/CI automation so the package can be produced consistently.
Validate with a minimal native Xcode consumer project that links the package and uses SimpleBLE successfully.
Acceptance criteria
A release artifact or documented build command produces the chosen Apple package format.
A native Xcode app can consume the package by following the docs, without manually discovering SimpleBLE's transitive dependencies.
Existing CMake consumption through find_package(simpleble REQUIRED CONFIG) and target_link_libraries(... simpleble::simpleble) remains documented as the preferred path for CMake-based projects.
Context
PR #273 highlighted a real gap for Apple developers: consuming already-built SimpleBLE binaries from a native Xcode project is different from consuming SimpleBLE through CMake. CMake users get transitive usage requirements from
simpleble::simpleble, but native Xcode users who manually add a static or dynamic library do not automatically get the required headers, Apple frameworks, runtime libraries, or permission guidance.Goal
Add and document an Apple-native package format for SimpleBLE, likely an XCFramework and, if useful, package metadata for Swift Package Manager and/or CocoaPods. The goal is to make native Xcode consumption work without asking users to reverse-engineer CMake link interfaces.
Requirements to evaluate
Foundation,CoreBluetooth,IOBluetooth,IOKit, Objective-C runtime linkage, and the C++ runtime as needed.Foundation,CoreBluetooth, Objective-C runtime linkage, and the C++ runtime as needed.NSBluetoothAlwaysUsageDescription; the package cannot set these for the consuming app.Acceptance criteria
find_package(simpleble REQUIRED CONFIG)andtarget_link_libraries(... simpleble::simpleble)remains documented as the preferred path for CMake-based projects.-- Riley