The Cake^H^H^H^HSDK is a lie!
The release of the iPhone/iPod Touch SDK last week has not gone without comment on the ‘Net, most of it being gut reaction to the terms and conditions imposed by Apple to allow the applications to be distributed via their gatekeeper site. I’ve been mulling this and the technical restrictions Apple have devised and come to the conclusion that the SDK is (almost) pointless.
Let’s look at the reasons I believe this to be the case and why the SDK itself is mostly a PR exercise…
(1) Techical problems.
I’m not going to touch on anything here to do with Apple gatekeeper role or licensing issues. I’m merely going to talk about what you can do with the SDK programmatically and how it makes many useful applications on a mobile device practically pointless.
(a) Applications have no access to the filesystem.
This is a strange restriction as the applications won’t be able to save their state. It rules out programs which need to hold cryptographic information for a start. It prevents the iPod Touch to be used as a notepad etc.
So, what programs *DOES* this allow?
Games, maybe? Erm, no, ‘cos you can’t hold the high scores. Oh, sorry, Apple’s thought of that, it seems, they’ll allow the big boys to store the high scores for you, or you could get the device to upload the scores to your central server… you can afford to have that sort of infrastructure can’t you?
(b) Applications cannot run in the background.
This will prevent any application which requires a continuous network connection. Yes, the most immediate programs which come to mind are things such as instant messaging clients, but there are other “enterprise” applications which this will affect, such as, say, an ssh terminal client used by techies in the field.. especially if the remote systems use one-time passwords generated by another application on the iPhone/Touch.
Just think about this scenario for a minute. A field engineer needs to contact a server at base via ssh. He starts the ssh client, connects to the server and gets prompted for his one-time password. Now his switches to the password generator program. Ooops! His connection to the server has just gone foom! Oh, and because the ssh client can’t store any authorised keys because of point 1(a) the probably can’t connect in the first place anyway.
So, what does this all mean about the sorts of applications which can be written?
Well, basically, the only applications which can be written are either stateless or hold their state at the other end of a network connection and don’t need a continuous connection. i.e. They use discrete data burst connections.. like HTTP. (Just what GPRS/EDGE is least bad at, funnily enough.)
(2) Apple’s licensing restrictions.
This is cash cow time. Let’s look at the restrictions:
(a) No interpretors or plug-ins.
This means JAVA, Flash and command shells are out.
(b) No direct up loading to the device without going through Apple.
You could technically have an application download onto the phone but because of the first restriction you couldn’t do anything with it and because of 1(a) you couldn’t store it anyway.
(c) Developers have to pay Apple a $99 tax per year to have their applications run on a real device.
This is *THE* real killer for hobbyist developers. You have to pay the tax otherwise you can’t even load your program onto your own device, even in tethered mode.
Oh, and if you don’t pay the tax it seems, from what I’ve read, that anyone who has downloaded your application will find that it no-longer runs.
(d) Programs mustn’t try to break the jail.
Fine, I have no problem with that, but the other restrictions will make you want to.
(e) Programs mustn’t be data intensive over the phone connection.
Fine, I can see why this is, and it has a lot to do with the TelCos not having a good enough back-haul network to cope. How would want to over GPRS/EDGE anyway?!
Conclusion
So, what do you get with the SDK in terms of the possibility to write programs which you’d actually want to use as a hobbyist or even corporate techie? Not a lot.
So, basically, the same people who are jailbreaking the iPhone to load their applications will STILL have to jailbreak the iPhone to load their applications as only pointless applications and toys will be able to be loaded the official way (with the annual payment of tax to Apple, of course).
You won’t see any GPLv3 code on the iPhone/Touch as you can’t distribute the code with the certificate to allow you to build and run the code.
So, in conclusion, this is a PR exercise, nothing more. Apple had to develop the SDK for their own internal use anyway so it costs them nothing to give it away. It costs them a small amount to set up the infrastructure for distributing the applications and vetting them, but this is trivial relative to the cash cow of the $99 per year per potential developer and a third of any takings from commercial developers. I can here the Ka-Ching! from here.
How it might have been….
So, how could Apple have had their cake and eat it?
I understand entirely that Apple don’t want rogue applications on the iPhone. It could tarnish the image of the device for the general public and corporate management. So, placing restrictions on generally distributed applications is AGoodThing(tm). However, they’ve thrown the baby out with the bath water.
Some might say that many of the restrictions are there to prevent applications misusing the device and jailbreaking it. Well, I have news for you, the cat’s out of the bag already. Restricting the SDK won’t help at all, in fact it will make things worse ‘cos techies can’t run what they want using the SDK and hence will be forced to jailbreak. Doh!
So, what could Apple have done instead?
Actually, that potentially quite easy.
Firstly, give applications a restricted access to the filesystem. Even if it’s each application gets a virtual filesystem in a file, it doesn’t matter. The OS can restrict the size and an initial version can be downloaded with the application.
Secondly, allow those with the SDK to build and run the application only on their own iPhone/Touch. The SDK could copy a cryptographic key from the device and use that to sign the code before uploading it to that device.
In that way the only method of distributing the code would be via source code or via Apple’s official channels (binary distribution wouldn’t work in any other form). Hey, Apple could even have their own version of SourceForge for the projects.
The effect of this one move would be to decrease the pressure for jailbreaking the phone. It would also mean that it was non-trivial to get programs running on the device (meaning that non-techies would be protected) so that rogue programs would not be a problem for the general population, keeping the normal folk’s devices clean.
As for the spin that hobbyist code risks crashing the iPhone/Touch. Well, if it was allowed to then the iPhone/Touch’s OS is rubbish and there has been no evidence of this happening on similar (in hardware terms) devices such as the Nokia N770/800/810.
Apple have missed a great opportunity here for good will and (potentially) a bigger uptake of their platform with very little risk to themselves.
Edit: I’ve just thought of a way around 1(a). Get the Calendar application or AddressBook to store the data for you! 🙂