Regarding Apple’s recent iPhone/iPad SDK TOS update sneak-peek, the signal-to-noise ratio of logical reasoning amidst the sea of self-inflated opinions and FUD has become unbearable.
So what am I going to do? Compound that mess with my own opinions, of course! And they are just that, opinions. Take them as you will. I only ask that if you choose to comment/discuss, do so in a calm and rational way. I have zero tolerance for fanboi fantaticism — that’s what twitter and your own blogs are for.
What about…?
I’m going to spout pure opinions (but at least I have some rational arguments) on a number of things in this post:
- How Apple’s new TOS might affect the world of JavaScript/Web-Stack enabled cross-mobile development
- How the new TOS is going to affect the world of Flash-to-iPhone cross-mobile development
- What this (and other things) may mean for the future of Flash
- Why the stupid comments on both sides are bad for the topic and the dev community
JavaScript for native mobile apps
I consider myself a hard core a developer, specifically a JavaScript developer. If something can’t be done with JavaScript (or web-stack technology) I’m bored and disinterested in it. In fact, I’m actually pretty uninterested in any use of JavaScript as a fluffy, trivial, toy language for unimportant things like bouncing boxes and distracting animations. I get excited every morning by trying to take JavaScript and push it to its limits as a real programming language, and to use it to solve some really challenging development and architecture tasks.
So, it should come as no surprise that I am 10,000% stubbornly insistent that I won’t ever get into building a mobile (native) application if I can’t use web technology to do it. This means in particular that I refuse with a passion to learn Objective-C just so I can build apps that appease the all powerful iPhone gods. It’s not laziness (I know half a dozen or more different languages)… it’s a philosophical pre-disposition against such vendor proprietary lock-in.
Turns out a lot of developers felt this way. First we saw projects like PhoneGap, Titanium, and several others crop up, which all (in their various ways) address the desire to build (native) mobile applications without having to tie yourself to each phone’s proprietary vendor lock-in stacks. Then we had Palm release WebOS which uses the open web stack as its core technology. Then Adobe jumped in and said “hey, cross-compile your flash applications to iPhone Objective-C”.
The fact is, the developer community is very broad and diverse. Apple (or any other vendor) may like to dream of the day when all the good developers so love their stack that they dismiss other alternatives as inferior. But it’s complete nonsense to think they already have that mind share in today’s world. There’s a lot of us out there, and not all of us feel like bowing to Objective-C and Apple just to get a freaking calculator app written for a smart phone. Moreover, we’re a lazy bunch, and we don’t want to have to write that damn application 14 different times, once for every vendor variation of every phone.
Wake Up!
Stubbornly choosing as a phone vendor to lock in your phone to only working with one application stack is a game you play for market share and team maintainability reasons and other political B.S. HELLO!??! The rest of us don’t like those games. In fact, we rarely tolerate them at all, unless our boss forces us to. That’s why we push for and support projects like those mentioned above which give us more (and sometimes qualitatively better) choices.
So, it’s awesome if a developer well skilled in the web stack (like me) can extend their skills to mobile app development. It’s doubly awesome if we can do so in a cross-mobile way so that code doesn’t have to be entirely rewritten for each device. And both these projects deliver wonderfully on that promise. Write an application in JavaScript, use HTML and CSS for the UI, and deploy it to multiple mobile devices. And by the way, there’s a good chance a lot of that code will ALSO work targetted at WebOS enabled phones. This sounds like a huge win for the open web world.
It was a little rough at first, with both PhoneGap and Titanium stumbling a little in the early goings, not to any lack of their own features but to the treacherous world of AppStore approval. The early applications ran afoul of Apple’s TOS wording regarding not using emulation layers or API’s other than the iPhone’s. But both Titanium and PhoneGap worked things out with Apple and since then hundreds of apps built on both technologies have been approved by the iPhone gate keepers.
I have several mobile device application projects that I have been planning to ramp up in the near term. And of course, I fully intended to leverage one or both of those projects to enable web stack programming for my native applications.
The muddy waters
A few days ago, Apple announced the much anticipated iPhoneOS 4.0 SDK update. Naturally, this comes with a new TOS. What came as a surprise to most of us was this little snippet:
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).
This is similar to the previous wording, but it differs in some important and broad-reaching ways. First of all, Apple is now specifically limiting the “original” language an application is developed in to Objective-C, C, C++, or “JavaScript as executed by the iPhone OS WebKit engine”. This means regardless of the fact that a compiler may result in a compatible iPhoneOS binary executable, Apple is going to reject it if you wrote your code in some way they don’t like.
This is a dangerous precedent. What if in the next TOS update, they say “only code written in one of Apple’s approved code editors”? So wait, now because Apple controls final distribution, this gives them the right to control the entire toolchain? What if Microsoft were to say “only JScript that is originally authored by FrontPage or SharePoint is allowed to run in IE”? We’d all think that was the most ludicrous thing we’d ever heard.
So who’s affected by this update? It would seem Titanium may be at risk, since they take your JavaScript (your “original code”) and convert it to Objective-C before compiling it down to the iPhone binary. And Titanium’s not the only one. There are several others in relatively the same predicament. So, because YOU the developer didn’t want to learn Objective-C, and you’re prohibited from using a language translator in the middle, your app gets rejected. End of story. Uhh… that sucks. Big time.
But… UIWebView?
I’ve heard numerous people claim that PhoneGap is unaffected by this new TOS update because they essentially DO end up sending your JavaScript straight to the iPhone to be used by the UIWebView (ie, iPhone Webkit). This sounds all rosy for the PhoneGap folks. However, I’ve yet to see a definitive statement/explanation that proves that Apple will see things this way, or that there’s any evidence to suggest they will always feel this way. Apple is known for changing the game’s rules when it benefits them, so what’s safe for PhoneGap now may not be safe for it with OS 4.1 or 5.0.
Moreover, I think there’s other wording in that clause (and in reading between the lines) which is dangerous for PhoneGap. Note that PhoneGap exposes a JavaScript API to your applications that allows your JavaScript code (running in WebKit) to interact with the native phone functions. Note the wording clearly states that only C/C++/ObjC may “directly” link to the phone’s APIs, not your JavaScript. It’s a razor sharp edge we’re dancing on here. Is JavaScript talking to the phone’s API through the PhoneGap API layer “direct” linking or not? This and a dozen other intricate technical questions remain regarding whether or not JavaScript is going to be allowed as a native application platform in the iWorld or not.
I just don’t trust that without much further clarification from Cupertino, we’re going to definitively know whether Apple intends to allow PhoneGap applications. And even if they do, it’s definitely bad that other options like Titanium may get cut off at the knees. It’s like the game has been reset back to how it was a year ago, when everything was up in the air. It’s a terribly uninviting environment for devs (like me) to jump in and spend time coding against. We’re far from knowing an answer to what rules Apple is really re-writing for this game.
Wait
Let’s take a step back for a moment. Isn’t what we’re seeing in Apple’s play on their gestapo control of AppStore apps (and indeed the ENTIRE DEV PROCESS) just the sort of fickle, whimsical, proprietary lock-in behavior that the open web has been fighting against for years (ahem, Adobe/Flash wars)? Or wait, am I wrong to mix these two worlds together — the mobile app space and the open web space? Is it crazy to assert that the success of both depends on each other?
And isn’t it Apple who’s been one of the biggest proponents of the open web stack? Don’t we owe <canvas> and a whole host of other goodness (including WebKit) to them!? So why then are they seeming to act in such a hostile manner to the community that now wants to use those technologies to push their (and everyone else’s) mobile platforms to the next level?
Far too many questions
These questions and dozens more like them are far too complicated and broad reaching for anyone to definitively answer. If you were to try to “write the book” on this topic, by the time you got done exhaustively explaining and re-explaining, most of what you said would be out of date.
So, I will only try to assert that I have a few (totally unoriginal to me) opinions on why Apple pushes open web but simultaneously resists its usage for native mobile apps.
- The push to bring open web stack technology to the native mobile app space is as much about the reasons listed above (coding once/targetting many platforms, developer skill diversity, etc) as it is also about blurring the lines between what is a web app and what is a device (mobile or otherwise) app. If the open web stack technology can become the ubiquitous and universal “language” that all devices and forms of access speak, developers stop having to chose and play tough games of tradeoffs and start getting to focus on some truly amazing innovations.
Basically, this comes down to us inherently all wanting the utopia where all applications are homogenous in their platform technology and delivery — the truly cloud and grid enabled world where it doesn’t matter what mobile hardware you prefer, you get the same access to amazing applications that everyone else gets. It’s a world where all applications become native, not to a specific device, but to the fabric — the web — that connects all of us together.
But why is this a challenge to Apple if we were to advance toward this utopia on the backs of applications built with open web stack technology and approved through the AppStore? Because a homogenous application utopia tears down all proprietary single-vendor walls and virtually eliminates the economic ecosystem that Apple has worked so hard to build. If an application exists in a world “free” (as in freedom, not as in beer) from the bindings of old school device lock-in, it’s going to be as disruptive to corporate profiteering as Neo was to thought control when he “unplugged” from the Matrix.
Universal applications?
Think about it. If an application were identically and universally available through open web means (cloud/grid enabled) and could run on virtually any device (laptop, iPhone, blackberry, iPad, etc), how could Apple claim exclusive commerce rights over such an application? They couldn’t. At best, they’d have to offer the application in a competitive market where they had to keep pace with supply-and-demand (and other capitalist constructs). They’d have to compete with other AppStore clones on price, quality, service, dependability, and a whole host of other traditional consumer concerns.
But more likely, the very concept of paying for an application itself would go away. It would be replaced with paying for privileges in an application (such as no advertising), or paying for consumption of services, or paying for support, etc. It would create a whole spectrum of commerce around mobile apps which only exists in fairytale dreams at the moment. And there would be a lot of other players at the table besides Apple. Bye, bye exclusivity.
As it is now, Apple has virtually none of that to worry about. They don’t have to care that some other vendor could sell the same application for 20 cents cheaper, thus cutting into Apple’s deep 30% profits, because since they’ve created the exclusive walled-garden, noone else can compete with them. They don’t have to be the best to get business. They only have to be just a hair better than despicably awful and not drive existing locked-in customers away. This is a beautiful picture for Apple and their stock holders. Creating an exclusive controlled economy is an absolute corporate dream. And they’ve done so with flying colors!
- Somewhat related, certainly part of Apple’s war on diverse app development processes (ie, other “original” languages) comes from their (understandable) desire to lock out other upcoming mobile platforms (namely, Android, and to a lesser extent WebOS) to prevent competition and maintain profit margins. I think it’s quite obvious that reading between the lines of Section 3.3.1, what you see is that Apple wants to make sure that any application you write for the iPhone was “originally” written and intended for the iPhone.
My “proof”? This phrase: “…as executed by the iPhone OS WebKit engine”. Why does Apple need to specify that JavaScript must be executed by the iPhone OS WebKit engine? It’s not as if there are other WebKit versions (not native to the iPhoneOS) running on the iPhone. Nor have there been, to my knowledge, any serious attempts to bring any other JavaScript interpretation environment to the phone (V8… wouldn’t that be hilarious!?) Their WebKit is the only game in town. Why not just say “JavaScript” as one of the allowed languages and be done with it?
No, I think what’s really going on here is that they’re setting themselves up to say in rejections, “you didn’t write this JavaScript intending for it to run on our WebKit, but rather intending for it to run on any WebKit or other interpreter.” How will they prove such a specious claim? By finding your application in the Android AppStore, that’s how. And I’m not the only one to make this radical prediction.
One AppStore to rule them all
Apple only stands to gain from a world where the best (and the most) applications are only available from their AppStore. If a killer twitter application is cross-compiled to both Android and iPhone, that’s great news for developers and especially consumers but it’s terrible news for Apple because it’s one less reason (though there are still plenty) why people should choose the iPhone platform.
Make no mistake about this: Apple got into the mobile device business not primarily to dominate mobile hardware, but to control and dominate mobile applications. Ever heard the phrase “Content is King”? Yeah, in the new mobile world, “Applications are King”. And Apple knows it. I can’t confirm with hard numerical statistics (those are boring anyway), but I’m sure Apple analyzes and projects that there’s far more money to be made with mobile applications than with mobile devices. The mobile device game only has to be just good enough to make the applications feasible and pleasing.
Apple is certainly good at the hardware side of things, no doubt. But I think deep down inside, they know the profitability comes from dominating the sale of applications.
5 years ago, the mobile device (and application) space was still a dream and a projection. Back then, Apple could have used help from other companies to “prove” the space. Had the Android, Blackberry, and WebOS devices all simultaneously launched at the same time as the iPhone, and all grown up together at the same time, they would have all had a healthy side effect on each other, in that they would have helped to raise the bubble of what the mobile device/app space could be (even quicker than it did).
But now, Apple has all the momentum they need to ride the wave and continue to dominate both the device and app mobile space. They don’t need or benefit from Android, Blackberry, or WebOS at all. In fact, those are all now heated competition. And Apple will do anything in its power to win that game. Including making it impossible or infeasible to write applications that help other devices’ AppStore communities thrive.
Original Intent
I think in large part, that is what the “original” wording in Section 3.3.1 is all about. Apple doesn’t like that PhoneGap, Titanium, and a dozen other similar projects are making it easier and easier to create applications that multiple devices (and AppStores) can benefit from. They’d rather you spend your effort learning their lock-in Objective-C technology and write iPhone/iPad only apps.
- Lastly, I think Apple is concerned that JavaScript’s powerful dynamic/meta nature could be leveraged to create a disruptively compelling application sub-space, similar to concerns that have been floated about Apple’s denial of the “Flash platform” on the device.
Consider this: take the rich and powerful capabilities of JavaScript driven systems like RaphaelJS and Gordon, wrap some intelligent game engine framework around them. Now you’ve got an exciting new platform to develop and distribute game-within-a-game type experiences, where the user can receive over-the-air web delivered JavaScript code (web application style) that seamlessly interoperates with the native application’s JavaScript code . You have one shell application with hundreds of different mini-applications inside it all loaded and running dynamically. It would become technically near impossible for them to distinguish between the core “native application” (that they reviewed and approved) and the “web application” that loaded dynamically. Apple loses control, and thus they lose economic attachment. This is bad for business.
Sure, Apple would try to find some way to update/enforce the TOS to prevent that. But I think we all know the slippery slope this gets us on. With Flash, Apple never allowed that door to open. But with WebKit already on the phone, the door is clearly already unlocked and without careful watching on Apple’s part, someone may swing it wide open.
On the next page, I will begin to address how Apple’s moves impact Flash.