On the management of the performance of older iPhone models

When the coverage that Apple had admitted to capping performance of older iPhone models (when it detects their battery may no longer be able to withstand the necessary power draw) reached the (French) morning radio news I usually listen to, I knew Apple had a PR crisis of epic proportions on their hands.

Much has been written about this covert update to these iPhones, but the most important lesson here is the illustration that, once again, Apple completely and utterly fails at communication. If that PR crisis is not taken by the higher echelons as a wake-up call for Apple to take communication seriously from now on, what will?

Let us back up a bit, at the time Apple engineering was devising this solution for the (real) issue of some devices spontaneously resetting because the battery could not sustain the instantaneous power draw. We know it is the case that this was a project of some sort, in particular because the solution was rolled out for some models first, then other models, etc. Such a thing was obviously documented internally, because it is an important change of behavior that their own QA teams will notice when qualifying the software for release, also because it resolves a support issue, so obviously customer support was in the loop so as to provide feedback on which compromises are acceptable, etc. And yet, at the end of the day, when the fix is about to widely land in people’s phones, the system inside Apple is so completely stuck up on secrecy that not even an extremely expurgated version of this documentation makes it out the door? What is wrong with you people?

As a developer-adjacent person, I can see many developers being affected by this when they can’t understand why the performance of their product has regressed, but this pales in front of the perception by the general public of the whole affair… Indeed, many perceive (with or without justification, doesn’t matter) their computing products as slowing down over time, and given a lack of an easy-to-pin-down cause (I think it’s partly perception, and partly the compounded effect of multiple reasonable engineering tradeoffs), they are more than ready to embrace conspiracy theories about this. And now you’ve given them an argument that will feed conspiracy theories about this for decades! Even for issues completely unrelated to this performance capping (e.g. more pervasive performance pathologies). Stellar job here, Apple! Engineering-wise, I can’t fault the technical solution, however faced with someone affected by the issue, I can’t see how I or anyone, even an army of Apple geniuses, could credibly defend Apple. For all of us who trust on Apple to make reasonable compromises on our behalf (because we want to buy a computer/tablet/phone, not a computer/tablet/phone-tinkering hobby), and who told their interlocutors to place the same trust, you have damaged our credibility — and yes, it is something that should worry you Apple, because our credibility is part of your brand, ultimately.

On this particular issue, now that it has reached criticality, I think Apple made the right call in offering to replace batteries for $29 when they are degraded enough to trigger the capping, but that of course reeks of PR damage control, because that is (also) exactly what it is, so the bigger question of Apple’s capability to communicate remains open.

And I can’t close without saluting the work by the Geekbench crew to narrow down and confirm this effect. I’ve been critical of their product in the past, and I still am, but I have to recognize that it has allowed to bring this action from Apple to light, and I am thankful to them for this.

The Mac App Store and long-term app preservation

I am fortunate enough not to have apps on the Mac App Store, and I have bought few enough apps on it (for reasons I previously exposed) that I initially missed the meltdown, due to the store, of many apps bought there. This is not an outage, in the sense that an outage implies the user is aware on some level on being dependent on an online resource; this is worse. This is not just unacceptable: this is a fundamental violation of the trust that both app developers and customers have placed in Apple, namely that bought, installed and compatible apps would keep working (short of any dramatic action taken for consumer protection so that they would not, such as revoking the certificate of a malicious developer).

Worse, this has implications beyond the Mac App Store per se. As you know, Apple is reserving many APIs related to online services even in a remote fashion to Mac App Store apps: even when there is a non-Mac App Store version of the app available, it cannot make use of iCloud (is there a typo version of “revealing tongue slips”? Because I initially typed ”iCould”…) or Apple Maps. So, in turn, how am I supposed to trust iCloud or Apple Maps, if I am not sure I can run any app that can access it? As if these services did not already have a reputation…

But even more troubling are the implications for long-term usage and preservation of software and it data. The consumer issue of not being able to trust that a purchased app will keep running even when nothing else changes is bad enough (you could set back the system clock, but how realistic is that, even in an unconnected system? You would no longer be able to trust the creation or modification dates of any of your documents, for a start); but the implications on being unable to preserve running software on a cultural level is frightening. Even more so for the documents with proprietary formats created by that software. I’ve been following with interest the initiatives of Jason Scott in that area, I am definitely down with the need to preserve this software and data, not just for ourselves, but the future generations. And the Mac App Store (and the iOS App Store, the only difference being that we have not had any fire drill on that side. Yet.) is “not helping”. To put it mildly, because this blog tries to be family friendly.

I initially though there was no DRM component to this story: certificates, “damaged apps”, that sounded like code signature infrastructure, in other words protection of the consumer against malware, something that the user can disable (ostensibly, at least). But when I tried to convince my Mac to run this app as an unsigned app, I encountered what is extremely likely to be the store DRM: I initially got the “your app was bought on another machine” message, so I tried deleting the receipt, but then I got the dreaded “app damaged” message, at which point I removed the signature. But no way: in that case, what happens is that the app does not launch either, with the console printing:

13/11/15 15:36:23,608 com.apple.launchd.peruser.502: ([0x0-0x2cc2cc].com.tapbots.TweetbotMac[9317]) Exited with code: 173
13/11/15 15:36:23,663 storeagent: Unsigned app (/Applications/Tweetbot.app).

Since I removed the MAS receipt, how is storeagent getting involved? Probably in order to decode the app DRM, and as you see it refuses to do so due to the app being now unsigned. So now we have DRM preventing us from running our legitimately bought software. I have kept a pristine copy of the app in a safe location to make further attempts, but the only way I can see is to create a new root CA which I install on the machine as a trusted root, and redo the signing chain, and even that might not work if the DRM is somehow tied to the signature chain.

I was already wary of buying apps without trials; this event guarantees that I will never buy anything else from the Mac App Store (and will try to obtain direct licenses of apps already bought there). No direct version of your app? You don’t get my business. I would delete the Mac App Store app if I could. Apple could change my mind by providing verifiable commitments on the ability to disengage the signature checks and in operational service levels, and even then… Furthermore, Apple owes an apology to all the app developers who trusted them with the Mac App Store and who had a long day (and will continue to have long days) of customer support entirely due to Apple’s incompetence.

Apple later on sent emails to developers to explain themselves on the issue; I will count that as the aforementioned apology. I don’t mind that they took a few business days to react, as they themselves had to figure out what the problems were from the multiple reports; I do mind that, operationally, they allowed developers and themselves to be caught flat-footed in the first place: why isn’t there anyone at Apple checking that a sample of Mac App Store apps do run on a machine with the time perpetually set to one month in the future? Still, I guess I’m glad we got an answer in the first place. — November 19, 2015

~ Reactions ~

Rainer Brockerhoff, besides presenting some investigations and corrections, took some issue with my investigation methods, and we started exchanging in the comments there. Don’t miss it.

Apple is all grown up. It needs to act like it

Look. I have already argued about Apple reaching hubris. I have previously written about what seriously looked like power abuses, then chronicled in the past how their credibility may be eroding (while adding a jab at how I thought they were stretching the truth). And rest assured there are many other events I did not cover in this ongoing iPhone shenanigans category. But here I really have to wonder whether Apple is currently engaged in a oneupmanship match with itself in that regard.

The latest events, of which the Transmit iOS feature expulsion is but the most visible, have made me think and eventually reach the conclusion that the iOS (and Mac, to an extent) platform is not governed in a way suitable for a platform of this importance, to put it lightly; even less so coming from the richest company on Earth. Apple has clearly outgrown their capability to manage the platform in a fair and coherent way (if it ever was managed that way), at least given their current structures, yet they act as if everything was fine; the last structural change in this domain was the publication of the App Store Review Guidelines in 2010, and even then, those were supposed to be, you know, guidelines. Not rules or laws. And yet guidelines like those are used as normative references to justify rejections and similar feature removal requests. This is not sustainable.

Back at the time of the Briefs saga, I was of the opinion that the problem was not so much the repeated rejection decisions than the developer being repeatedly led to believe that with this change or maybe that change Briefs could be accepted, only for his hopes to be squashed each time. Look, I get that the Apple developer evangelists at DTS (Developer Technical Support) honestly thought Briefs would be a worthwhile addition to the iOS platform and genuinely were interested in this app seeing the light of the day on the iOS App Store; but at the end of the day, it was Rob Rhyne’s time and effort and livelihood that was on the line, not theirs, so yes, the fault for the whole Briefs debacle lies with them, not the iOS App Review Team. Today, the same way I wonder whether the fault really lies with the iOS App Review team. Okay, okay, before you go ahead and drown me under the encrypted core dumps reported from users of your iOS and Mac apps, hear me out. To begin with, no matter how desirable (including for some people at Apple) a rejected app is, if the higher ups at Apple were to start issuing executive orders overriding App Review Team decisions, or if pressure was put on reviewers by other Apple employees to accept an app, it would undermine the work of the App Review Team at a fundamental level, their authority would become a joke, and anyone worthwhile working there would quit, leaving the rest to handle the reviews. I don’t think that is what anyone wants. So yes, this means that regardless of the great work on new APIs from the OS software teams, regardless of the interest from Apple leaders to have on iOS, say, more apps for teaching computing, regardless of the desire of the iOS App Store editorial staff or Apple ad teams to feature innovative apps, regardless of the willingness of DTS to help quirky apps come to life, this means that regardless of all this, if the App Review Team isn’t on board, none of that will be of use. So its power needs to be limited, certainly, but not just about any random way.

“It is a timeless experience that any man with power is brought to abuse it […] So that power cannot be abused, the dispositions of things must be such that power stops power.” De l’Esprit des Lois, Livre XI, chapitre IV. I think it may be time for Apple to apply the rantings[fr] of an obscure magistrate from the Bordeaux area (link and expression courtesy Maitre Eolas[fr]). To begin with, all app review decisions must refer to normative texts published before the app was submitted (no retroactive application). I can already hear reviewers (even though I know they will never say it out loud) complain that they cannot possibly predict every situation in advance and need the flexibility to come up with new rules on demand, to which I answer: shut up, shut up, shut up. To me, that line of thinking (which just oozes out of the Introduction to the [iOS] App Store Review Guidelines) sounds suspiciously like a George III or Louis XIV. Even if you reviewer thinks an app should not be part of the App Store, if this app has to be accepted for lack of a rule prohibiting it, then so be it; if the rule makers (which are of course different from those applying these rules) are interested, they will come up with a new rule, at which point it can be enforced on new apps. Speaking of which, secondly, enforcing rules on app updates should not be done the same way as on new apps: blocking an app update must be balanced against the drawbacks, namely leaving a buggy, out-of-date version available on the iOS App Store; this goes especially if that previous version was already violating the rule in question (but on the other hand, they do need to be able to enforce the rules in some way even if previous app versions violating these rules were accepted, as otherwise rules would quickly become unenforceable). Third, the detailed reasoning of the rejection (with references to the relevant rules) will have to be provided to the developer, and app review decisions can only be overturned by a proper appeals process attacking this reasoning. Fourth, the person arguing against an app must be different from the person making the decision, and the app developer must be able to provide counterarguments. Fifth, for these violations that directly concern users, there has to be a way for these users to complain about such a violation so as to avoid inconsistent and unfair application of the rules (Ninjawords, anyone?). Etc. In short, at least a proper judicial process based on Rules and a proper process to come up with these rules.

All of this might seem outlandish for a company to implement: to the best of my knowledge, this has never been put in place by a private entity before. But as long as Apple has these claims to try and dictate large aspects of which features apps should and should not provide to users, I see no way they can sustainably avoid such a separation of powers given how large and incoherent in this regard Apple has become; and this is even if they were allow iOS apps outside the iOS App Store and give up on Mac App Store exclusive APIs (e.g. iCloud), as the iOS App Store and Mac App Store have become too important for them to avoid such a rationalization. Look, I’m not asking for anything like a full due process or enforced independence of judges. No one’s liberty (or, God forbid, life) is at stake here. But the livelihood of developers and the credibility of the iOS platform certainly are. Apple has too many responsibilities and has grown too much to keep acting like an inconsequential teenager. Apple is all grown up, and it needs to act like it.

Did Apple just cargo cult the iPhone platform?

This post is, in fact, not quite like the others. It is a parody of Coding Horror I wrote for parody week, so take it with a big grain of salt…

In The iPhone Software Revolution, I proclaimed that the iPhone was the product Apple was born to make:

But a cell phone? It’s a closed ecosystem, by definition, running on a proprietary network. By a status quo of incompetent megacorporations who wouldn’t know user friendliness or good design if it ran up behind them and bit them in the rear end of their expensive, tailored suits. All those things that bugged me about Apple’s computers are utter non-issues in the phone market. Proprietary handset? So is every other handset. Locked in to a single vendor? Everyone signs a multi-year contract. One company controlling your entire experience? That’s how it’s always been done. Nokia, Sony/Ericsson, Microsoft, RIM — these guys clearly had no idea what they were in for when Apple set their sights on the cell phone market — a market that is a nearly perfect match to Apple’s strengths.

Apple was born to make a kick-ass phone. And with the lead they have, I predict they will dominate the market for years to come.

But never mind the fact a similar reasoning could have been made of the Macintosh when it came out. What bothers me today is the realization Apple might have handled the opening of the iPhone platform like a cargo cult:

The term “cargo cult” has been used metaphorically to describe an attempt to recreate successful outcomes by replicating circumstances associated with those outcomes, although those circumstances are either unrelated to the causes of outcomes or insufficient to produce them by themselves. In the former case, this is an instance of the post hoc ergo propter hoc fallacy.

cargo cult phone

cargo cult phone by dret, on Flickr; used under the terms of the Creative Commons CC BY-SA 2.0 license

By which I mean that Apple decided they needed to open the iPhone as a development platform, but I wonder to which extent they then did so by giving it the trappings of a platform more than the reality of a platform: third parties can sell their apps for running on it, right? So it must be a platform, right? Well… And I don’t mean the APIs are the problem either, it’s more like… everything else:

  • Apple has a very restrictive idea of what kind of use cases third parties are allowed to provide solutions to: everything that does not fit their idea of an app is rejected, or is impossible. For instance, installing third-party keyboards is not possible on iPhone:

    But sometimes, an Apple product’s feature lands at the wrong side of the line that divides “simple” from “stripped down.” The iPhone keyboard is stripped-down.

    If you don’t like how Android’s stock keyboard behaves, you can dig into Settings and change it. If you still don’t like it, you can install a third-party alternative. And if you think it’s fine as-is, then you won’t be distracted by the options. The customization panel is inside Settings, and the alternatives are over in the Google Play store.

    This? It’s from Andy Ihnatko, in an article in which he explains why he switched from iPhone to Android. Andy. Ihnatko. When Mac users of 25 years start switching away from the iPhone, I’d be very worried if I were in Cupertino.

  • Even for these use cases third-parties are allowed to provide solutions to, they are quite restricted: when Apple added support for multitasking, in iOS 4, they more or less proclaimed they had covered for every desirable multitasking scenario, and have not added any since. This feels a tad preposterous to me that there would have been no need for even a single new multitasking scenario in the two years since.

  • Even when third parties can sell their wares, they do so at the pleasure of the king. Apple seems to consider iPhone developers to be contractors/authors developing solely for Apple purposes. And paid by commission. Without any advance. And without any assurance when they begin developing that their app will be accepted in the end.

  • Apple apps do not play by the same rules other apps do. They are not sandboxed, or not as much. They use private APIs off-limits to other apps. They get a pass on many iOS App Store restrictions. In short, Apple eats People Food, and gives its developers Dog Food:

    Microsoft has known about the Dogfood rule for at least twenty years. It’s been part of their culture for a whole generation now. You don’t eat People Food and give your developers Dog Food. Doing that is simply robbing your long-term platform value for short-term successes. Platforms are all about long-term thinking.

  • In the same spirit, Apple introduced iCloud, gave users the perception Apple did the hard work and that apps would merely have to opt in, sold it to developers as the best thing since sliced bread, then promptly went and not used it themselves in combination with er, the technology they have consistently recommended be used for persistent storage (while ostensibly supporting this combination), without giving the ability to audit synchronization issues either. And now it turns out, and people come to the realization, that iCloud Core Data syncing does not work. Shocker.

  • Apple even tried at some point to prohibit non-C programming languages for iPhone development, with a clear aim to ban a number of alternative development environments, not just Flash. But just like Apple cannot provide all the software to fulfill iPhone user needs, Apple cannot provide all the software to fulfill iPhone developer needs either. A platform is characterized not just an by ecosystem of apps, but also by an ecosystem of developer tooling and libraries behind the scenes. They ended up relenting on this, but if I were an iPhone developer, I would not be very reassured.

But wait, surely, that can’t be. Apple knows all about platforms and the value of platforms, right? VisiCalc, right? But that encouraged Apple to provide something that looks like a platform, rather than a platform. As for the iPhone not being Apple’s first platform, there is a school of thought that says Steve Jobs did not build platforms, except by accident; so according to this line of thought, the Apple II and the Mac became honest-to-God platforms not because of Apple, but in spite of Apple. And now for the first time we would get to see the kind of platform Apple creates when it actually calls the shots. It looks like a platform, sounds like a platform, has the taste of a platform, smells like a platform, walks like a duck platform… but the jury is still out on whether it is actually a platform.

There is a case to be made for reducing your dependencies. Apple clearly is not going to let anyone hold it back; but as incredibly skilled as the people working at Apple are, is “not being held back” going to be enough to keep up when Android, propelled by being a more complete and inclusive platform, will threaten to move past Apple?

Apple can still turn this around. Indeed, the issue lies not so much in these restrictions being present at first, than in so few of them having been lifted since then. The key, of course, will be in figuring out which ones they need to lift, and how to do so. And this will require Apple to reconsider the motions it does to bring cargo, regardless of the cargo these actions have brought, and instead focus on improving their limited understanding of what it is that actually makes a platform. In order to really bring in the cargo.

No, Apple does not pay developers

Enough is enough. For a few years already Apple has been boasting at WWDC and various other events (earning calls, etc.) about paying however billions dollars to developers; more recently, they have put this page where they proudly proclaim their contribution to the (U.S.) economy with, among others, the “App Economy” (they insist there: “And Apple has paid more than $4 billion in royalties to developers through the App Store”). If Apple has been criticized for this claim, I have not come across such criticism, which is a shame because Apple is not paying iOS or Mac application developers by any reasonable sense of the word “pay”. This is money that the developers have earned from users, and Apple is but an intermediary in this transaction.

All definitions and usages of the word “pay” (at least when one entity is subject, as opposed to say, an investment) that I could find imply either an opposite movement of goods or services, or an existing debt the payment exists to settle; as far a I can tell neither of these is the case: is Apple borrowing money from developers, then paying them back? Is Apple placing bulk orders of apps that it then redistributes? Is Apple commissioning the development of apps? No, no, and no, and quite the opposite in fact in the last case, as not only developers figure out themselves what to produce, but Apple has been known to reject the outcome, after it was done, in ways that have sometimes lacked transparency. In the context Apple uses it, “pay” implies there is a supplier/buyer business relationship, but Apple has none of the characteristics of a buyer: it is not the one that needs to be courted, it is not the one making the buying decision, it is not the one deciding how much to buy, it is not the one providing the money. The definition with which I could most charitably interpret their usage of “pay” would be “hand over or transfer the amount due of (a debt, wages, etc.) to someone” (New Oxford American Dictionary), in which case the amount due would be the remainder after commission that Apple owes developers, and transfers at the end of the month, which is not something particularly worthy to boast about.

Apple cannot even technically be said to be paying developers. The business and legal relationship iOS and Mac App Store developers have with Apple is, to sum it up, that Apple represents the developers in front of the customers, it acts as the developer agent (hence the agency model) and among other things collects customer payments on behalf of the developer and then forwards the payment to the developer (minus the commission Apple takes). The end user is the customer in this transaction, and she pays the seller, that is the developer; Apple does not. Apple merely transfers money that the developer earned from customers, nothing more. So it makes sense to say Apple transfers money to developers, amounting more than $4 billion; it doesn’t make sense to say Apple “pays” developers, even less so to speak of “royalties”.

Even worse yet, what kind of organization would boast about creating an “industry” of 210,000 unstable, underpaid jobs? Indeed, these jobs have no long term business visibility as any one of them could be the subject of a random Apple edict in the next few years; and clearly not everyone is earning a wage from the iOS App Store, as even if you assume all $4 billion have gone to the 210,000 U.S. developers, this works out at about $20,000 on average per such “job” since the introduction of the iPhone in 2007…

To me, this is symptomatic of a level of contempt towards third party developers not seen since the contempt of Nintendo towards third party developers at the heyday of the NES. This may or may not be anything new, but Apple should take care. iOS developers are a proud, independent bunch, and it is hard enough by itself to create apps that users will buy; telling them that it is Apple that pays them is not a good tactic. One day or another, Apple will meet its Playstation, and then everything will hinge on the attitude of developers.

Don’t get me wrong, Apple has made a lot of good things with iOS and enabled a lot of possibilities, and I am thankful for that. It’s just that “paying developers” is just not something Apple does; this is money from end users that developers have earned.

“translation layers”, externally sold content, and unsandboxed apps

So Apple ended up relenting on most of the requirements introduced at the same time as subscriptions. Apple does still require that apps not sell digital content in the app itself through means other than in-app purchases, or link to a place where this is done, however. I would say this is a reasonable way to provide an incentive for these products to be offered as in-app purchases, were it not first for the fact the agency model used for ebooks in particular (but I’m sure other kind of digital goods are affected) does not allow for 30% of the price to go to Apple, even if the price used in-app is 43% higher than the price out of the app, and second for the fact some catalogs (Amazon’s Kindle one, obviously, but it must be a pain for other actors too) cannot even be made to fit in Apple’s in-app database.

John Gruber thinks this is not Apple’s problem, but at the same time Apple has to exist in reality at some point. Besides, I don’t think Apple is entitled over the whole lifetime of an app to 30% of any purchase where the buying intent originated from the app. Regardless of whether you think it’s fair or not, competitors will eventually catch up in this area and offer better conditions to publishers, making it untenable for Apple to keep this requirement. But it’s not fair either for Apple to shoulder for free the cost of screening, listing, hosting, etc. these “free” clients that in fact enable a lot of business. Maybe apps could be required to ensure the first 10$ of purchases made in the app can be paid only using tokens bought through in-app purchase (thus avoiding the issue of exposing all SKUs to Apple), then only could they directly take users’ money.

But what this edict has done anyway—besides making the Kobo, Kindle, etc. apps quite inscrutable by forcing them to remove links to their respective stores—is hurt Apple’s credibility with respect to developer announcements. Last year they prohibited Flash “translation layers”, and this prohibition had already been in application (to the extent that it could be enforced, anyway) for a few months when they relented on it. This year they dictated these rules for apps selling digital content, rejecting new apps for breaking them before these rules were even known, with existing apps having until the end of June to comply, only for Apple to significantly relax these rules at the beginning of June (and leave until the end of July to comply). This means that in both cases developers were actually better off doing nothing and waiting to see what Apple would actually end up enforcing. I was about to wonder how many Mac developers were actually scrambling to implement sandboxing, supposed to be mandatory in the Mac App Store by November, but it turns out Apple may have jumped the gun at the very least here too, as they just extended the deadline to March. In the future, Apple may claim that they warned developers of such things in advance but the truth is most of the stuff they warned about did not come to pass in the way they warned it would, so why should developers heed these “warnings”?

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 appreview.tumblr.com, 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.