Sunday 11 April 2010

In defense of the iPhone 4.0 SDK section 3.3.1

There have been many blog posts about the new iPhone 4.0 SDK which do not like section 3.3.1 of the developer license agreement, which says:

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

Apple's introduced restrictions on original programming language, which has been considered an attack against Adobe Flash. However, there is more to it. The market for smartphones has been very diverse for a long time. Microsoft has attempted to standardize smartphones on Windows Mobile, which failed because of its power consumption and because it was always a bit late to the market. Apple made a huge hit with the iPhone, because they combined new technologies that made it possible to give a great smartphone experience, earlier than what would otherwise have been possible. They were rewarded for innovation.

Now, that everybody is catching up on the basic technology, like touchscreens and sensors, other software vendors are seeking ways to standardize the ways that software is written for many platforms. There is a huge saving if software vendors can create one application that can be deployed on iPhone, Android, Maemo, Bada and others, and on many different form factors. What would the result be for Apple? They would just be one of many, and they would probably not have any significant advantage over the competition. This means that their margins would drop, in a market where prices are already going down, and they would earn a lot less money. Apple does not want that, of course.

For the consumer, that would mean a lot of apps, which do not exploit each platform well - the feature lists would focus on the lowest common denominator for the target platforms, and few platform-specific features would be used for marketing apps. It would be hard for phone platform developers to add new capabilities that the developers would love to use.

Apple's strategy is to separate itself from the apps on other platforms, giving the user a unique and different experience, which they believe will be better than usual. If you have three features, and Apple does the first two perfectly but not the third, and the competitors do all three in a mediocre way, many consumers will pick the Apple product. A good example is the HP Slate: It supports flash, but nobody cares, consumers still want the iPad.

The iPhone and the iPad will never become devices that can do everything. Of those who had this expectation, many will be unhappy about Apple's latest move, but anyone who wants innovation in smartphones, great user experiences and real choice, should be happy about the new section 3.3.1.

11 comments:

LDS said...

Ne day you will reread your own post and regret it, believe me.

Lars D said...

Why?

gabr42 said...

I don't see any reason why restrictions for iPhone should be any stricter than for the Windows.

"From now on you can only develop for Windows using C#." What would you say to that.

Lars D said...

@gabr: Windows is a general-purpose platform, Apple has never handled the iPhone as such. If you look at the value of source code, I'm quite sure that Microsoft decisions have ruined much more source code than this decision from Apple. And remember, even some Linux repositories have similar restrictions on programming languages, even though they may not have put it down in writing.

I think it is more fair to compare iPhone apps to Music in a Music store, or paintings in a museum. I see no reasons why it should be any different, as long as Apple hasn't promised otherwise. Apple is still a small player in the mobile phone business, and under severe attack from many sides, and I see the new license as a sign, that Apple doesn't assume that they will dominate any time soon. There are lots of smartphone alternatives.

Google has already moderated their app store, too, by removing tethering apps for T-mobile customers in USA, and we are probably going to see much more of this; Vodafone just announced that they will launch an app-store, where they test all apps for compatibility with their devices. I guess that "compatibility" can mean many things, but that Vodafone focuses on delivering a great end-user experience. Even Ubuntu Linux does something similar: If I write some software using a commercial proprietary and closed programming language, and machine-translate it to C, I would not expect Ubuntu to include this app in their repository.

In a free market, anybody who thinks that they can create a better product, is free to do so. And the consumer enjoys the freedom of choice, so if you don't like it, buy something else. I have not seen any documentation that Apple has broken any promise about their product, and I believe that Apple's focus on energy efficiency in 3rd party apps will pay off in a better user experience, that may inspire other platform vendors to improve their products.

Lars D said...

It seems that John Gruber is supporting my point of view: http://daringfireball.net/2010/04/why_apple_changed_section_331, quoted:
"My opinion is that iPhone users will be well-served by this rule. The App Store is not lacking for quantity of titles."

Warren said...

The first and biggest problem I have with iPhone is the App Store itself, which makes Apple not only the gatekeeper (who gets on here, and who doesnt) but also the broker (they get a piece of all the action).

The language restriction is really best understood as making sure that they keep themselves in on all the action.

Remember the Commodore 64 emulator? What was the threat there? Commodore 64 Basic V2? Well, in short, even something that crude would allow you to load a thousand (or more) games onto your iPhone, for which Apple would receive what? Zero dollars.

And in the end it's about dollars. You can put a hundred thousand hours into an iPhone app, and you probably earn almost as much on that as Apple does.

So go ahead, and line up in the queue of people kissing up to Apple's business model. I'm a mac fan, and a fan of highly usable polished user interfaces. But I don't like being told what to do, in such draconian fashion.

Warren

Unknown said...

I think back to the days when it was IBM who pushed out statements like this. Fast forward a decade from the 80s to the 80s and their iron fist on hardware and software was left them behind. This strategy will work for a short time, but forcing someone into your development environment creates limitations. Apple has a history of closed architecture and it has been nothing but an albatross for them.

Lars D said...

I have never owned a Mac, but I realize how much Apple technology has meant for Microsoft. Without Apple, I believe that many Microsoft products would have evolved much more slowly. The same principle applies to phones.

Kyle A. Miller said...

If apps developed directly to the API provided the best experience, as you and Apple contend, then consumers will naturally gravitate towards those applications. The applications delivering inferior user experiences will be on the fringes. The problem takes care of itself. Why the fear Apple? Probably because they know you can develop equally and even more satisfying applications without using the API directly. They are not defending user experiences as they are running from competition.

Lars D said...

@Kyle: Very good point, but I don't think it works this way. Several mechanisms will work against it, and the most obvious one is the first mover advantage: it is difficult to do marketing for mobile apps, because the market is so crowded. The first to produce a decent app will have much more money to do marketing for their app than the latecome, and will also have built up a large customer base that recommends the product.

Next, we need to remember that content is king. If a large content provider wants to provide an app on all mobile platforms, they may not publish enough APIs to enable a competing app.

Joeri said...

Any argument you can make about why it makes sense for the ipad to require native-API apps also applies to PC's. The ipad is a general-purpose computing device. It's got a browser, a word processor, finance software, games, chat, mail, you name it.

The whole quality argument doesn't fly either, because apple has shown very little interest in improving the quality of the average iphone app (they remove apps for violating api usage or content rules, not for bugs or lack of polish).

So, the way I see it, the ipad is just a PC with a different UI, and this move by apple is not about quality. It is apple's attempt at redefining the PC concept to boost their margins, at the expense of developers. I don't buy into that, no developer should.

If the ipad model works well, they'll gradually phase out the regular mac and replace it with ipad-like computing devices. There's no reason XCode couldn't just be another ipad app. It makes a lot of business sense for Apple, and it's something that's very "Steve"-like.

But even if you don't buy into that, the situation remains simple. When all is said and done, ipad developers can do less than they thought they could, and they're not getting anything in return for what they're forced to give up. That's just not a good thing, for any developer, regardless of how you twist it.