Hi Ralf,
I’m not from Apple but I’ve worked on both BLE and Classic/MFi apps talking to devices.
For Classic BT profiles supported by iOS there is usually no need to install a custom app. The system will take care of those (for example, for most of the audio/messaging profiles). If you have a device implementing a custom protocol using IAP then you can define a custom app/bundle ID which the system can use to prompt the user to go and install. The UX flow is that you turn on the device and the system searches the appstore for an app matching that ID which they can then install it. For IAP you need to follow Apple’s MFi guidelines. On the app side you need to use Apple’s Accessory framework which can only be used by those folks signed up for MFi.
For BLE you don’t need to do any of these. There is no need to go through MFi certification (this was one of the big selling points of BLE for most developers). On the app side you use the CoreBluetooth framework and can create custom protocols on top of a pre-defined communication model defined by the Bluetooth SIG. In this universe you have general purpose services and characteristics which you can define in any way you want. The down side is the communication is much slower than Classic with IAP but your device is presumably much more power-efficient (hence the Low Energy part of BLE).
To build a BLE app you define your services and characteristics. If you need more than 20 bytes at a time you need to define your own custom streaming protocol. Then you build that protocol handling code in both your device firmware and your mobile app. You can then ship your app and device without having to go through any sort of MFi certification.
The feature you’re asking about… to have the system prompt the user to install the right app, unfortunately doesn’t exist in BLE world. This is one of the side-effects of not having to go through MFi, since Apple has no way to verify that two developers aren’t using the same app bundle/ID.
The way most people do it is to instruct users (often on the app package or in documentation) to go download the app and run it. On first run the app scans for any devices implementing the device's custom service UUID. Once the device is turned on the app then connects to that device, establishes pairing (if necessary) and starts exchanging information with the device through the pre-defined characteristics.
If you need to support the model where you turn on a device and then the app for it automatically runs there’s a way to get close to that with BLE (after the app has been downloaded and run once) but it can get pretty complicated. Probably easier if you re-think your application/device interaction to better follow the BLE model. Or if you really need that interaction, may want to stick with IAP and MFi.
Hope this helps.
Best, Ramin
On October 21, 2016 at 5:02:58 PM, Ralf Rottmann (email@hidden) wrote:
Hi Everyone,
We understand that in
order for iOS to show the system prompt which asks a user to
install a companion app, the HW vendor needs to be an MFi
member.
However, we don't quite
understand the exact technical
requirements. Hopefully, somebody from Apple can
clarify:
- Is this functionality
available for BLE only connections, too? Or does it require BL
Classic?
- What exactly is
required MFi wise?
- How does the accessory,
given that it is a single-mode BLE device, tell iOS which app to
install? E.g. how is the bundle or App Store ID
transmitted?
Any help would be
greatly appreciated.
Ralf
grandcentrix GmbH
Schanzenstrasse 6-20
51063 Köln,
Deutschland
phone: +49
221 677 860 0
fax: +49
221 677 860 99
Amtsgericht
Köln | HRB 70119 | Geschäftsführer: R. Rottmann, M. Willnow |
USt.-IdNr.: DE266333969
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|