Apple previewed and released their iPhone OS v4 yesterday. Along with the new features comes a new development agreement. The development agreement is under NDA, but that didn't last long.
The big news tweeting up the servers is this clause from the agreement:
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 this basically says is that you can no longer write iPhone OS applications in whatever toolkit you want, rather you must use Obj-C, C, C++ or JavaScript.
It's an interesting limitation, and I've not heard of such a limitation on any other platform in the history of computing. It may well have happened before, perhaps back in the dark ages when IBM ruled the mainframe world with an iron fist. But certainly not at all recently.
Currently, there are several toolkits that let you create iPhone apps using languages other than C. A popular one is the Unity Framework, used in many games. This toolkit uses C# to write the programs. MonoTouch is another C# framework.
But this isn't just about what language you can use. The second clause about linking and compatibility layers is equally important, if not more so.
The compatibility layer clause eliminates toolkits that offer a single API to run across platforms. Such as QT or GTK. With those toolsets you can write a C program that runs the same on Windows, Mac, or Linux.
From the two clauses, it's clear what Apple wants. To quote Steve Balmer, "Developers, Developers, Developers, Developers". The key here, however, is that they don't want Mobile Platform developers. They want iPhone developers. They want developers specializing in and writing specifically for the iPhone.
This clause does a couple of things.
First, is strangles other mobile platforms. No longer can you write common code that will potentially run on all of the major mobile platforms, notably Android, which is Java based, and the upcoming Windows 7, which is Silverlight based.
By requiring developers to use their tools and libraries directly, they can't write code (easily) that will directly compile on other platforms, and therefore will require somewhat significant porting effort if a company wishes to distribute an application on to another mobile device.
That means that a company wishing to create an application for mobile devices will have to dedicate a team specifically for the iPhone. This is just like what happens today in the desktop world. A company has to choose whether their application is going to run on Windows, Linux, or Macintosh.
You can observe the effect this has had over the years, with Windows being the most popular desktop platform, it, by far, has the most desktop applications running on it. Microsoft development tools have no reason to make it easy for developers to port applications written for Windows on to other platforms.
Other providers, however, have reached out to meet that need for cross platform code bases, and many toolkits and development environments have appeared to fill the need.
Java is the dominant leader in cross platform runtimes today. "Write once, run everywhere" so the t-shirt says. This is mostly true. There's some "Write once, debug everywhere" involved, but Java is mostly portable. And this portability along with other aspects of the Java system have pushed Java to the top of the charts, especially in the server and enterprise space.
However, Java has not had the success in the desktop arena that they'd like to have. In fact, Java has it's own mini-platform battle being waged within its own ranks. Without digging deep in to the sordid history of why desktop Java isn't ruling the world, let me boil it down to two words: User Experience.
The User Experience, especially earlier in Java's life, was simply not as good as native applications. The major reason was that Java had to reinvent all of the buttons, windows, sliders, etc. that user applications use so that they can use them on all of their supported platforms. So, out the gate, Java applications looked like, well, Java applications. Not Windows apps, not Mac apps, not even Linux apps (which is saying something, what does a Linux app look like anyway?). No, they look and behave like Java apps.
The basics work, but the nuances aren't there. The speed wasn't there, the perfect integration wasn't there. Functional apps indeed, just not particularly desirable apps.
If you have worked with an iPhone, it may have occurred to you that Apple has very strong views on how the UI looks, and on how it functions. They spend a lot of time on the "look and feel" of the user interface. Spectacular UIs is something that Apple is famous for, and it's part of the overall identity of their products.
So, now imagine if something like Java came along to try and create applications on the iPhone. Basically the folks creating the application would have to "reinvent" all of the widgets that the iPhone provides. As history has shown, since it would be a black box reverse engineering effort, the result would be functional, but imperfect. It wouldn't quite work the same. You could just tell that the app is a little bit off. Making a cross platform application that works like that targeted platforms, is hard work.
How many hours do you think Apple spent tweaking how fast a panel slides, how far the scrolling list bounces, or tuning all of the beeps and boops? And how important do you think all of those subtle tweeks are to the overall effect and feel of the UI? I'm pretty sure it wasn't all decided in a Friday meeting after a wet lunch.
Apple has done some cross platform work. The example is the iPhone Users Guide. What many do not realize is that this iPhone application is really an embedded web application that runs on the internal Safari browser. 100% JavaScript.
The trick is, that all of the animations and such within the app, all of the look and feel that makes it feel like an iPhone app, is coded, by hand, within the app itself. Within JavaScript. A glaring example is the scrolling.
In a normal web app, you let the browser do the scrolling. You make a large list, print it out, and the browser pops up a scroll bar, and away it goes. Within the Users Guide, all of the scrolling is done in JavaScript. They rewrote that fundamental behavior to ensure that it looks and behaves properly. That's a lot of work for basically a bunch of webpages for something as mundane as a Users Guide.
But it demonstrates the drive within Apple on how apps should present themselves on the iPhone.
So, a side affect of forcing developers to use their toolkit, is that they help preserve the User Experience on the device. If Apple has proven anything, while applications empower a device, the experience they provide define the device. We have all seen GUI horrors that take perfectly good computer and make them miserable to use. Apple wants to prevent that from happening with apps on the app store.
Mind, this is a secondary benefit of the policy, a side effect, albeit a desirable one for Apple, but it's not the primary goal.
The primary goal to make iPhone OS the premiere mobile platform. Developers have been flocking to the iPhone already, and the iPad just works them up in to an even frothier frenzy. By restricting the toolset, Apple want the iPhone OS to be like Windows OS. Which means they want it to be the primary platform developers use when they want to target the mobile space.
If a developer does so, then they immediately give the iPhone OS a potential time to market advantage, because, at the moment, it's not trivial to port an iPhone application to another device. Most mobile applications are 90% UI, and with the iPhone, all of that UI will be tied up within Apple specific code. To port to another platform, you can take your 10% of logic and rewrite the entire user experience on another device.
That will take a lot of time and resources. If the iPhone market is Big Enough, many developers simply won't bother to port the application, much like many Windows developers don't port their applications to Linux or Macintosh. Now, if they had chosen a cross platform dev kit instead of, likely, a Microsoft specific dev kit in the first place, they may well port to the other platforms. But they didn't, so they don't.
The new Apple clause helps ensure that modern iPhone OS developers don't have that option of a cross platform dev kit. Well, specifically they don't have the option of using a higher level, generic dev kit that then targets multiple platforms. We have to yet wait and see if someone decided to create something that will lets an iPhone OS source base in Obj-C compile and deploy against another platform. It could happen.
All of these limitation buy Apple time. The mobile space is very hot now, Android and Microsoft are very credible. Apple WILL, in time, "lose" this war, much like Microsoft is "losing" war today with the rise of popularity of Linux and Macintosh desktops.
But as well all know, software development is the building of abstractions upon underlying foundations. This process gives code and development a momentum. A project once started on a specific development stack can be difficult to turn.
Apple has the market presence and momentum right now attracting developers. Developers are expensive to collect, so Apple is taking this opportunity to make the attractiveness of the iPhone platform a faustian bargain and building even more momentum for the platform. Doing this will help ensure, for the time being, that the iPhone OS will get the apps, and get them first.
Posts
No comments:
Post a Comment