This is a repo that will accompany a class on introduction to Core Bluetooth.
The project consists of two parts: "Apps," that are complete, standalone applications (one for each Apple platform: MacOS, iOS/iPadOS, tvOS, and watchOS), and "SDKs," which are Swift Frameworks, embedded into each app. These frameworks implement the Core Bluetooth functionality, and are the target of the lesson, while the apps are merely high-functioning test harnesses.
The main focus of the lesson will be on the SDKs.
The entirety of the SDK code is shared between platforms, with the exception of this file, which is only included in the MacOS and iOS/iPadOS targets (it implements Peripheral Mode, which is not supported in TV or Watch).
The various target directories (MacOS, iOS, watchOS, and tvOS) contain only a single plist file, each.
There is a separate target for each platform, with the naming convention of "ITCB_SDK_XXX", where "XXX" is replaced with the target operating system ("Mac", "iOS", "Watch", or "TV").
Each target is a dynamic "pure Swift" framework. By "pure Swift," we mean that there is no bridging header. Only Swift applications can use the SDK.
The apps are "Ship-quality" apps, written to the standards of any apps destined to be sold/distributed through the various Apple App Stores. They are localizable and carefully designed.
They are not "super-advanced" apps, though. They don't use SwiftUI, for example; instead, sticking with the traditional Interface Builder.
They aren't the star of the show, and the lesson doesn't deal with them at all, except to mention the need for some plist values and a sandbox setting.
The apps implement a rather simple "game," based on the famous Mattel Magic 8-Ball Toy.
It requires two devices (at least), with one acting as a "Central" (the "question-asker"), and the other[s] acting as a "Peripheral" (the "question-answerers").
There will only be one Central, but there can be more than one Peripheral.
Only iOS/iPadOS and MacOS support Peripheral Mode, so those are the only app variants that can act as "question-answerers."
NOTE: The following example images are from the iOS app, on an iPad and an iPhone.
Figure 1: The Initial Mode Selection Screen
In this screen, the user is presented with two image buttons: "CENTRAL", and "PERIPHERAL".
They each represent an operating mode for the app.
This screen is only shown at startup, and "commits" the user to that mode, thereafter. In order to change modes, the user needs to exit the application, and restart.
In Central Mode (which is also the only mode for tvOS and watchOS), the app acts as a "question-asking" app. The user is presented with a list of nearby Peripheral Mode devices in a simple, vertical table.
Figure 2: The Central Mode Screen
Once a user selects one of the Peripherals, they are taken to a simple screen, with just a text entry field.
They use this field to "ask a question" of the Peripheral. It should be a "yes/no" question.
Figure 3: Asking a Question
The Peripheral will automatically return an answer, randomly selected from the 20 standard answers.
Figure 4: Getting the Answer
NOTE: In the Watch variant of the app, there is no room to enter a question, so one of 20 random questions is selected to be sent.
In Peripheral Mode (Again, only for iOS/iPadOS and MacOS), the user doesn't do anything. The app reacts automatically to questions from the Central.
Figure 5: Waiting for a Question
Once a question is asked of a Peripheral, it is reported in an alert.
Figure 6: Reporting an Answer
NOTE The alert needs to be dismissed by the user, so there is "a bit" of user interaction in Peripheral Mode.
In order to run the apps, using Core Bluetooth, it is necessary to add some fields to the app info.plist file. The App Store will not allow release of apps that don't have these rows:
NSBluetoothPeripheralUsageDescription(Deprecated)NSBluetoothAlwaysUsageDescription(Current)
I usually add both, even though NSBluetoothPeripheralUsageDescription is no longer necessary.
If you do not include at least NSBluetoothAlwaysUsageDescription, your app will experience a runtime crash, as soon as a Core Bluetooth call is made. If you are not running the debugger, it can be difficult to figure out why this happened. The debugger gives a very clear console message; explaining the issue.
For MacOS, there is an additional step that needs to be taken, if you wish to use the App Sandbox:
Figure 7: The Sandbox Checkbox
In order to set this, you need to select the MacOS target, then, in the top tab bar, select "Signing & Capabilities," select "All" (or at least "Release"), then, scroll to the "App Sandbox" section, and select "Bluetooth," in the "Hardware" section.
If this is not checked, you won't get a crash, but the Bluetooth subsystem just plain won't work.