Fleeting Moments of Android Envy

They don’t happen often, but sometimes I do get envious of things over on Android, though I don’t imagine for an instant that there aren’t Android developers thinking the same of iOS (heaven help you if you try to do media on that platform). A few recent examples…

Fun With External Accessories

So, client gig has me working with an “Made for iPhone” device. The clued among you may have already cringed after reading that sentence. A colleague told me at 360iDev a few years back that MFi makes App Store policies look like a cake walk. “Have your lawyers call our lawyers” is apparently how MFi conversations begin. In this case, the client has dealt with all that, and has a working device.

Thing is, on iOS we talk to MFi devices via the External Accessory framework, which does its damndest to put an abstraction layer between you and the hardware, such that there is no difference between a dock-connected accessory and a Bluetooth MFi accessory (Bluetooth LE / Core Bluetooth is a totally different thing and doesn’t apply here). Maybe that’s a good thing in some cases? There’s definitely a nice clean abstraction over discovering available devices and opening I/O streams to them. And in typical Apple fashion, the I/O is all asychronous, so you don’t have to do your own threading to watch the ports, and that’s nice.

But sometimes the devil is in the details. Most paired BT MFi accessories connect to the iOS device immediately upon being turned on and stay connected. That doesn’t work for this client, where the app only wants to be on long enough for an occasional configuring of the device. Ideally, the app should be in control of making and breaking the connection. Unfortunately, on iOS, it can’t be. Connections are made in the Settings app (or via -[EAAccessoryManager showBluetoothAccessoryPickerWithNameFilter:completion:], which brings up a system-controlled picker), and can apparently only be broken by powering down the device or turning off Bluetooth in the settings app. The app knows when it’s done with the device and is ready to disconnect (which will allow the device to power down its Bluetooth), but the system gives us no way to do that.

On Android, the Bluetooth access is lower-level: the app is responsible for scanning for devices and getting the Bluetooth MAC of a selected device, which it then connects to, and is also responsible for closing the connection. More work, but more control, which is what I wish I had (even if it would mean managing the threading myself). Another bonus: hanging onto the MAC is a nice way to remember the last device you used (although EAAccessory devices do have a serial number that can serve the same purpose if the SN is properly set by the manufacturer).

Also, the iOS Developer Program and the MFi program are separate silos, so finding information and figuring out who to talk to is a problem.

Suffice to say that the Android version of this is long since ready to ship, and the iOS version that I’m responsible for is lagging. Sigh.

Maybe Open Does Win Sometimes?

Minor thing, but there’s a Kickstarter for a visual novel that’s targeting the desktop platforms, and I said “hey, it’d be a great stretch goal if you guys could say there will be an iOS version.”

They were really nice writing back with a detailed explanation about why they can’t commit to that. They need a Python runtime for their game engine, and apparently(?) there isn’t one on iOS. That kind of surprised me at first, until I remembered that I was the one throwing cold water on scripting languages on iOS as an idea that sounds good in practice but hasn’t panned out in reality. Still, while it might not surprise me that there aren’t success stories for Python on iOS, that nobody has it running at production quality? As popular as Python is? Huh.

Of course, Python is no sweat on Android. Apparently, the hold up with the visual novel on Android is the platform’s crappy video support. You don’t say!

Pause Button

One other thing that is far less easy to quantify… for most of this year, I’ve noticed a behavior in which long-time clients “press pause” on their iOS development indefinitely so they can “catch up” their Android versions. I’ve asked around about this and gotten head-nods from a few colleagues in Ann Arbor and Detroit (don’t know if this is a regional phenomenon or if I just haven’t case my net wide enough). In fact, if we get a “go” from a certain client, I might soon be porting some of my iOS work to a C library to be shared between iOS and Android versions of an app.

Some of the rivalry between iOS and Android comes from regrettable zero-sum thinking: if more people use my favorite platform, there’ll be more apps, accessories, etc. for it. More than not, though, I think this is a rising-tide-lifts-all-boats thing: more mobile development is good for all of us, and I’m happy to have more code running at where the user is (my old saw about “user-local programming”) than on some damn server somewhere.

But there is some degree to which limited client resources means more money spent on Android means less for iOS, and vice versa (or worse, more pressure for those awful cross-platform frameworks that look and feel like total crap). Marco makes the case that iOS 7 pressures companies that care to get their apps up to snuff on the platform, but in the contracting world, our clients often have better uses for their money — more relevant to their lines of business — than chasing Apple’s design whims.

Marco thinks that lots of developers will be spending the next couple months updating their apps for iOS 7. The big developers with top-100 apps, sure. But what about the other 700,000 apps? I’m not hearing anything about old clients wanting to sign up for an iOS 7 makeover yet, and when I put out the call on Twitter to see if anyone was getting iOS 7 upkeep work yet, I got zero positive replies.

Not time to worry, per se, but I’m watching how the next few months play out, maybe just a little warily…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.