Hi Thomas,
We're actively investigating this as we'd love to able to support all platforms, but I can't say for sure what will be possible or when yet.
Actually, this would be a great place for some help and advice from the community. Are there any iOS experts in the group? What do you think would need to happen to make the OpenXC vehicle interface compatible with iOS?
Namely, these are the problems and questions we have:
Bluetooth and USB I/O (besides the A/V protocol stuff) requires support for the iPod Accessory Protocol (iAP), and that requires an Apple authentication chip on the vehicle interface. It's currently difficult to impossible to do this even for hobbyist-oriented parts without an expensive and proprietary license agreement with Apple (the MFi program).
Bluetooth low energy doesn't require iAP, but it would require a completely different Bluetooth module on the vehicle interface (from either SparkFun's BlueSMIRF RN-42 based board that we recommend right now for the chipKIT vehicle interface, or the RN-41 that we're using in the prototype of a streamlined kit that we just unveiled). There are very few (or no?) Android devices that support Bluetooth 4.0 or BLE right now, too, so it would effectively mean the vehicle interface would fork to support iOS. Lastly, the max throughput over BLE is much less than Bluetooth or USB, so we would have to add throttling to the data stream to intelligently decide which data elements should be allowed through. A vehicle that implements every OpenXC data point at the frequencies specified on the OpenXC site right now runs at ~38KB/s. Granted, some of the frequencies could be decreased without too much practical effect on applications (torque at 60Hz is likely more than most applications need), but restricting data is counter to our goals of opening up as much as possible. We are trying to add more signals all of the time, and if we're fighting a ~35KB/s max throughput on BLE it would be unfortunate (but not a dealbreaker).
If we were somehow able to get the data into iOS (e.g. over wifi, since the chipKIT-translator does have an Ethernet port and could be hooked up to wifi router), it's not clear what is the best way to keep the data stream alive and present the data to applications. The Android library for OpenXC depends quite a bit on Android's freedom and flexibility with background services. We have one background service running in a remote process to manage the connection to the vehicle, and the data stream is multiplex to any and all OpenXC-enabled apps running on the device. With iOS the focus on foreground app performance means that background apps are significantly restricted and killed off after a relatively short time. From our own iOS experience and from our consultations with a few other experts, the best suggestion seems to be that each OpenXC application in iOS would need to manage its own connection to the vehicle interface, and no more than 1 could be running at any time. As soon as you switch away from an OpenXC data logging application, for example to check an e-mail or switch music tracks, the data stream would stop. That's a significant blocker for many applications. That said, we have been focused almost exclusively on Android for the last year, and there seem to be some applications out there that manage to keep a data stream going in the background - if anyone has ideas on that, please speak up!
Chris