So it’s true

So it’s true. Along with announcing support for subscriptions, Apple has confirmed the policy changes that many suspected were behind the rejection of the Sony Reader app: that apps can no longer link to a place to buy content for the app (there can still be such a place, just it must not be linked from the app), and must instead offer an at least as advantageous in-app purchase to do so (Apple first released a press release announcing support for subscriptions and this new policy that would apply to them, then confirmed this new policy would also apply to all paid content used by apps, not just subscriptions).

In the way it’s presented in the quote attributed to Steve Jobs in the press release, it sounds like a wager between two gentlemen: a friendly, interested contest, here to see who can bring the most people in, everything else being otherwise equal. That the publisher earns less in one case, and yet maintains equivalent prices is not unheard of, either: for instance books sold directly often have the same price in Amazon or a bookstore (setting aside any shipping, of course), even though the retailer (and this includes Amazon) takes quite a bit of margin. In fact, in some cases like the tabletop gaming world, publishers have a store on the web but downright encourage customers to buy from their friendly local game store, because they know the benefits these places provide. So on the face of it, this looks reasonable.

Except for this: what value, exactly, does Apple bring to the table here? For in-app purchases that unlock features, there is a quite justified case to be made that, since Apple distributes the app with the feature potentially present, just not unlocked yet, the hosting, screening, and to an extent, DRM services provided by Apple apply as well to in-app purchases, justifying the same 30% cut. However, none of these apply for content in-app purchases: new content can be added all the time, without the need to send a new binary to customers (as an aside, I wonder when Apple added the ability to allow in-app purchases to be added without the need for a new binary), so this content is not coming out of Apple bandwidth, never goes through the approval process, and likely has its own DRM.

This leaves payment processing. Now don’t get me wrong, iTunes is quite awesome payment processing. Back when I was a teenager I really wanted to pay for shareware, but I had no way to do so, and my parents refused to do so for me, so I played pretend by printing the order form (this was even before we had Internet). But a teenager today can buy a prepaid iTunes card with his pocket money pretty much anywhere, or use iTunes credit gifted by his parents, and buy apps for his iPod Touch, the family iPad, or the family Mac. This is awesome. So I think Apple can justify having a payment processing fee slightly larger than, say, that of PayPal. But most definitely not 30%.

Oh, there is, of course, the immense privilege of your app being allowed to run on Apple devices, but it has been established again and again that it is a deadly sin to make it difficult for people to build on top of your platform, because a platform is only as good as what has been built on top of it. No successful platform has ever collected royalties from applications, except for game consoles, but you have to remember consoles are sold at a loss or zero margin (recouped on the games), which is not exactly the case for iDevices.

The end result is that, contrary to the cases I mentioned earlier where publishers would earn less, but still earn money, through another retailer, this leaves publishers with the prospect of selling to Apple device owners at a loss, due to the fee disproportionate with the value Apple brings, as it is certainly larger than the share of profits the publisher can afford to spare for just payment processing (given that they still need to do pretty much everything else). Even if the publisher has a way to sell directly to these same consumers, and even if he was confident most of the sales would occur directly, uncontrolled selling at a loss is still way too big a risk for any publisher to take. I don’t think Apple is seeking rent as much as trying to establish a balanced system, but even with the best intents they have set up a policy that will drive publishers away.

Even if you see no or little problem on Apple’s side with this new policy, consider the following: the end result of this, whatever the reasons or whichever way the faults lie, will be that the Apple “ecosystem” will have its own specific publishers (of books, movies, comics, etc…), either Apple itself or ones that are, in practice, dependent on Apple; publishers different from the ones used by the rest of the world. Is it really what you want? Is it really what Apple wants?

Back in the 80’s, Apple with the Mac had years of advance on everyone else, and made obscene profits exploiting their then current strengths while positioning themselves too narrowly, before this caught up to them in the end. While the mechanisms and kind of partners (application developers/content providers) this is happening with are different, I wonder if it’s not what is going to happen with iOS as well.


(Sudden breakout of Haendel’s Alleluia Chorus)
Alleluia! Alleluia! Alleluia, Alleluia, Alleluuuuia!

(Now, it doesn’t solve everything debatable about the iOS App Store, we’re mostly back to before the changes made in april: it’s a bit better than that as now sealed interpreted scripts are explicitly allowed, while back then they were in a limbo; also, sealed frameworks are no longer forbidden, which may be useful in rare cases. Many issues still remain, but, while I disagree with some things, I can live with them and it’s possible to have a healthy debate about them; the terms introduced in april, however, were completely foolish. The App Store Review Guidelines document is a welcome change, as well.)

Giving In

I’ve tried very hard to avoid agreeing to section 3.3.1.

I had the foresight to renew my provisioning profile April the 21st, just before I would have had to accept the updated agreement to access to provisioning portal. This has allowed me to keep developing so far.

Even so, provisioning profiles only last three months. So as I predicted, I’m now unable to load new builds on my device, or even run already loaded applications that I signed, since the 21st of July.

Tomorrow I will be going in holidays, to a place that will be ideal to try out an iPhone application prototype I developed and validate its concept in the field.

Because even though the iPhone Developer Program License Agreement and the iOS App Store may be a pain in the body part of choice to deal with, the iPhone is still an amazingly integrated piece of hardware, more importantly underlying an excellent platform which is, IMNSHO, still way ahead of the competition.

In order to try out that prototype application, I need to be able to run it in the first place.

To run it, I need a renewed provisioning profile.

To get a renewed provisioning profile, I need access to the provisioning portal.

To get access to the provisioning portal, I need to accept the updated agreement.

I’m sorry, everyone.

Apple’s Golden Path

Much has been said about the modifications to section 3.3.1 since the release of the iPhone OS 4 SDK beta when these changes were introduced; however, as Jonathan “Wolf” Rentzsch lamented, and to my own surprise, few developers complained about them (since, after all, they are the ones most directly affected by this rule). I still stand by everything I wrote at the time (even though I wrote it while the issue was still hot and, to be honest, a bit in righteous anger), including that Apple is showing hubris, my bewilderment that anyone, and especially anyone’s legal department (which are often fussy about the smallest details), would agree to these terms, and my call to action. But some writing I have read since then has significantly affected my understanding of the situation: first Louis Gerbarg explained how this was less an anti-competitive maneuver or an attempt to control the user experience, than Apple trying to keep control the whole operating system, including its de facto parts, by preventing there being any de facto part; then John Siracusa gave his broad view of the situation (if you haven’t done so, go read it. Now. It’s an order.)

Parable of the Desert

I now picture the situation as Apple being some sort of Old Testament prophet or even messiah, leading a tribe of follower/pioneer developers to the Promised Land of The Best (Handheld) Computing Platform Ever; but there is no time to waste, as others are trying to make their own path to the Promised Land. The way ahead is not easy, with a big desert, mountain ranges, traps, and what have you. Thing is, Adobe, an important merchant in the Desktop Computing Platforms Lands, got wind of the expedition and is trying to insert representatives carrying his Flash goods as pioneers in the Apple expedition, to set up stores as early as possible in the promising Promised Land market, and why not, possibly get influence there himself selling to all factions. Apple, having always refused to carry Flash on concerns that it would slow down or possibly temporarily stop the expedition in the coming mountain ranges, realizes this, of course, and, infuriated, edicts a new rule: every morning, all followers are now to walk on one mile only on the right foot, with those unable to do so being left in the place the expedition started from that morning. The aim, of course, is that those carrying Flash goods, Flash being as heavy as it is, will be unable to do so, and the expedition will be free of them; however, there are other followers that are unable to do so either, some of them for reasons that have nothing do to with their ability to cross the mountain range or any other difficulty; but the subtext, as many of them understand it, is that Apple is not going to enforce the rule on everyone, and will only look in the direction of certain pioneers when checking that they actually are walking only on their right foot, as he wouldn’t be able to check for all of them anyway: he’s going to check those carrying Flash, of course, as well as a few others he has never liked in the first place, though no one knows how far he will actually check. All to make sure that nothing would stand in the way of the Apple expedition as it makes its way to the Promised Land. This basically sends the message that followers are at the mercy of Apple’s arbitrariness, and they’d better like it, because it’s that way or they leave the tribe.

In fact (speaking of desert…), this reminds me of Dune. In “Children of Dune” and “God-Emperor of Dune,” Leto II, foreseeing in his prescient visions an apocalyptic future for mankind, decides that he basically has to become the harshest tyrant ever and set into motion a plan to prevent that future: the Golden Path. And he follows through. (Watchmen would work as well, for that matter.) So I can’t help but think of the Golden Path when I think of Apple and section 3.3.1, except that, to the best of my knowledge, no one at Apple has the gift of prescience. This is certainly hyperbole, but I can’t shake the feeling.

You know, with rare exceptions, I have never considered blog posts (including and especially mine) to be very important in the grand scheme of things; typically they are manifestations of the current zeitgeist. But here, I can’t help but feel that anything I do would be downright insignificant in front of Apple’s “no matter the cost”-style commitment to its course. At this level you feel there is no right or wrong, no good or evil. And yet I still hold the hope that Apple will, if not influx its course, at least not react as harshly, because I care for the iOS platform.

I worry for you

Let’s get Flash out of the way first. You may notice that I barely mentioned Flash once in my original post; it was not the matter. I have no hate for Flash; I have not love for it either. It sucks for Flash developers who invested in that Flash iPhone compiler technology, but the truth is, it was Adobe who put them on the playing table in the first place, Adobe is responsible. What would be my reaction if Apple only banned Flash and very similar stuff (e.g. Silverlight)? I would say that Flash content (especially games) would get on iPhone eventually one way or the other, and Apple’s decision would only serve to set up a cottage industry of shops specializing in manual conversion of Flash content to the iPhone. I would then accept the agreement, not mention the changes ever again, and leave it at that.

But this is not the case. The first problem is the current language of the agreement. If you read it literally, Objective-C++ is actually banned, and I believe many applications in the iPhone App Store use Objective-C++, if only to integrate C++ and Objective-C together; assembly code is forbidden as well, and again I believe many apps use assembler, if not directly, then through a dependency, especially as the ARM code generated by gcc is really crappy. Also, the recent addition by Apple of a clause allowing embedded interpreted scripts with Apple’s written approval is hilarious, as no change was made at the same time to the actual Section 3.3.1, so in what language can these scripts be originally written in? C? I think the whole point is to allow game designers to write these scripts in some language friendlier than a C derivative…

Then we have the front intent, which is trying to mandate the languages used for development. One of the problems with this is that this is completely impossible to enforce. Once compiled down to machine code by a good compiler, is there any way Apple can tell what language a particular program was originally written in? There may be hints (e.g. bound checks for languages whose semantics mandate it), but no proof. And if they don’t actually enforce this, the disposition is pretty much meaningless; it becomes a way for Apple to arbitrarily bother developers that they don’t like. They may ask developers to trust them, but I believe the trust many developers have in Apple is actually in the negatives right now.

Then we have the real intent, which is to prevent any intermediate platform layer. But at which point does middleware become this? For instance, Unity might become the kind of dependency which is found in a significant proportion of iPhone App Store apps, if it isn’t already. What if they misuse some API, and all Unity games would break if a change was made? But at the same time, isn’t a game engine kind of indispensable to make effective use of OpenGL (ES)? We can already see that in practice, decisions will have to be handled on a middleware by middleware basis.

And programmers are imaginative. They will come up with corner cases you couldn’t possibly have thought of. They are also notoriously undisciplined when it comes to their tools. Often when they are mandated by their hierarchy to use techniques or tools they feel are suboptimal, they will secretly develop using a tool they think better suited to the job but not different in any ways that would be problematic (e.g. it integrates into the build system and has not relevant drawback), and when they succeed earlier than expected and/or with better performance, they reveal they had been using the unofficial tool all along. So if bosses cannot really control the tools programmers use, it is foolish for Apple to think they can.1

So my worry is that, in effect, the modified Section 3.3.1 exposes the developer agreement for what it really is: a bunch of words almost devoid of any meaning, put here mostly for form, while the real relationship is governed mostly by unwritten rules, only known through hearsay (though, bless them, tries to document them). While some claim this was always the case, this is the first time many developers are asked to agree to a provision they know they violate. And while not many developers have seemed to object, that, combined with other rejection problems, is taking its toll on the developers’ collective goodwill.

So you may say, I’m not so sure, but even if Apple is acting in a way that depletes developer trust faster than the tank of a gas-guzzler, it won’t matter if Apple eventually gets dominance over the market; these policies could even be eventually rescinded since all other platforms will be far behind. The problem is, these policies may be easy to rescind, but the effect they have on developers may very well be definitive. I’m especially worried about delayed effects here: Apple may not how much goodwill it is losing, as the effect on apps is for now insignificant, and may not get significant until it is way too late to regain the confidence of the developers who jumped ship, when Apple finds itself in a position where they need developers to trust Apple.

Also, the network effects at play in the mobile world are I feel much weaker than in the desktop: devices are networked, but mostly with servers and using open protocols, not much with each other; applications are sandboxed and don’t exchange many documents yet; etc. So even if Apple does achieve “Microsoft-level dominance” at some point, it’s no guarantee that they will stay there, especially if a competing platform is helped by developers having fled the Apple ship.

But, you may say, there remains the most fundamental network effect of all: users come to the platform because it has applications, and developers make applications because the platform has users! However, many of the best iPhone developers are not here (only) for the money. Marco Arment, whose Instapaper is considered one of the best iPad apps, has said he wrote it (on the iPhone, originally) “because [he] wanted it to exist, and [he] love[s] being able to share it with the world with the [iPhone] App Store”. This hardly sounds like a guy who targets the iPhone because the users are there and who has no time in his budget to write an Android version if it would ever strike his fancy.

Do I Worry Too Much?

So in closure, the new Section 3.3.1 could be considered overreacting payback for all the times Apple had to keep a Must Not Break™ app running in the long life of the Mac (and, possibly, the Apple II), as well as their resulting paranoia for platform code control due to these experiences. They probably think that this time, if only they would keep control and not let anyone else get leverage over them, they can withstand anything and ultimately succeed. But I think the whole point of having a platform open for third-party development is that you do inevitably lose some control, including in ways you may not have foreseen. In particular, when foreseeing a threat or after experienced it, companies will often put checks into place so that such a thing never happens (again), making sure to cover the whole threat class. But they forget these checks will catch wider than intended. Especially here, these restrictions by Apple could prevent not only known stuff (for which exceptions could be made), but also innovation from third-parties that is impossible to foresee right now, therefore the restrictions should only be made as wide as strictly necessary for the intended threat. I could keep going with aphorisms on how by squeezing too much for control, you end up losing it, but I think that by now, you get the idea.

  1. Notice “usage of private APIs” does actually matter very much to Apple in concrete ways, so they do have an actual point here. While many people see applications as living atop a platform, the truth is that an application runs thanks to a very complex symbiotic relationship with its host operating system, the terms of which are called an API. So it’s in Apple’s best interest that applications fulfill their end of the bargain by not using private APIs, to begin with.

Rallying against Section 3.3.1 of the new iPhone Developer Agreement

I wasn’t planning on starting my blog that way. However, circumstances mandate it.

Basically, Apple’s new iPhone Developer Agreement terms added to section 3.3.1 are not just unacceptable, hubristic by pretending to specify which tools we use for the job, and anti-competitive. They’re also completely impossible to enforce, and so utterly ambiguous that no one in his right mind should agree to them.

Read the additions again. They are obviously meant to prohibit “translation layers” such as Flash and other similar technologies. But as written, they could mean anything. For instance, suppose you’re using (or a dependency you’re using uses) a build system that dynamically generates headers depending on configuration and/or platform capabilities. It translates specification files to C code! It’s prohibited! Okay, you may say that it isn’t actually “code” which is generated, just defines and similar configuration. What if you use Lex and Yacc (or substitutes), which take a specification (e.g. a grammar in the case of Yacc) and do generate actual C functions? It’s prohibited! And what if you use various tools and scripts to generate variations of C code as part of your build process, because the C preprocessor is not powerful enough for your needs? To say nothing of having (some of) your code be written in Pascal, Fortran, etc.

It’s worse if you consider that the language of the agreement could be interpreted to mean that libraries that abstract even partially the “Documented APIs”, even if you use them from C/C++/Objective-C, could be prohibited. It’s in a limbo, like usage of an on-device interpreter with “sealed” (i.e. not downloadable, not user-changeable) scripts, which isn’t clearly allowed or prohibited (or rather wasn’t; the new terms clearly forbid it), so few people did it for fear of trying the legal waters. Furthemore, someone could come up with a cross-platform meta-framework with a C++ API (very possible, for instance Bada has C++ APIs), and given the intent behind this change it could be something Apple would want to block as well; I’m loathe to use the “Apple may do this in the future, we must block them now” argument, but I’m not doing so, it’s something they could try to do with an interpretation of the current language of the agreement (who’s to say the meta-framework isn’t a “compatibility layer”?).

It’s not just a matter of how the terms are written. Apple is basically trying to mandate how our programs are developed and maintained. What if you have special needs and develop a custom language that compiles down to C (which is then compiled the usual way)? That doesn’t seem very kosher under these terms. What tools we use is our business, not Apple’s; what matters is the output. It’s also dangerously close to mandating what kind of infrastructure software (as opposed to user-facing functionality) is allowed to run on their hardware.

And this disposition is also completely impossible to enforce. If you have a “translation layer” that works entirely by generating C and Objective-C code which is then processed by the SDK tools1, how could anyone or anything tell from the output? False negative and even false positives are going to happen.

You might think you can avoid agreeing to the new terms, keep using the current SDK, and ignore the new APIs and functionality… except one must accept the new agreement to be able to access the provisioning portal past April 22nd; some time after that, the provisioning profiles will expire, and development on a device will be impossible.

So what can we do? I don’t think it makes much sense to boycott development for the plaftorm, or all devices running that platform altogether, because Apple will not realise the loss until it is way too late. So we should let them know these agreement terms are a problem. There is no Radar to dupe, as this is not a matter with a product, instead you should contact them to let them know why you won’t, and possibly can’t, agree to the terms, and ask them to clarify edge cases until these agreement terms become meaningless. For instance, they forgot (I can’t see any other explanation) to list assembler code as one of the mandatory languages, so if you use, or plan to use, assembler as part of your project, contact! The same goes for shader language, so if you use, or plan to use, OpenGL ES 2.0, contact! Oh, and Objective-C++ too! Contact! Games often use a middleware engine, so if you use one, or plan to use one, contact! I’m sure some projects out there use some Pascal, Fortran, Ada or Lisp (why not?), if that’s your case, contact! Using a tool or a fancy build system that generates C code? Contact! Unsure about something? Contact! You can even use your imagination to come up with an edge case that they haven’t anticipated, however no spam please, because we’re not having a temper tantrum, but a legitimate concern about the validity of these new terms.

In closing, I will say that it’s not just a matter of Apple making the rules, and we play by them or not at all. Here Apple has reached the point of hubris, and they must be brought back down to Earth. If they are afraid that iPhone development is becoming more popular because of the installed base than because of the Cocoa Touch framework, and that developers are going to sidestep Cocoa Touch (eventually making them lose their network effect), then the answer is to make and keep Cocoa Touch awesome, which is currently the case; the answer is not to mandate its use.

  1. They may even sidestep the Xcode IDE: Xcode is not doing anything magical, just invoking the compiler, resource compiler, code sign utility, etc.