The addition of the Multipeer Connectivity framework to iOS7 has created quite some buzz lately. Being able to establish direct connections between devices without much coding, in a fashion that “just works”, has long been a dream that has now come true. The multipeer connectivity framework wraps multiple technologies – WiFi and Bluetooth – and uses whichever is available to establish a connection between devices. iOS devices.

Android, on the other hand, comes with a bunch of different options for establishing local peer to peer connections. Most prominently, WiFi Direct, an open standard and Bluetooth are both open and usable. The problem again is that none of these technologies are available on the iOS platform, making the both completely incompatible in terms of high-bandwidth local connectivity without a central instance like a WiFi AP.

And here comes the problem. Depending on the geographical area and the demographics of your target audience, shipping an Android or iPhone-only product may be either risky, ambitioned or simply stupid. The question is: Is there any working alternatives capable of solving that problem?

NFC isn’t a possibility – it’s just not available on iOS. The only option left is Bluetooth LE (Low Energy). Interestingly, this technology is well supported on both iOS and Android.

Bluetooth LE is an addition to the the traditional Bluetooth environment and was introduced to enable low power communication between clients, like phones, and servers, like heart rate monitors. In this type of communication scenario, the bandwidth required is low, which is why the payload size is 21 bytes. You read that right: 21 bytes. That’s about 1.9% of a kilobyte and not that much. Of course you can send a larger message by sending a lot of small ones, but this is just not what the designers of BLE had in mind.

Both Android and iOS can serve as a client BLE device, meaning they can consume services, subscribe to their data and even talk back if the server device allows for that. An example taken from Apple’s documentation states a thermostat as a server example accepting input to set the desired room temperature. So, what’s the conceptual difference between a client and a server? Servers announce themselves, much like WiFi access points. Clients can listen for those announcements and browse nearby servers. Clients do not announce themselves, they are only made to consume.

iOS supports acting as a server, too. This means that you can configure your iOS device to publish a BLE service, thus enabling P2P using BLE. Sadly, this is feature that is not supported on Android to date, so to work around, each Android device would need to connect to an iOS device to announce it’s presence. It is hacky, but it works. This approach has one major disadvantage: while Android to iOS and iOS to iOS communication works that way, Android to Android doesn’t. Since there’s a plethora of possibilities for implementing that directly using the different technologies available on Android, one could imagine that using all those technologies combined, a homebrew solution for the P2P is possible – depending on different technologies, a lot of workarounds and with catastrophic bandwidth.

Edit: Luckily, the paragraph above is no longer true as Android 5.0 supports Bluetooth as a Peripheral. That’s nice.

For reference, here is the complete compatibility chart of the technologies mentioned. The answers depend on whether a technology is usable as a developer without any extra effort (i.e. joining Apple’s made for iPhone program).

Technology iOS 7.1 Android 4.4
Bluetooth 2.1 No Yes
WiFi Direct No Yes
Multipeer Connectivity Yes No
NFC No Yes
BLE Central Yes Yes
BLE Peripheral Yes Yes