For years, in music technology and computing, we’ve relied on an idea so ubiquitous, we take it for granted. That notion is that you can use things together, and they work. At its soul, MIDI gives us the power to assemble different sounds, to record ideas. It means the investment you make in one device, whether a soundmaker or computer, can be expanded. Just brought a new gadget home? Plug it into the old gadget, and use them together.
There’s another notion, even more fundamental, underneath that idea: if you save up your pennies and buy gear, you get to choose what to do with it. This is neither a desire of “advanced” users – on the contrary, casual users of technology are often the first to assume that things will work the way they want.
What if that weren’t true?
I was intrigued, as were many on this site, by the announcement of a MIDI adapter for the iPhone. It’s something I expected from the moment Apple announced support for third-party hardware. It’s a little thing, and definitely a niche product, but that means the ability to turn your shiny, little mobile device into a portable recorder for musical ideas – even with, unmodified, a mid-80s keyboard. Score one for standards.
Line 6 MIDI Mobilizer (hardware) + MIDI Memo Recorder app (software)
But with countless apps for music making on the iPhone already – and many more coming to the iPad – you probably would want to use this MIDI support with more than one app. You might take for granted (there’s that phrase again) the power of connectivity. That’s how computing platforms work.
Not so with the iPhone, and by extension, the iPad.
Hardware must support Apple’s proprietary protocols and APIs, and it requires signing legal documents which, among other things, prevent developers from talking about the contents of the legal agreements and disclosing certain developer features. Partly because of the restrictiveness of these terms, there’s even a murky issue that raises questions about whether more than one application publisher can support a given accessory.
The result is anything but “friendly to beginners,” unless the iPad and iPhone are catering to lawyers.
MIDI, Minus the Compatibility
Line6 have built a really cool little gadget. It plugs into an iPhone, iPod, or soon an iPad, and via their software provides quick recording and playback of MIDI files. And to Line6’s credit, they’ve extended an open invitation to developers to support it. The problem is, supporting any accessory iPhone/iPad hardware is restricted by Apple not technically, but legally.
From Line6’s FAQ:
Can I use MIDI Mobilizer to control synthesizer applications or play other music apps on my iPhone?
This is technically possible, but would require software updates to each application in order to communicate with MIDI Mobilizer. Additionally, the developer of the application would need to become a Line 6 MIDI Mobilizer developer in order to be given the development tools, and allow Line 6 to publish their MIDI Mobilizer-enabled version (currently, all applications for a hardware accessory must come from the same publisher). If there’s an application you’d like to see work with MIDI Mobilizer, please have the developer contact MMdeveloper [at] line6.com for more information.
Line6 can’t talk to me about Apple developer agreements, because they are contractually bound to keep those details to themselves – details below. However, I was able to ask whether the restriction on publishing was one they had imposed.
Their answer: no, they didn’t come up with this restriction. Their understanding of the Apple accessory program is that only one publisher for an app that works with a specific accessory can provide compatibility for the accessory.
While the EFF has released the main developer agreement, I have not seen a public copy of the separate accessory program agreement. But I can confirm at least part of Apple’s requirements for proprietary accessory development below.
Because the accessory document is not available, I’m happy to be corrected. Please, if we’re wrong about this, if there’s a counter-example of an app, let us know, and I’ll investigate. I’d actually like to be wrong, as then we could open the floodgates on more compatible apps.
Assuming this is correct, however, we can assume that multiple applications from multiple developers can’t support a non-Apple accessory, unless they come from the same publisher. And that’s a pretty big issue, if the iPad is – as people claim – the future of computing.
Sure, this is just for hard-line gear you plug in via the connector. And yes, wireless communication still uses open standards for Bluetooth, Wi-Fi (TCP/IP and UDP), and zero-configuration networking or Zeroconf (what Apple calls Bonjour). But those are the exceptions that prove the rule: standards are good. Standards make things work.
And that’s what Apple has done: they haven’t simply simplified a design to make it friendlier to non-techies, or to make the iPad extra slim. You can make non-standard connectors that still work with USB, or use standard, slim-line USB connectors. The Apple Dock Connector is just the physical connection: inside are the actual signals that replace the video, device, and audio connections. What Apple has done is not simply change the technical and industrial design: they’ve added legal restrictions around that design.
Updated – Apple’s language seems to allow any third-party app to support any third-party hardware driver. That would conflict with Line6’s interpretation. (I get the impression that Line6 is interested in making this work with third-party apps, so it is possible that this will get sorted – one advantage of writing online and updating information is that we do get your feedback and, hopefully, we all know more after the article than we did before.) From Apple’s invitation:
Extend the capabilities of your application by monitoring and controlling external devices, or create entirely new integrated solutions that combine your iPhone app with dedicated hardware.
Your application can communicate with your own accessory using a custom protocol, or any accessory that uses a standard protocol provided by the manufacturer.
If you are developing an application that works with an accessory, use the new Accessory APIs in iPhone SDK 3.0 to identify and communicate with external hardware.
If Line6 did misinterpret the language here or not, however, it does illustrate the issue with having to reinvent mechanisms for hardware to talk to other hardware over physical connectors. The proprietary nature of the Dock Connector breaks the kinds of standards and interoperability that USB manufacturers have built over years – aided, ironically, by the efforts of one Apple Computer (back when they still had “Computer” in their name). And the lack of free communication and free development also remains a problem – it stops vendors like Line6 from feeling they can communicate freely, and it stops, say, tinkerers on CDM from building a little kit that would let you connect your own MIDI adapter and the like.
Further update – Bluetooth communication is also bound by Apple’s hardware developer agreements, as confirmed for us by an iPhone/iPad application developer:
Bluetooth on iPhone and iPad counts as an accessory just like USB not like TCP/IP over Wifi. Bluetooth devices must use same ID protocol and licensing as USB and serial accessories. There are a few classes of Bluetooth devices that are generically supported, but everything else is subject to Apple’s control.
There is some support for ad-hoc Bluetooth networking, independent of this issue, as used for games. But that means that even some Bluetooth solutions may be restricted. (That’s a whole independent topic, so I won’t attempt to cover it comprehensively here, other than to say, you may want to fully research these options before committing.)
No, You Can’t
Whatever the specific restriction around accessories, in general, the terms of the Apple developer agreements can be chilling.
Apple’s iPhone Developer Program License Agreement is a non-public document. The moment a developers signs it, they are contractually obligated not to speak “publicly” about the document. (Some iPad apologists might say, ah, but this is true of many game console developer programs, to which I ask, when did I say that was a good idea? And did that really help make Dragon Age more reliable?)
Thanks to the Electronic Frontier Foundation and the Freedom of Information Act, however, the non-Apple lawyers found a loophole: force NASA, a government agency, to release its document. You can read the results (including, in detail, section 10.4 which bans developers from discussion):
UPDATED: All Your Apps Are Belong to Apple: The iPhone Developer Program License Agreement
I can at least refer to this section:
3.3.20 Your Application may interface, communicate, or otherwise interoperate with or
control an iPhone Accessory (as defined above) through Bluetooth or Apple’s 30-pin dock connector only if You have obtained a license for such iPhone Accessory under Apple’s MFi Program.
The MFi Program refers to “Made for iPod.” There is at least one case of Apple suing a vendor who tried to make hardware without that license, so it’s clear Apple is serious about their intellectual property there.
I can’t refer to the specifics of that license, because they’re not published. In fact, you have to apply for the program before you know the details of the program, and once you do know those details and sign the agreement, you’re obligated not to share them.
Because you need an application to support any hardware, and Apple has complete control over what applications are available through the store, and because jailbreaking iPhones, barring an exemption ruling, theoretically violates the Digital Millennium Copyright Act, and because you violate Apple’s developer agreement just by making your app available through jailbreak software sources, Apple is the true, final arbiter on any matter of hardware support, as they are all matters of developing for their device. (Clarification added: the EFF is awaiting a ruling on an exemption request for jailbreaking. In the meantime, that theoretically means the de facto state of jailbreaking is a violation of the DMCA, at least here in the US.)
Here’s Apple, again in the developer agreement, on the matter of hardware support:
You agree to inform Apple in writing through iTunes Connect if Your Application connects to a physical device, including an iPhone Accessory, and, if so, to disclose the means of such connection (whether iAP, the headphone jack, or any other communication protocol or standard) and identify at least one physical device with which Your Application is designed to communicate. If requested by Apple, You agree to provide access to or samples of any such devices at your expense (samples will not be returned).
That may be defensible when it comes to verifying quality or providing an official Apple certification. But it shuts down the possibility of DIY hardware, or, as in this scenario, even cases that would provide greater compatibility, interoperability, and usability. I will retract the assumption, for now, that one piece of hardware can’t be supported by multiple apps. It wouldn’t make a whole heck of a lot of sense.
But the other concerns remain. If Apple is going to add this additional burden, and if the iPad is going to become as successful as a general-purpose computing device as many think it is, it does become an issue to see if the kind of hardware connectivity that’s possible on other devices will be possible here.
Why this isn’t just for “techies”
A common characterization of iPad criticism is that it’s technological “elites” who care more about features than design.
David Pogue writes in The New York Times (a newspaper heavily invested in the success of the iPad, though that is not disclosed):
In any case, there’s a pattern to these assessments. The haters tend to be techies; the fans tend to be regular people.
Pogue provides no evidence for this description, which is odd, as my experience has been that non-techies generally don’t really understand why techies are so excitable either way. (As for whether “they” want an iPad, they seem as polarized as everyone else. Plenty of non-techies love their QWERTY and have other places to spend $500.)
But it’s a brilliant argument. The only people who would likely debate you – technical experts – are magically excluded from the discussion. “Ah,” says the technical expert. “But you’re a technical expert. It’s not for you. So you’ll have to accept my argument about what non-technical experts want at face value.”
Apple promotes this distortion of the reality of their device. When Stephen Fry asked Apple representatives about missing functionality on the iPad, Jonathan Ive responded with this quizzical answer:
I put to designer Ive the matter of all the features that are missing from the iPad. “In many ways, it’s the things that are not there that we are most proud of,” he tells me. “For us, it is all about refining and refining until it seems like there’s nothing between the user and the content they are interacting with.”
The thing is, those things are there – with an addition: restrictions, encoded in legal documents and developer agreements, about how what is there can be used. Apple’s intention may well be “quality.” But that’s the very essence of control: whatever the reason, one party has control, and the other doesn’t. Get it?
The assumption is that these kind of restrictions make devices more usable and more stable to end users. But how does gagging developers from talking about their legal agreement accomplish that goal? How does blocking application and hardware interoperability – the first thing those “casual” end users would take for granted – make the iPad easier to use?
Not Just an Apple Problem: Reinventing and Uninventing the Wheel
Apple I think deserves the brunt of this criticism at the moment, partly because they’ve made their restrictions legally explicit. But don’t think I’m about to let anyone else get off as easily – not with the entire Internet abuzz about how the “future of computing” is coming and it’ll transform everything we know about the universe.
Google’s Android and Chrome operating systems have none of these legal restrictions. (Android’s Market does require that, if you’re sold through the Market, you can’t be sold through another market, but that’s about it – and even that doesn’t stop you from posting an installer file on your site.)
Unfortunately, Android and Chrome also are lacking in actual hardware support. In reinventing the wheel of what operating systems done, Google hasn’t quite gotten to adding all the functionality we expect in operating systems. Sure, an OS built on the browser sounds fantastic – but what if you have a Chrome-based netbook and decide you want to connect a camera with your vacation photos? There’s tremendous confusion in the developer and device vendor communities about what Android and Chrome are for. Is Android a netbook OS, too? Will Google add hardware support? How? It’s even easier to be critical of Google, too: because their operating systems are based on the Linux kernel, support for a vast array of currently-shipping hardware is essentially ready to go, once they can make up their minds to support it. So, bonus points to Google on not being, to use a technical term, “legal bastards,” minus quite a few points for not shipping hardware support.
That also means a missed opportunity for Google, since restrictions like those above could easily drive vendors and developers into their arms. I’m hopeful that their rapidly-evolving platforms will resolve these issues, but I will hold them to the same standard. Ironically, Apple solved some of the technical problems, but imposed new, arbitrary legal obstacles that cripple their own solution.
There’s also the danger that other vendors will copy Apple’s legal restrictions, thinking that these are part of the appeal of the platform – when, for many of us, they’re quite the opposite. That happened most recently when Microsoft announced it was controlling app distribution and disallowing native development on the upcoming Windows Phone platform. Details of that platform are too early to judge, but it’s a discouraging sign.
If I had more time, this would have been shorter
I bring this up for a reason:
The future isn’t inevitable. This is a fixable problem. Apple could – as they did by loosening the NDA on developers – make this better, and they’d deserve credit if they did.
But we have a special obligation as musicians to cry foul. Musicians have taken a leadership role in defining what computing can be, in stretching the boundaries of digital interaction and expression, and in standardizing means of exchanging ideas, connecting equipment, and collaborating. Music was at the center of the creation of copyright law, musical notation was one of the early international standards, and music itself is one of the earliest forms of communication.
The ability to plug things in and connect them is apparently no longer something we can take for granted. But it is something we can protect and improve.