Pictured: Looks native, but this app is built with a cross-platform library. And really, for music making – or great, immersive development, in general – does it matter?
The iPad has inflamed plenty of passions online. On this site, I’ve gotten a little flak from iPad lovers and haters alike. It goes something like this: “wait a minute, you’ve got all these criticisms of the iPad’s restrictiveness, but then you’ve got all these amazing music apps.” Or, on the other side: “why do you keep covering all these iPad music apps?”
In a word, yes. They’re not the same issue. I’ve talked to plenty of developers. The business draw on iPad is a big deal for independent, creative developers, so to the extent that Apple strategy makes the store a good place to sell apps, there’s some overlap. But the iPad has also been attracting plenty of music developers because of the quality of the APIs – developers who often aren’t pleased with the restrictions. Does the person who writes the audio drivers and APIs have anything to do with the lawyer who writes the developer agreement? Of course not.
The problem is, just as iPad/iPhone critics sometimes conflate issues in their rush to criticize the platform, some of the defense from the Mac community is getting a bit carried away, too. We’ve seen this with design issues, not just ideological or business issues: you go from “touch can be an expressive way to interact with a computer” to “throw out your QWERTY keyboards! They’re dead!” or “you’ll never read a magazine again” or “multitasking was a terrible idea in the first place.”
In this case, Apple made a fairly specific change to a developer document. That resulted in some criticism that was over the top (namely, people claimed it’d stop specific developer tools before they had verified whether that was actually the case). But it also resulted in some Apple apologism that was downright surreal:
All cross-platform development is bad? Wait – what?
And for that matter, is the mark of great software design now exclusively using Apple’s developer toolkits? Wouldn’t we sort of hope that, beyond those slick Apple UI widgets, someone somewhere might be developing the UI of the future? For that matter, do people not realize that a lot of what makes Apple’s quality exceptional is stuff you can’t see – things like multitouch firmware, high-quality audio drivers, and other fit-and-finish on the plumbing?
So, I invite you, dear reader, travel with me. I think we may actually have something on which iPad critics and fans alike can agree. It’s relevant to music, because music apps (along with games, incidentally) are the ones that are most intimate with this issue. And I suspect a lot of you use cross-platform tools to develop code for your day job.
The Catalyst: Apple’s Legal Change
Apple surprised many in the tech world last week by making a change – mandatory to all developers – that requires that applications for iPhone “must be originally written in Objective-C, C, C++ or JavaScript [running in the WebKit browser engine].” More specifically-worded, “Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited.” Because of the timing, and because of the further clarification, conventional wisdom suggests this is aimed at Adobe CS5’s tool for making native iPhone apps from Flash code. I don’t think it should be any surprise that that would get developers upset, not only those who use Flash, but even some loyal developers who don’t like being told what to do by Apple. (And I know at least some fairly big fans of the iPad weren’t fans of this change.)
Had it not coincided with Adobe working on CS5, I don’t know that this would have been big news; Apple already restricts the languages used to develop on their device. But I think what set people off may have been that very problem: people don’t know what it means, and that (rightfully) makes them nervous. While online debates have devolved into idealogical extremes “All control is good! / Apple just killed Adobe!”, what the press has missed is a sense among developers that they can’t predict or entirely interpret Apple’s developer agreements. I suspect Apple did aim this at Adobe, but that means even non-Flash-using, native-developing software makers now have to face some serious ambiguity in a legal document they have to sign.
That said, if Apple would further clarify the statement, that could be resolved.
I didn’t personally get worked up over this, because it’s consistent with what I and many, many others have been saying about the platform all along. Apple’s control over distribution and desire to control the development process means this is the sort of thing they can do. There are reasons to endure it: they make a really well-engineered platform, and there’s a terrific market and installed base that has a voracious appetite for creative software. There are also clear reasons to look elsewhere if you’re not comfortable with the restrictions. This is the very definition of trade-offs and choices.
I’m going to avoid the debate not because I don’t think it’s important – I think it is – but because I think enough words have been written in service to one side or the other. What seems to be missing, however, is a shared understanding of what cross-platform development actually is.
The Trend: “All Cross-Platform Development is Bad”
Whatever Apple’s thinking, it’s caused some people apologizing for Apple to say really weird things. John Gruber at Daring Fireball, for instance, begins by making an entirely reasonable argument for Apple’s strategy and where they live in the market. I don’t agree with all of it, but it is a well-reasoned, well-argued point. Then, almost as a footnote, John makes this claim:
Cross-platform software toolkits have never — ever — produced top-notch native apps for Apple platforms. Not for the classic Mac OS, not for Mac OS X, and not for iPhone OS. Such apps generally have been downright crummy.
[emphasis mine]
Why Apple Changed Section 3.3.1
[Daring Fireball]
That argument has gotten picked up all over the Web by other Mac fans. And that, to me, is dangerous – because, as worded, this statement appears to be to be entirely indefensible.
John doesn’t say “cross-platform compatibility layers” or “meta-platforms” like Flash and AIR. He says “cross-platform software toolkits,” and I think he means it. (Now, John, if I’m wrong, please correct me – but please stop making statements like this, because “cross-platform” is what many of your readers are coming away with.)
This would likely come as news to those who use music software. Cross-platform software frameworks are at the heart of most of the tools we use. One small but lovely example, specific to the iPhone/iPad and absolutely kosher under Apple’s new developer rules, is LibNUI, a C++ framework for building UIs. (In fact, after playing with this a bit, I may pick it up for a project on a completely different platform.) Popular iPhone apps like bleep!BOX and BeatMaker use it, but it also keeps tools like MOTU’s MachFive plug-in compatible with multiple platforms, without sacrificing native features like drag-and-drop.
If you use Ableton Live, Max/MSP, Cubase, or countless other apps, you’re using software created in cross-platform frameworks – some in-house, but using the same basic technology. Indeed, few of these applications would work the way you expected if they used exclusively “native” features and design patterns, like UI widgets that don’t fit musical applications or don’t work in live music performance.
In fact, John’s statement is so broad and over the top, I think it might even apply to tools like CodeWarrior, the developer tool and, yes, cross-platform framework that was the dominant toolset for developers in the pre-X “Classic” Mac OS era.
This matters to users, too. Sure, you may never write a line of code, but you rely on the community of people who do. Part of what gives you the freedom and flexibility to run great software on a variety of platforms, rather than being locked into just one platform, is the fact that these tools make the differences between those platforms fall into the background. Any developer who thinks this happens automatically without effort or testing is likely to give you a terrible app, but odds are, they’ll give you a terrible app regardless of what tools they’re using.
Develop Once, Run Anywhere?
Macworld editor Jason Snell also picks up the old argument about cross-platform development being inferior. (The title, I think, may be the most insightful part of this piece, but I’m not an Apple employee or investor, so I’ll let them worry about that.)
Apple against the world [Macworld]
…the develop-once-run-anywhere philosophy is something that makes more sense to bean counters and development-environment vendors than it does to platform owners and discriminating users. In the ’90s we were told that Java apps would be the future of software, because you could write them once and deploy them anywhere. As someone who used to use a Java-based Mac app on an almost daily basis, let me tell you: it was a disaster. Java apps didn’t behave like Mac apps. They were ugly and awful and weird, but hey, at least they ran on the Mac.
Ah, yes – this argument again. (It’s one of those things from the 90s that just never gets old, like Ace of Base or plaid t-shirts and pleated khakis.)
Okay, I kid, but Jason – I feel you. Actually, I feel you even as a fan of Java; the language and platform have some real power, but because of some questionable tooling atop them and questionable development practices with them, it produced some really horrible products. Such is development. (Actually, arguably, the folks in the 90s were right – it just turns out to be the browser itself, not Java applets, which have nothing to do with modern Java development anyway.)
I think Jason is mostly hung up on things like UI widgets; he refers specifically to the lack of a menu bar, odd preferences dialogs, and other usability issues in the AIR application TweetDeck. (Part of the reason we don’t nitpick these things in music, of course, is that we’re using extraordinarily complex interfaces for doing other things.)
Jason misses some critical points, however – in this case by omission; he doesn’t make the same, sweeping statement Gruber does. (Jason told me via Twitter that he wasn’t set to write another 2000 words, so Jason, I’ll try to do that for you.)
In regards to Java, the reason Java apps don’t feel like native Mac apps is at least in part because of Apple. It is actually possible to do all the things Jason is describing; Apple themselves touted the feature. You can read the documentation, and the fact that it was deprecated way back in 2005, on Apple’s legacy Mac developer documentation site. I can only speculate about the decision there, but my guess would be that it was practical more than strategic. There’s a new open source project to replace this functionality, Apple themselves recently made interfacing with native code easier for Java developers, and whatever language preferences Apple has on the iPhone, they continue to support projects like Ruby on the desktop Mac.
Generally, I think you’ll see more native feel in apps for Mac, Windows, and Linux from Java, Ruby, Python, and other languages. It’s an area of active development, and it’s improving. It may also benefit from these communities breaking off from big corporate parents, because the developers themselves seem to understand the perspective of the users better than, erm, companies like Sun and Oracle. Bottom line: don’t be surprised if some day soon you again run a Java app (or another language, not necessarily Java) and don’t notice. Those “discriminating users” on the Mac do notice when it’s wrong, and very often want to get it right.
Art, Tools, and Cross-Platform Frameworks That Don’t Suck (Or Break Apple Rules, Maybe)
But it’s not just about the standard Mac widgets. Jason, definitely check out Processing and the fantastic art made with it? It’s Java, though that doesn’t matter and isn’t immediately apparent, which is good.
If you design became only about widgets and preference bars, even nice Mac ones, we’d have a generic, bland, look-alike future for software. I know that escaping bland, cookie-cutter software is what drove a lot of people to the Mac in the first place, so it’s worth reiterating.
Tools like Java aside, though, somehow lost in this debate is the fact that cross-platform development is wildly popular and largely transparent – just in the language C/C++. From games to serious software, a whole lot of software is written in cross-platform C++, with the bulk of the code compiling on different operating systems and even hardware architectures. Developers typically make use of various frameworks to ease this compatibility.
Furthermore, while I still think there are reasons to be wary of Apple’s policies and this decision in particular, it would likely be inaccurate to claim that the recent change blocks these tools. In fact, several specific examples all use native code to link against the official Apple APIs, meaning they should be safe. These applications are exceptions that prove the rule: they’re great cross-platform tools that can produce great apps, they’re allowed on the iPhone/iPad OS as near as I can tell, and in some cases they’ll also be cranking out great apps for non-Apple platforms. Adobe’s big sin may have been allowing development from Windows, meaning you don’t get all those designers buying new MacBooks. Here are some examples of tools likely to be safe:
iPhone Wax uses Lua, but it still uses Xcode templates.
Corona, an awesome development tool for OpenGL-accelerated apps, has a specific response. Oh, and it’s coming to Android, too.
Unity is producing fantastic games and should likewise be safe under the new rules.
OpenFrameworks, a brilliant framework for artists that allows them to produce creative, interactive applications with music, visuals, and media for Windows, Mac, Linux, and platforms like iPhone/iPad is written entirely in C++ and appears to be okay. (Again, you use Xcode and Objective-C to link against official Apple APIs.)
Not incidentally, each of these tools (and LibNUI, above) could make some amazing music apps, some likely developed by readers of this site.
Let’s be clear: critics of Apple’s change likely overestimated how many frameworks would be impacted. That meant people were making an argument that may have been divorced from the facts. That said:
Just because they got the argument wrong doesn’t mean criticism (or defense) isn’t warranted. Apple did make a major change to the developer agreement, and they made it – apparently – as a reactionary response to a particular technology, in a way that could threaten other, unrelated technologies. The debate may have gotten overheated and inaccurate, but it’s understandable that the underlying cause is cause for concern. In fact, I think there’s no reason that Mac-centric media outlets couldn’t point that out. And developers really should consider leaving a platform if they don’t like it. (If it’s Apple’s right to make the rules, it’s certainly likewise the developer’s right to vote with his or her feet.) I think there’s an argument to be made in defense of Apple – I could certainly make that argument if someone dropped me on a debate team and put me on Apple’s side, even if I happen to disagree.
The jury is still out on just what apps are impacted – which should be further cause for concern. In fact, I’m still not entirely sure what the status of the apps above may be. On the blog /dev/why??:
In my opinion this is not purely aimed at Flash, but it is certainly precipitated by Flash CS5. I can’t imagine Apple is happy about environments like MonoTouch, Unity3D, PhoneGap, Appcelerator, or Corona, but I am doubtful they would have changed the license in this way just to stop developers using those environments …
He apparently thinks, however (though even the developers of Corona do not), that these frameworks could become verboten. Furthermore, he notes the case of “interpreted code” and why it’s important (it happens to be useful in music apps, too), though my understanding was that that was already a violation of the agreement. (Perhaps it’s clarified here.)
The more interesting thing from my standpoint is that this makes it a license violation to include a language interpreter inside a game. If you aren’t a game developer you might not be familiar with how large games are structured, but most games consist of a game engine, which is high performance code for doing things like rendering graphics, and an interpreter which runs the game logic (determining how sprites move, determining when to pop up in game text boxes, etc). This is how practically every commercial RPG works, as well as many (most?) other types of games. This affects major app store publishers, like EA, Gameloft, Tapulous, and ngmoco:). Looking at the top ten lists on the app store right now I see several titles that I know have embedded Lua interpreters. In this case I think these apps are genuine collateral damage, though I honestly doubt Apple would attempt to enforce the clause against them. In fact, using an interpreted language for game logic is already technically in violation of section 3.3.2 in the current agreement, though many developers may not realize it because under the original agreement it was okay, and the change that made it verboten was very subtle (changing an “and” to an “or”). I am actually not sure exactly when that changed, and only noticed it myself while I was researching this blog post.
See comments – ultimately, the language question is the big one. It could have a negative impact on developer flexibility, and specifically could impact DSP code. As Richard notes in comments, it’s all a matter of what Apple chooses to enforce. It’s possible that the letter of the law makes all of these things illegal, but in practice, Apple just wants to block Adobe’s tools.
But let’s also be clear:
Major voices in the Mac community are advocating against cross-platform software, even without a complete understanding of what that means. And you can actually defend Apple’s rule change Others (like Jason Snell at Macworld) I think just don’t get the opportunity to be clear. But let’s be clear. Let’s makes sure that idealogical discussions on both sides of this debate don’t obscure the facts.
Digging into Apple’s own, platform-proprietary tools can be a great thing. My friend vade, a sometimes-contributor on Create Digital Motion, has done great work with Quartz Composer, for instance, as an artist, and knows Core Image backwards and forwards because it allows him to express himself.
But that’s just one avenue. I know other developers who have found that working across multiple platforms ultimately makes their software better. Jason Snell unfairly, I think, characterizes this as “lowest-common denominator” development. If that’s what you’re doing, well, yeah, that would kind of suck. But I’d call this “highest-common denominator” development: the more you need to make code work on multiple platforms, the more, very often, you have to optimize all of the platforms, the more you discover opportunities to improve your code and make it a more general solution to a problem.
The truth is, you can use the cross-platform tools above to make fantastic iPhone/iPad apps, apps that feel entirely “native,” but apps that will also – by Jason’s description:
…[create] a world where App X for iPhone and App X for Android are indistinguishable from one another.
When it comes to games, to music apps, to creative applications with alternative interfaces, to immersive applications, to rich media interfaces – developers are creating that world, period. Apple can’t stop developers from doing that. Given that they tout availability of apps for their platform that were built with that model, I’m not even convinced Apple always has a problem with that development model.
The cross-platform world is here already, and it’s growing. And, honestly, I think it’ll be a good thing.
For further reading…
This post is really rhetorical, but it hilariously takes the legal clause to its logical (if not practical or likely) conclusion:
Apple bans modular programming
It’s amusing reading, but as author Jeff Erickson (“Ernie Pan”) responds to comments, the real bottom line comes out: “But it doesn’t matter what Apple means. The license is a legal document; the only thing that matters is what it actually says.” Of course, that leads to still more unpleasant revelations: it doesn’t matter what the document says or Apple means, but what Apple actually does. And Apple can change what it does at any time.
Tao Effect notes, as I do, that cross-platform toolkits can be made to look like native apps, or even that it may not matter what they look like (because as a game, or in my example of a music app, they all look different by necessity). It also responds to what I think we could now call the Jobs Doctrine:
“We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.”
My issue: I”m not sure what Jobs means by the terms “intermediate” or “layers.” In fact, I’m not entirely certain what he means by “sub-standard.”
The blog notes that – while I suggest that maybe some of them are safe – things like MonoTouch, popular apps that feature Lua scripting in their development, and the widely-used Unity 3D game framework may well not be allowed in the store, which could mean more unpredictable rejections.
Ah, to be using a game console, where almost everything is rejected and you only have to worry about the few apps that make the cut…
Whatever the implications for the iPhone platform, though, these stories underly the point I’m really trying to make here – whatever Jobs may seem to be saying or Apple advocates are arguing, the notion that cross-platform development creates bad apps is one that is seriously open to debate.
In the meantime, we have several groups who don’t speak the same language or technical understanding:
1. Apple lawyers.
2. Apple end users / customers / advocates.
3. Developers.
And then we have Steve Jobs making sweeping, provocative generalizations that are themselves enigmatic, because he’s, well … Steve Jobs. (So make that category #4.)