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.)

  • RichardL

    Jason Snell's article in MacWorld makes the analogy of Apple as Lucy pulling the football away at the last minute from Adobe's Charlie Brown. That sum it up well. Sure it's Lucy's football, but why would anyone want to play football with her.

  • http://soilsound.com SoilSound

    Well, according to Steve Jobs…

    <blockquote cite="http://bit.ly/acHz6V"&gt;

    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.

    He does have a point. But, how far is all of this going to go?

  • http://www.exodub.com/ Kyran

    I find it strange. It shouldn't matter which language you use. Bad design is bad design everywhere, no matter which tool is used.

    Just look at all the language bindings you see for linux technologies. They don't care which language you use, be it javascript, python, c++, c, c#/mono, whatever, just as long as you make good programs with it.

    Besides: technically speaking the clausule isn't aimed at cross platform tools, but at 'translation' libraries, which could very well be mac specific.

  • bar|none

    Fantastic post Peter!

  • http://www.humanworkshop.com/durk durk

    I am simply amazed how a product like the I-pad can make such an impact…

    I am very happy with it tho. I will never buy an I-pad, because i see no use for it. However it seems like MT for music needed a I-pad.

    many new UI designs and MT screens + win7 = me happy :)

  • http://www.createdigitalmusic.com Peter Kirn

    @SoilSound: He does have a point, indeed, but that quote itself is incredibly ambiguous.

    "intermediate layers between the platform and the developer"

    What qualifies as an immediate layer? I have some guesses, but the devil's in the details.

    That should sound fine to users, who have a vague sense of what this means. (Jason told me separately that, basically, yes, he just doesn't want apps that have UIs that don't work the way he expects as a Mac user – fair enough. I think he may underestimate the ability of developers to deliver those experiences, though, even in Java, but it's the dev's responsibility to prove that to him.)

    But I expect any developer who read that statement would respond with, okay, what the heck do you mean, exactly? Where do you draw the line?

    Ambiguity isn't good enough, either, because if developers aren't sure that these tools are okay, at least some of them may determine it's not worth the risk. I expect the concern for toolkit makers who aren't Adobe is now whether the perception of this clause will be enough to chill the use of their tools.

    So, suffice to say, I'm still very interested to hear whether anyone can make more sense of the rules. And I think that since some of these tools do actually deliver those "native" experiences, they may be unfairly targeted here – that is, Apple's changes may have the reverse impact, and scare some developers away from the platform. (Obviously, there's still a ton of developer interest, so there will be plenty who won't be discouraged. But I do think that each time this happens, people doing developer evangelism for other platforms must crack at least a little bit of a smile. Maybe it also means Apple gets some Flash/Flex developers to learn Objective-C, but you have to figure it could run both ways.)

  • KDR

    Beatmaker is a fine app. However, it definitely does NOT look native.

  • http://www.createdigitalmusic.com Peter Kirn

    @KDR: It'd really be a whole different discussion, but that's my point. Beatmaker using entirely native widgets wouldn't make any sense. Not every app is going to look the same. It's so fundamental, so basic, and yet in the midst of giving Apple well-deserved praise for building great UI toolkits, it seems to get lost. (Indeed, even Apple maintains a separate look and feel for their desktop pro apps, plus all sorts of things – like simulated guitar pedals in Logic – that don't look like their other apps, by necessity.)

    I think what people want is apps that they enjoy using that run smoothly. "Native" in this case means that things like Beatmaker perform well, so that they support whatever the OS is well in terms of, say, audio output. And incidentally, you can still design the app in such a way that its preferences panel looks the way an iPhone user would expect, or hook into Apple APIs where it makes sense. The same would be true for Mac, Windows, Linux, Android, whatever.

  • KDR

    @Peter I don't entirely disagree, but to claim the app "looks native" as you do at the beginning of the article damages your thesis. A person who opens Beatmaker for the first time has to learn an entirely new interface before they can actually do anything with the app.

  • bar|none

    OS X would never have been such a success without its UNIX underpinnings and therefore portability of many key libraries and software. Cross-platform developers embraced it as a personal dev platform for this reason.

    Losing the hearts and minds of developers is a serious risk that should not be underestimated. Jobs has done it before. Such dangerous thinking is again gaining hold in Cupertino. This will be very interesting to watch play out.

  • http://kaysha.com Kaysha

    Great post Pete and I do agree with everything you say. I think people on the internet are fast to jump to ideologic conclusions.

  • ericdano

    This pretty much takes your rant and blows it away.

    http://www.devwhy.com/blog/2010/4/12/its-all-abou

  • http://www.valhalladsp.com Sean Costello

    A few other things to bring up around this topic:

    - JUCE is a free/non-free cross-platform solution, that can target the iPhone and iPad. It is written in C++, and compiled via Xcode for Apple targets. This is probably in the same category as OpenFrameworks and libNUI – i.e. allowed for now, but who knows about the future.

    - How will this affect RjDj? This seems like an application that makes heavy use of a scripting language.

    - For that matter, what about all the Smule apps that are running ChucK?

  • bar|none

    arstechica was a good write up on this as well.

    http://arstechnica.com/apple/news/2010/04/apple-t

  • http://www.createdigitalmusic.com Peter Kirn

    @ericdano: Well, that would have blown away my "rant" only if I had been leaping to the defense of Flash. Sure you didn't confuse my post with one written by the Adobe developer evangelists? (I would have described this as "rambling editorial" more than "rant," but okay.)

    He's got a pretty strong argument against Flash and AIR, etc. The problem is the gray areas that *aren't* Flash, to which that article alludes. There, the only reference is to interpreters in games, but depending on how the clause is read (and, in turn, how Apple decides to implement it), there could be broader implications.

    Ironically, if the framework or "layer" keeps pace with OS updates, using a framework could mean a developer maintains better compatibility as the device is updated. It kind of depends on what you mean by "framework." It also depends on how well the framework itself is maintained.

    And that's really my point here – one broader than this particular Apple agreement. The sequence of events has been roughly this:

    1. Apple makes a change to the developer agreement. It appears to be aimed at Flash, but it's vaguely worded.

    2. Some of the folks defending Apple's change say, simultaneously, this is just about Flash AND all cross-platform frameworks are inherently evil.

    It's somewhere in point 2 that things go pretty far off the rails.

  • http://www.createdigitalmusic.com Peter Kirn

    @bar|none + @Sean:

    I'd wager RjDj is safe. The "language" in Pd – even though you see a patching interface – is still C. And native code is allowed on iPhone. (Something, incidentally, NOT true of Windows Phone.)

    Smule is *definitely* safe because the apparatus for Apple taking action against apps in violation is their own enforcement. That is, they alone choose who lives and who dies on their platform.

    But as for the other examples, I just don't know.

    Ditto this Ars article. Corona claims they're fine. I'm utterly confused.

    "3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)."

    What does "originally" mean?

    What does "intermediary" mean?

    What does "translation" mean?

    What does "compatibility layer" mean?

    I think it's possible to imagine a conservative interpretation of this description where almost anything is allowed.

    But none of this means we need to start running around saying cross-platform frameworks make bad software, when what people mean is that they hate Flash and AIR. If that's what you mean, just say that. The legal document isn't going to say what it really means, but at least we could.

  • salamanderanagram

    can we please just drop it and talk about something, anything that isn't the iPad?

  • Jesper

    It's a testiment to the greatest marketing scheme ever that Apple are still perceived as the "good", while Microsoft are perpetually the "bad" guys.

  • http://www.createdigitalmusic.com Peter Kirn

    @RichardL: Well, on mobile, I think Adobe won’t play ball. On CS, they have to defer to their customers. I can’t imagine what kind of emotions are now running at Adobe – or Google – two long-time Apple partners who Apple seems to have declared partners.

    That said, the main concern for me is that I still don’t know what these rules mean. So having written this above, I think that’s a pretty big thing to remain ambiguous this week.

  • RichardL

    It’s worth noting that one consequence of Apple’s new requirement that iPhone software be written in C, C++, Obj-C or Webkit served JavaScript is that it now makes hand-tuned assembly language such as DSP processing functions using the iPhone 3GS and iPad’s ARM NEON vector processor illegal. This is very likely collateral damage and not Apple’s intent (although who knows?). But it will certainly impact serious audio and music applications if Apple whimsically chooses to enforce it.

  • Warren

    @ RichardL "hand-tuned assembly language such as DSP processing functions using the iPhone 3GS and iPad’s ARM NEON vector processor illegal."

    It's interesting that this potential 'lock off' of assembly comes in the same update that the Accelerate Vector DSP library arrives on iPhone OS. It's an Apple framework that provides a thin unified interface on top of all various hardware vector processors, and provides stuff like FFT code as well.

    I *hope* they don't outlaw ASM, but I think they could, and just point to Accelerate and say "use that". I guess we'll see…

  • kev

    Apple appears to be determined to control iPhone OS in a way that is unlike the Mac OS. However, iPhone OS is not lacking for strong development tools. If Apple chooses to exclude some tools in favor of others in the interests of furthering their agenda/vision they have both reason and right to do so.

    If developers choose to ignore iPhone OS in favor of other platforms then that is there prerogative.

    If you don't agree with Apple's plans then the answer is simple: don't develop for them.

    It's up to Adobe, etc. and the developers using such tools to prove Apple wrong here, by developing best of breed apps that are demanded by users on Android, etc, and demonstrating that the use of the tools in question is integral to the success of these apps.

    If that day comes then Apple will have to face their previous decisions.

    If that day never comes then, Apple's moves here may prove to be the correct moves for their business.

  • http://www.createdigitalmusic.com Peter Kirn

    @kev: That's a really good point, actually. I've heard plenty of groaning and moaning, and not a whole lot of effort to say, how could we make the competition, you know — better. Not as good or nearly as good, but better. What about Apple's platforms *are* worth learning from? What's worth doing differently?

    Even people advocating development for Apple's platforms I think will agree, that sort of competition is healthy. I'm a writer first and a blogger second, but if it were possible to convert the collective anger of developers on Twitter and blogs and such into actual code, I think we'd have an alternative platform by now. ;)

    Anyway, shortly more on some of the details of what's happening with multi-touch platforms; that's an important piece of the puzzle.

  • electronic_face

    This is a great post, Peter. It's just that I wish you could be cloned and have these published on another site focused on the iPad and iPhone.

    iCreateDigitalMusic.com

    Still, I'm glad someone is speaking up about this. But, y'know, it's eating up variety in your content. It's like a game of Duck Duck Goose, except the Duck is the iPad iPhone, and the Goose is a post on the Elektron Octatrack or some other goodie.

  • http://www.createdigitalmusic.com Peter Kirn

    @electronic_face: Don't worry. We'll have more of some other stuff. I know what's in the queue.

    Unless Apple unveils another form factor next week, this will calm down. News always comes in waves.

  • McGee

    What really bothers me is that I can't even think about writing software for Playstation 3 or Wii, and nobody writes giant rants about that.

    Ironically, I can write software for XBox 360 too, but only using Microsoft languages and APIs too, and nobody cares about that either. (Btw, programming for the XBox is as cool as programming Cocoa!)

    Now, down to what this article REALLY means… I really used to like Adobe, but I believe it's about time for Flash to die. We desperately need it to happen in order to HTML5 to flourish. Have you ever seen the main cause of Firefox lockups on Mac computers? Guess what. It's FLASH's fault.

    http://crash-stats.mozilla.com/query/query?produc

    Google doesn't care, Microsoft just wants it to be replace by Silverlight, Sun tried and failed fifteen years ago with the Applets. Who's left? Apple. Yeah, they're fucking up with the people who helped the Mac grow so much in design circles.

    Steve Jobs wants Flash dead? Yeah. So do I.

  • http://www.stepwisesound.com dave ahl

    Hi Peter,

    I think this is a good, fair article that isn't dogmatic or "a rant" as someone posted.

    We really don't understand the full implications of what Apple meant by the changes in the license terms. You are right — clarification from Apple about what is permissible is needed.

    Steve Jobs apparently wrote to a developer directing them to John Gruber's article so his arguments seem to have merit in Jobs' eyes.

    Overall, Apple is a very secretive company that doesn't disclose its plans except to limited employees on a need-to-know basis. They keep their cards very close to their chest. It is hard to "read the mind" of Apple other than to follow their advice if you develop for their platform.

    Apple has a plan — who knows what it is — but presumably for future compatibility reasons they are saying "we are asking you do to x and y." Apple only wants the best, most unified platform possible for the iPhone / iPad. They don't want a ton of apps to break when they update the OS or other system components — I think this is the heart of this change.

  • http://www.stepwisesound.com dave ahl

    FYI — Jon Gruber has posted an update to his original post that clarifies:

    "I do think, though, that Flash CS5’s cross-compiler epitomizes the sort of meta-frameworks Apple is not going to allow."

    "Apple isn’t going to let anyone else build a meta-platform on top of Cocoa Touch"

  • blub

    just my two cents…

    having a set of core functionalities that are provided by the platform and enable/support the development of ideally most applications/their use-cases is very nice – from the user-perspective. you ideally get a set of applications working out of the box for that specific applications including further updates/enhancements to the platform. if you leave aspects like dongling the user's choice of workflow/tools/etc. aside.

    from the developer perspective I can't withstand to say it is just plain retarded. it's 2010 and one thing (of the many) that the development of technology has taught us is that only platform agnostic technology survives in the long term. just step back for a second and think of the literally billions of lines of code/great apps written for specific platforms (hardware/sw) that are basically worth sh** nowadays since those platforms don't exist anymore or moved into a niche. if you look back on the history of computing you see exactly the addition of intermediate layers to add abstraction from the details of a specific platform (e.g. ASM->C->JAVA/CLI/Interpreters // direct I/O -> OS -> App Frameworks -> Cross Platform Frameworks // the whole platform agnostic idea of accessing content on service providers + standardized representation -> Web). Especially for mobile devices you've got a plenthora of different platforms… 3x linux based, windows mobile, iphone os, symbian… so from my viewpoint you have to be downright insane to invest your time as a developer and _dongle_ your application to a specific platform just to see that it is an arbitrary binary blob in 5 years worth a c64/CP-M/you-name-it executable/diskimage.

    And I don't even want to start with the whole aspects of established toolchains&IDEs&compilers… let alone the discussed lib-issue.

    Remember it's 2010 … if you think your platform supports fancy feature XY then you can be sure it will be a commodity in ~1-2 yrs later on other platforms; otherwise it was just some nifty gadget. Same applies for the whole performance criterion… think your app runs only on mobile platform XY with some nice vector-libs, reconsider that the next version generation of mobile hw will have ~twice the processing power… and if you are a good software architect you'll know that in 80% of the cases you can externalize fancy feature X.

    so, my point is… for all developers… please… pretty please… I am tired of seeing dead code ;) Tired of seeing application XY just running on platform Z because you thought Z was cool and worth dongling Z. Tired of seeing time and great ideas/tools being wasted.

    And for the thing about intermediate layers+sub-standard software: ableton? audition? PT? PS?Illustrator? just some of the "marked defining" apps. let alone awesome tools like reaper, renoise, blender… *yawn*

  • blub

    s/marked/market

  • trees

    Every single music app could have been made for windows touchscreens even before the ipod touch. The reason they weren't? Money.

  • kev

    Check out John Siracusa's new article on Ars:

    http://arstechnica.com/staff/fatbits/2010/04/appl

    He basically lays out the gamble that Apple is taking here and the strategy behind that gamble and he does so very succinctly.

    In Apple's view the iPhone OS platform is their product… This means that they are not just floating some ideas out there for bright minds to build upon. This means that they intend to steer the iPhone OS ship for as long as they possibly can. This is a new business model when compared to all previous OS platforms.

    At this point, I support Apple's aggressive tack for the following reasons:

    1) There are still completely relevant desktop Operating Systems which have few developer limitations

    2) iPhone OS is for my phone (!)… And "I don't like people playin on my phone." So I say let the devil drive.

  • Polite

    I like how the reflection has a different app. Virtual DS? :P

  • PooPoo the Korruptah

    iDontcare

  • Pingback: A Brief History of Health Care in America | Sioux Falls Health Insurance

  • http://www.intermorphic.com tim

    Great post. I reckon Apple will NOT clarify further as in keeping it vague it gives them more wriggle room (their perogative) to vet or reject apps as they see fit. As you note, some apps seem to pass even if they do not comply 100% with the legals (knowingly or not!). One can only assume that Apple are aware of such things and will turn a blind eye if or for as long as it suits them. They will likely be banking on an initial sting of comments and then the noise dying down and everyone getting on with it. Maybe they will decide to clarify, but it is hard to see what could force the need for them to do that.

  • Pete

    How ironic that iPhone/iPad are based on vast amounts of open-source, cross-platform code (WebKit, gcc and what have you)! I hope that MeeGo really succeeds in the long term as a platform.

  • http://music.cornwarning.com chaircrusher

    Three things bother me about this announcement.

    1) The assertion that cross-platform development is inherently substandard.

    2) Apple isn't saying what they actually mean. There's a Soviet-style indirection to it.

    3) What they DO say is vague to the point of meaninglessness.

    To question 1: Ableton Live? Cubase? Before the Apple Purchase, Logic? Every VST/Au plugin? This assertion is a priori bogus.

    I've spent 20 years at various companies where 'cross platform' was an essential development strategy, and not just for 'bean-counting' reasons. Cross-platform software is inherently more robust, because it separates core function from UI, a design separation that's a Good Idea even for single platform development. Different OS/Compilers flush out different bugs. If you make the effort to run everywhere, your program is improved.

    As for 2, Apple obvious doesn't mean what their statement says, because 99% of programs will have some "intermediary translation or compatibility layer." Even if it's just 200 lines of code written in-house. If they want to Torpedo Adobe, fair enough; there are good technical grounds for prohibiting Flash. But if Adobe can translate Flash into Objective C, why is the resulting code anathema?

    As for 3, this whole thing is pure Humpty Dumpty bullshit. What the statement means is whatever Apple chooses it to mean, on a case by case basis. So if they said what they really meant, it should read "we reserve the right to refuse any app, based on whatever criterion we choose at any given moment."

    This is just more of Apple being capricious, arbitrary, and dictatorial. So what else is new?

  • Pingback: Is it okay to use a light string gauge with extra-light string gauge on my guitar? | Patio String Lighting

  • dent

    http://stevecheney.posterous.com/the-genius-in-ap

    an interesting perspective.