Matt Gemmell

TOLL is available now!

An action-thriller novel — book 2 in the KESTREL series.

★★★★★ — Amazon

iPhone Developer Complaints

development & tech 9 min read

There’s been a lot of whining lately connected with iPhone development. Here are a few thoughts on the matter. Where by “thoughts” I mean “utter flamebait”.

People seem to have been mostly complaining about two things, so let’s address those individually.

The NDA is still in place

The iPhone developer NDA (which limits public discussion of the APIs, prohibits sharing code for the platform and such) is still in place even after the launch of the App Store, ostensibly hindering developers who wish to collaborate, help each other with code and tutorials, and so forth. People are sufficiently annoyed about this that there’s a Twitter meme (surely by now the last bastion of the man-bitching session) built around it, which doesn’t warrant further publicity here.

It's worth noting at this point that I received an email from Dr. Harry Zink regarding the NDA, which I'll reproduce here with his permission:
I really dislike it when people get all up on their high and mighty horse (like certain 'developers' on TUAW), demonizing Apple and claiming they are unable to do something, when in fact there is no such limitation. The NDA does not allow you do discuss anything covered by it in public, or with people that are NOT covered by the same NDA - and well so it should. On the other hand, you are free to discuss NDA covered issues and topics with others covered under the same NDA. All NDAs have always been written up like this, and Apple's is no exception. As a developer, you are free to meet up with other developers that signed the same NDA, and discuss the finer points of developing for the iPhone. You could even conceivably set up a very private discussion forum, with invitations extended to ONLY other developers under the same NDA (in other words, look up the words 'very' and 'private' for added emphasis) - so the argument that productive discussions can not take place amongst developers are simply strawman arguments advanced by, I would guess, pseudo-developers that are locked out of these actual discussions - and probably for good reasons. As so many of these, these arguments seem built on the usual sense of entitlement by the peanut gallery (or those who haven't bothered reading an NDA. Ever.)
Many thanks to Harry for this clarification, and for his permission to reproduce it here.

This state of affairs is indeed genuinely annoying, but we have to believe that there’s a very good reason for it. The iPhone SDK is in no way a “secret” since anyone at all can sign up and get access to the documentation etc immediately, so there must be a sound legal/business reason for not yet having lifted the NDA. Yes, it’s possible that the inability to release sample code, write tutorials, participate in public chatrooms etc is having a small, temporary limiting effect on iPhone development, but it’s not as dramatic as some of the most vocal complainers would lead you to believe.

Nor is Apple unaware of these effects, despite the inexplicable implicit air of grand revelation that some complainers seem to use. This is not being done on a whim, nor is it based on some false notion of API secrecy or a lack of understanding of the negative effects of maintaining the NDA at this time. It’s naive to the point of sticking your head in the sand to claim otherwise. Have some patience, and see what the 2.1 release of the firmware brings.

For what it’s worth, my belief is that a large part of the reason for the continued existence of the NDA is simply that the iPhone OS APIs are not complete and finalised, and thus not yet in a publishable state. The fact that apps are being accepted into the App Store strongly indicates that the current (firmware 2.0) APIs will not change to any significant degree in the near term, but this doesn’t mean that the APIs are actually complete.

I can well imagine the backlash if the NDA had been lifted in time for the launch of the App Store, there had then been a rush of published books, scheduled classes and so forth, and then Apple had completed the SDK APIs (for push notifications etc) in 2.1, leaving the books etc all in almost immediate need of updating. The need for further revisions always happens in technology, of course, but within a couple of months of a supposed 1.0, and in such critical areas?

Which, of course, is nothing to say of the implicit “published = finished” assumption, which would lead directly to reports that the firmware-2.0 lack of push notifications etc essentially “cripples” an app’s ability to provide meaningful periodic interactivity other than when the user explicitly launches it. You can see how the combination of these issues could conceivably lead Apple to simply keep the NDA in place until a more natural publishable API state was reached.

This is, of course, all total conjecture on my part - the point being that we don’t know, and have no way around it at present, and might be better advised to focus on actual development rather than the rending of garments.

Apple is keeping some APIs and capabilities to itself

Well, welcome to real life. Of course Apple is applying double standards; that’s completely to be expected, and isn’t necessarily even a bad thing. You have to put aside the moral ideals for a moment and deal with these situations on a basis of business reality. The actual reasons behind these “decisions” are always going to be some combination of the following:

API maturity

The various currently-private APIs, whilst in use throughout the Apple-supplied applications on iPhone, are not yet seen as quite mature/robust/well-documented enough for public consumption. God knows there’s enough complaining (from folk such as myself, I freely admit) whenever we find an issue in one of Apple’s public APIs. Cue a flurry of Radar duplicates with prominently publicised issue-numbers, six blog posts from all the usual suspects, and an avatar-changing meme where we all lick Gruber’s earlobe.

My feeling is that it’s far better to have to wait for an API and get one that’s reasonably solid, rather than to ship code which makes use of something cobbled-together that’s going to change or break soon afterwards. Particularly when such breakage would be tied to an extremely high-profile new revenue source for Apple, which the entire industry is watching very closely indeed.

Consistency and integrity

Incredibly, it’s possible to have the dual requirements that (1) a standard API exists, and (2) you don’t have direct access to it. I’m thinking about things like app launch animations, the ability to put indicators in the status bar, global overlays like the incoming call or SMS displays, and so forth.

You want this to be consistent, or else you’d complain about it (in fact, I’d be the one complaining there). But, you don’t want third-party apps crapping up your status bar or vomiting overlays as you use the Photos app to browse your collection of mediocre pornography. These two requirements are not contradictory in any way. Let’s all just take a moment to try and grasp that world-toppling concept.

Quality of experience

We keep coming back to this, and indeed Steve mentioned it himself way back when, but it’s a huge point: this device is a phone (the fact that it comes in an iPod variant is neither here nor there; the OS must serve the most nominally QoS-critical platform, which is of course that of the phone).

I’ll say that again: this device is a phone. It may also fit the description of a PDA, an ultra portable computer, a music and video player, and a web hip top tap pad or whatever the trendy term is these days, but fundamentally it’s a phone. At all times, it must remain immediately responsive to incoming calls, available for outgoing calls, and should presumably provide the same guarantee for SMS messages, voicemail, browsing contacts for the purposes of the aforementioned functions, and auto-negotiating changing network availability conditions.

This can’t be done without imposing restrictions of some kind. Running an OS with protected memory is a significant help, of course, and you also have the somewhat simplistic approach of monitoring an app’s resource usage and sending warnings or just plain terminating the process when necessary (as iPhone OS already does for RAM usage), but that’s not enough. You still need a way to ensure that third-party applications behave reasonably.

The thing is, we as developers are incapable of behaving reasonably. You and I, and the rest of them. As a group and as a whole, we’re incapable of not releasing needless crapware (take a brief glance through the App Store for 2 minutes; I’ll wait). We’ll release spyware, either deliberately or through the developer presumably having had a stroke before implementing a feature. We’ll create websites which are at the very least littered with ads and popups, and which may even be actively malicious. We’ll release poorly-coded bloatware that’s graphics-heavy and resource intensive, and we’ll do it without a solid grasp of memory management, which will make our code leak memory all over the place.

Now, of course, I don’t mean you specifically, oh charming and attractive reader. Nor do I mean me, of course, as a pillar of the Mac community and one of the shining lights of Cocoa development and open source. But then, it’s not just you and I - anyone at all who has a hundred bucks can get their app into iTunes, and don’t give me all that “Apple vets the apps” crap. They do to some extent, of course, but do you think that Apple is going to rely on that process? Give me a break.

Apple has to get apps onto the store, so that you can buy them, so that they can take a cut, so that the app download numbers increase, so that Apple’s revenue increases, so that the stock price goes up, and so on and so forth. That’s the primary focus; the rest is a means to that end. You know all of this. So quit acting so surprised and sniffy, little girl, when they take measures to ensure that pursuing that end is an easy as possible, via imposing restrictions which make it as difficult as possible to compromise the core functionality of the device.

You also know how this is going to play out. The crystal ball says: more and more APIs will be opened up to us in due course, with appropriate concomitant restrictions as before. The APIs that aren’t available to us right now aren’t going to suddenly become available because of public whining alone. File a feature request and shut the fuck up about it.

Let me share a quick quote from Lukas Mathis’ Pandering to Content Providers Hurts Usability:

Yes, the things Apple has done are defensible. They did these things for good reasons. Unfortunately, not good enough reasons. Apple’s reasons are not user reasons, they are content provider reasons. Pandering to content providers may help a platform in the short run, but the decreased usability which invariably results from such moves are incredibly harmful in the long run.

Like the way the existence of the iTunes Store has hurt Mac OS X, for example?

(At which point I must of course say I mean no personal offence to Lukas; I’m just using an extract from his brief post to characterise a much larger phenomenon, representatively or otherwise. I read his blog, you should too, etc.)

I’ll just never understand this magical thinking process; it seems that whenever we don’t get access to a juicy API, or when Apple uses a new type of window appearance that isn’t yet publicly available, or when something gets locked down so that we can get access to it at all, normally sane and rational people contract some kind of temporary freetard rabies.

Fact is, pandering to content providers provides fucking content. It’s a continuing negotiation process between Apple and these providers, and we all know that Apple is about as politically bleeding-heart-liberal in its views on DRM as it possibly can be without gross fiduciary irresponsibility. Locking down the phone in order to make sure it always functions as a phone is essentially the same principle: it’s forcibly maintaining an invariant requirement, albeit this time for the sake of not compromising the most fundamental functionality of the device, rather than for reasons of legality. That’s even better for you.

Newsflash: Apple is a business. Apple’s reasons are user reasons, simply because the alternative is either not having the thing at all, or having an operating system that needs you to manually install a raft of hooky codecs before you can even watch the latest music video from your current white-chick-who-sounds-like-a-black-chick pop “artiste” of choice. You’re talking about Linux, for christ’s sake. What the hell is wrong with you?

If that’s your bag, sod off and install SUSE on your brick and have fun writing your own GPL’d Bluetooth stack. We’ll all still be here, using our teeny-tiny touchscreen motherfucking sex-phone which is actually going to still be around and commercially viable in 2 year’s time. With AppleCare.

But I digress, and there’s now a fine spray of spit on my wireless keyboard. Allow me to close by summarising what I’m saying here:

  • There's a reason for the NDA situation. It's annoying, but there's nothing for it. Why don't we wait and see what that reason is?
  • There are many reasons for private APIs and device lockdown, and they're pretty much all good for you.
  • Speaking as an NDA'd iPhone developer, oft-times OS X seed developer, and generally rational human being: Apple listens to your feedback, and will make further APIs available in due course.

The truth is that firmware 2.0 is barely 1.0 for the SDK APIs - this is literally true with regard to push notifications and a host of other smaller things. There’s no evidence of evil intent, anticompetitive posturing, or tyranny for its own sake.

So have some fucking patience.



I just loved the first comment this blog post received on Reddit:

Man, if Steve Jobs shot and killed a baby just to see it die this guy would try to come up with some reason that justifies it.

That’s definitely going on my business cards.