24
votes

The vibe I'm getting from Stackoverflow and the internet at large is that unless I'm using an LE device, any Bluetooth device I make for an iOS app must be MFi certified.

However, on the MFi FAQ page, I found this line:

...developers of accessories that rely solely on standard technology (e.g., Bluetooth Low Energy or standard Bluetooth profiles) do not need to join the MFi Program.

My device will be able to use the standard Bluetooth profile File Transfer Protocol (FTP).

Now this sounds like some conflicting advice to me, or perhaps I'm just not understanding correctly. So, having provided the above evidence, I'm just going to ask outright: Can I write and publish an iOS app that connects to a proprietary Bluetooth device using the standard Bluetooth profile FTP without certifying my device as MFi? And if so, what details, caveats, etc do I need to know?

2
It seems like everyone says MFi is required. I'm hoping someone can help me figure out what this line in the FAQ means.Aaron
FTP is a standard BT profile, but not supported by iOS. As a result, it has to go through MFi.RAX

2 Answers

15
votes

That line is referring to standard profiles supported natively by ios devices, such as HFP or A2DP. If you build a headset device that does HFP, the iphone will be able to connect to it and route your call to the headset without the headset being part of MFi.

If you want to write an app that does other things with bluetooth, inlcuding FTP, you would have to use MFi.

27
votes

The new Bluetooth 4.0 Low Energy (hereafter BLE 4.0) specification which is implemented in Apple's latest iOS devices does allow one to create app-specific profiles and connect to BLE 4.0 devices without jailbreaking, using an approved Bluetooth 2.1 profile, or becoming part of Apple'd MFI program and using the previously required MFI cryptographic chips.

In other words with the proper BLE 4.0 compatible bluetooth radios you can create wireless devices that connect to iOS apps without having the device pre-approved by Apple. However, you must write a custom app for the device, and Apple still holds the ability to reject that app if they want to. So they still control this to a great degree. This is essentially Apple's answer to the Android ADK, while not fully relinquishing the ability to shut down apps and devices they don't like.

Your app must include specific XML schema for your app's bluetooth profile, and use CoreBluetoothFramework APIs, so it's very obvious to Apple during the app approval process that your app connects to a device. If your app does not work without the device present, then it's likely to be rejected if you are not part of the MFI program, as Apple cannot test the app without your device. The apps that appear to be successful in passing this test use the device as an accessory to app functionality, rather than a requirement. For instance an exercise app might connect to a BLE 4.0 heart rate monitor, but the app doesn't depend on it.

Some apps seem to be getting around this by displaying simulated, or online information in place of the device information when no device is present. Thus the app can be tested without the device, and functionally works when the device is present.

You can find out some successful efforts online:

http://blog.makezine.com/2012/03/19/bluetooth-4-0-from-arduino-to-iphone-no-jailbreaking-no-mfi/

BlueGiga in particular has been pushing their devices specifically for this use, so there are probably forums and support for this elsewhere.

Keep in mind that the devices that currently support BLE 4.0 are limited, and currently only include

  • iPhone 4S and later iPhones
  • recent MacBook Air, Mac Mini
  • iPad (3rd generation and later, and iPad mini)
  • Macbook Pro Retina

There may be other Apple devices that support this standard, it's something Apple is advertising openly on each product's technical specifications page so it's easy to find for current products.