I’ve been transfixed by Apple’s announcement yesterday that applications developed using translation or compatibility layers need not apply for inclusion on the App Store. My first thought was that this was an obvious stab at Adobe, and my second thought was that this was an attempt to insure that other companies don’t abstract away the iPhone OS.
I am reminded of Microsoft’s reaction to Java, specifically the early hype about Java. We all think of Java as a boring server-side language now, but the initial idea behind Java was that software developers could write applications in Java rather than writing them for Windows, and that those applications would work everywhere, thus defanging Microsoft’s desktop OS monopoly. Microsoft took various steps to prevent that from happening, but they lacked a tool like App Store that would enable them to just ban Java. Apple has that card to play, so they’re playing it.
Yesterday, John Gruber posted Why Apple Changed Section 3.3.1, and I think he nails the reasoning behind the move, but he declines to analyze whether this move is really good strategy for Apple. I would argue that it’s not.
Apple already has very wide latitude in deciding which apps will be approved for the store. If apps are low quality, they can be declined. And Apple can always issue more guidelines to application developers based on the content of the apps rather than on which tools were used to build them, requiring companies who create libraries to help produce iPhone applications to meet certain standards in terms of look, feel, and functionality in order to be included. It’s not necessary to cut everyone off.
Secondly, Gruber points out that most applications built using these kinds of intermediate layers suck. That’s the real reason why Java desktop applications were never incredibly successful. It had little to do with Microsoft’s anti-competitive moves and a lot to do with the fact that Java applications were slow, had their own user interface widgets which were different than those of the native platforms, and just looked ungainly. It wasn’t easy to write great applications in Java. That alone assured that Sun wasn’t going to abstract away Windows or the Mac OS.
Thirdly, this announcement is freaking out independent iPhone developers in a big way. Nearly all developers use third party libraries to save time when building applications, and every user of third party libraries now has to ask themselves whether these libraries fall into the new prohibited category. What happens if the iPhone application you’ve based a business on is found to depend on a library that is forbidden with iPhone OS 4? Do you start over or give up? A lot of developers are asking themselves that question today.
I have no idea whether there’s anything that will run afoul of the law in these license terms, but they should bother people, and Apple should suffer in the court of public opinion for them. This is a paranoid move and a defensive one. Apple’s mobile products are the most popular in their class right now, and they have the best community of developers of any platform vendor. Given their position of strength, they don’t need to act out of insecurity. And yet this is the second big defensive move they’ve made recently, the first being their offensive patent lawsuit against HTC last month.
Apple’s innovation impresses me, but their business practices are chilling. Customers need to let them know that they expect more from the company. Apple has shown in the past that it listens to this kind of feedback. Starting in 2003, Greenpeace put pressure on Apple over its environmental practices. Today Apple is regarded as one of the most environmentally responsible electronics makers in the world. I hold out hope that similar pressure over Apple’s ugly business practices can encourage the company to be more responsible on that front as well.
April 9, 2010 at 12:07 pm
Im disappointed by Apples decision,, and hope that anti trust groups argue against it and win. As a longtime Apple consumer, from a G3, G4, G5, to Mac Pro, PowerBook G4, Core Duo MacbookPro, to Cure Duo 2 MacbookPro, numerous iPods, 2 iphones, to 2 iphone 3G’s, this anti competitive position and its consequence on developer options turns me sour to Apple. I dont want any more from Apple
April 9, 2010 at 12:47 pm
April 9, 2010 at 12:47 pm
Apple’s platform, Apple’s business model, Apple’s prerogative. http://daringfireball.net/2010/04/why_apple_changed_section_331
April 9, 2010 at 1:52 pm
A ton of iPhone development, like every other kind of software development, relies on 3rd party libraries. Granted. However, there’s a huge difference between a library that’s written in Objective-C and uses only public APIs and one that uses private APIs or compiles to ARM bytecode or something. Developers who use the former type of library have nothing to fear. Apple’s not going to yank the carpet out from under them (at least not without sufficient warning). The other folks, even if they’re using tools that aren’t specifically proscribed by 3.3.1, can’t say they didn’t see it coming once their time comes.
I’m not /necessarily/ defending Apple here, but I wanted to at least make the point that developers who have been playing by the rules all along don’t need to be asking themselves anything today.
Once Apple starts rejecting PhoneGap apps, which do comply with the letter (and arguably even the spirit) of the agreement, then they’ll have gone too far.
April 9, 2010 at 2:53 pm
It seems like the classes of app you’re discussing (compiling to bytecode or using private APIs) are already explicitly banned. This new ruling would appear to go beyond that, which is why people are worried. I find “translation” and “compatibility” to be somewhat vague.
April 9, 2010 at 3:11 pm
Hank Williams thinks the new licensing agreement is clear example of restraint of trade, a basic tenet of contract law.” http://whydoeseverythingsuck.com/2010/04/jobs-bans-non-c-libraries-insane.html
It’s one thing to ban a particular technology like the Flash Player from a device, it might be grounds for a lawsuit to dictate what tools a developer uses when the end result is the same and the app needs to be decompiled and inspected at the byte code level to find the differences.
April 9, 2010 at 4:04 pm
So, after setting up absolute control over the platform, they exercised that control in their own interest. Wasn’t that the whole point?
April 9, 2010 at 4:28 pm
Clearly. Sadly our only recourse is to stop giving them money and to make a stink about it. Doing the latter is easier than doing the former, at least for me.
April 9, 2010 at 4:39 pm
With Apple though, making a stink has never been an effective tactic in my experience.
April 9, 2010 at 4:41 pm
Apple changes in response to customers, but they’re like the Chinese government. They’re only willing to change if they can make it look like it was their idea rather than a response to pressure.
April 9, 2010 at 9:37 pm
One thing I haven’t seen addressed anywhere: Does this mean Apple will be throwing apps not written in Obj-C out of the App Store?
What happens to all those people who have already posted and sold stuff using United3D and the like?
April 9, 2010 at 11:10 pm
Note that 3.3.1 may explicitly prohibit code that can be done even within the XCode ObjC/C/C++ environment.
Say that you’re writing a game. You want to speed up some critical code so you put in some inline ARM assembly. Is that a reject? Even though it is in a .c file, and gcc has a specific syntax for allowing inline assembly blocks, it is not C, ObjC, or C++. It’s ARM asm.
The other side of the issue, with stuff like Unity3D, is even more absurd in the context of the games industry. Having a reusable core engine in C++ with a lot of game logic scripted via something like lua or boo is not exactly a new idea – it’s a model that’s been in use for years. Banning that is ridiculous.
April 10, 2010 at 12:16 pm
Apple’s relation with iPhone developers has always been paranoid and dysfunctional. The NDA saga from the initial iPhone SDK release (lasting from June to October 2008) is a prime example. Apple prevented developers from answering code questions or posting sample code, authors from writing iPhone programming books, websites from publishing iPhone programming introductions, etc. All to protect the intellectual property in an SDK that anyone with an email address (real or fake) could download.
I’m a Mac developer, so I’m already pretty familiar with the IDE, language, and most of the frameworks used in iPhone development, but I just can’t get interested in developing for iPhone. I remember after the IE/Netscape brouhaha, someone referred to the 3rd party browser business model as “picking up nickels in front of the steamroller” (a phrase which Google now associates with the last financial crisis). To me, that’s what all commercial iPhone development feels like.
April 10, 2010 at 3:07 pm
@Cliff Rowley — I’m getting sick of people pulling out that tired old staw man. No one is saying Apple can’t do this. We are saying they shouldn’t. Further, if you are a developer, you shouldn’t in good conscience support this kind if disgusting anti-competitive behavior.
April 10, 2010 at 3:26 pm
Apple isn’t in a monopolistic position, why would antitrust groups get into action (let alone have a case)?
April 12, 2010 at 12:33 pm
I’m fascinated by all this. In poking around on this for a post on my own blog, I came across this post. I wonder if one can infer a technical platform shift from this new requirement. It seems like there’s only downside in pissing off developers. What if there’s a different upside than people think*?
*(Adobe seems to think it’s “hurt adobe’s competing Flash platform”)