Under The Microscope

Section 3.3 or Why We Must Go Back To The Future

As Mike noted in his post on code signing, Apple has stated that there will be restrictions on what Apple allows on the iPhone. They list the following application types as being excluded:

  • Illegal
  • Malicious
  • Unforeseen
  • Privacy
  • Porn
  • Bandwidth hog

However, this list is incomplete. Section 3.3 of the iPhone SDK aggreement includes a whole litany of restrictions for which your key to the iPhone can be revoked should you violate them. I would list them all here myself, but the license agreement itself forbids that. You can download this file from the iPhone DevCenter, but you’ll need at least a free ADC account to access it. Unfortunately, if these restrictions remain in place, opportunities for developers to be truly innovative on the platform will be stifled from the start.

Perhaps a little history can put this in perspective. Back when the Mac OS was first released in 1984, it had some limitations to it. It could only run a single application at a time, barring some utilities like Calculator and other Desk Accessories. Much like the modern day iPhone, which can only run one application at a time, barring some utilities like Mail and SMS.

This limitation of early Mac OS was solved in the end not by Apple themselves, but by a third party working in their own time. The whole story can be read here but in brief, while not employed by Apple, Andy Hertzfeld took it upon himself to add multi-tasking to Mac OS. In the course of a few weeks, he single-handedly wrote an application that could allow multiple applications to co-exist. That may sound simple in 2008, but in 1985, it was revolutionary and incredibly complex. It involved patching system traps, fiddling with low-memory variables, and playing with other applications’ memory spaces.

When Steve Jobs first saw Switcher, his reply was: “It’s great. Apple is going to bundle it with the Mac. Congratulations.” Andy had written an innovative application that improved the platform for every single user from there onward. Fast forward to today, if he had an iPhone instead of a Mac, it would have been legally impossible for him to do so. This is no mere hyperbole – the SDK agreement expressly forbids using non-public APIs, attempting to touch other applications, and running in the background, among other things.

I don’t mean to suggest that an application like Switcher should come from a third party on the iPhone, merely that such feats of magic are possible on open platforms. As it stands today, as a developer who much wants to take the iPhone to the next level, I must constantly watch to avoid running afoul of Section 3.3 of the SDK license. I must ask “does this go too far?”, and worry about pushing legal limits instead of mental ones. When Andy implemented Switcher, such thoughts never crossed his mind once, and he was able to create something spectacular as a result. We hope that Apple will see the potential of their great little device, and allow developers to push it to its utmost as well.

8 Responses to “Section 3.3 or Why We Must Go Back To The Future”

  1. CyLoNite says:

    Instead of blaming Apple, why dont you point the finger at the breed of people called Lawyers?
    In a land where one can sue for one’s cofee being too hot ( and win ), is it any surprise that your access is being restricted?


  2. Paul says:

    CyLoNite: Certainly, the issue is with the legal restrictions, but those are being placed on all this by Apple’s lawyers.

    If you want to pin the problem on the civil system in general, well, you can I suppose, but it’s a pretty big jump. Apple manages to release millions of Macs that have no restriction of this nature.


  3. DJFriar says:

    I’m agree with Paul. I’m not an established developer, but the iPhone has made me want to learn programming more than any other device. And while I have lots of ideas, many of them are being thwarted by Section 3.3. Are they good ideas or not, I dunno. I can’t find out due to these restrictions. :(


  4. Tony says:

    I have two or three ideas about software to write, and I’ve been holding out for the real SDK to get it right. This section completely destroys any chance of writing any of them.

    TBH I’m hard pushed to think of a useful app that’s writable… For example there will be no 3rd party MMS for the iphone. No MSN, AIM. No VOIP.. all require background listening threads to be useful. No enhanced mail. Devicescape, an app that I use daily as it makes the wifi on the iphone actually usable.. not possible under the SDK.

    It’s interestng that they demoed AIM on the launch.. by apples own rules this app is not legal!


  5. Devon says:

    CyLoNite,
    How is allowing background applications opening up Apple to lawsuits?

    I think I know their reason for this restriction which is running out of memory. That’s a valid problem because there is no swap file but it does really limit what applications you can use. Skype or some other VOIP program will probably be coming but it’ll only be useful for outbound calls because it can’t run in the background. I bet someone will figure out how to do it and there’s going to be an active community still hacking around Apple’s limitations on the iPhone just as there is now. We’ll have background chat clients and whatnot as well as ways of installing applications and going around the App Store. It just sucks that people have to do all that just to install your own apps for free.


  6. Peter Quade says:

    I habe not read through the whole agreement, but don’t you think special agreements with bigshots like Skype or AIM are possible?


  7. Mike says:

    Special arrangements are not only possible but expected. That’s part of the whole problem. If you have enough money you can do whatever you wish, but the little guys get cut out. As one of the little guys who uses software made by other little guys, I object.


  8. LGW says:

    Well, maybe much of the “Switcher for MacOS” and the obviously unlikely “Switcher for iPhone”-situation might be based on one rather simple, but a) ugly and b) hard to accept fact:

    It’s not 1985 anymore.

    As a big OSS advocate, I do not like all this lockout/signing/control freaky stuff. But just considere for a mere second the following scenario:

    What if apple would have rolled out an operating system on their iPhones that was as insecure and open as the first version of MacOS? What if they would actually SHIP something like that on a current Mac? And this is not about 10% of unlocked iPhones. this is about approx. millions devices (by now), all sharing the same exploit, all connected to one vast network. This scares me.

    Times have changed. And I don’t mean that in a small way, I mean it in a big way.

    I actually learned programming on a //e. I continued on x86 (by chance) for two decades. I saw OOP raise. I fondled around with windows 3.11 to get a working TCP/IP stack into that system. I enjoyed seeing how my systems got communicating with the “outside” world. Suddenly it was possible to actually type a text, and like a miracle, someone in australia would be able to answer – maybe this single fact changed everything about computers I (or we) did know before – anything I could imagine, that is.

    Viruses where a big problem even before that. Accidently leaving that disk in the floppy drive you used at school, rebooting, and “boom” – you where screwed. Now, a physical drive is relatively easy controlled – you can physically decide which media to insert. You could even decide which file to run (i.e. code to execute) – is this Larry Laffer copy I got worth risking a virus on my dad’s PC? It was. And I still somehow wish I would have given THAT a second thought.

    Connecting a computer to something as big and “open” as the internet makes it vulnerable. It might get the flue just by saying hello to that funny guy that send me that weblink. Will code signing or a strict gatekeeper solve this problem? No, it won’t. It might even make things worse in some perspective. But this just supports my theory: things have changed since 1985. A lot. I was there, and I’m pretty sure you were there, too. We have to accept that.

    The main point for the “Switcher” example remains valid, though; innovation needs people. If it had not been for Woz, swinging around his mighty soldering gun in that garage, the world might look quite different today. If he had been working for someone like IBM, who knows. Maybe the superiors would not have liked his haircut, and he would still be brushing the office.

    Locking out people of innovation because of security issues is a dangerous thing to do – we might loose more than there is to gain. I’m right now just unsure whether code signing helps to maintain steve’s “I control everything and get money out of it” side, or his “it’s all about innovation and great products” side. Mostly, he switches so fast between these two these days, it’s hard to follow.

    I just hope that Apple remembers what OSS has done for MacOS. And I certainly mean THAT in a big way. It was a rather funny experience when I activated distributed compiling in XCode and saw that distcc threads popping up that where so familiar from our linux compiler farm setup. I think, if you strip OS X from all the OSS-based stuff, you would get something much like that old MacOS without Switcher. Closing out or pissing off the hacker guys? Bad mojo. Big, big, bad mojo.

    The worst: programming for MacOS just is great fun. The APIs are simply astounding, and compared to the hell I had to went through for PalmOS application development, the iPhone APIs make it more than just a “new device”. This thing has the potential to shatter everything we thought to know about mobile devices into pieces – it’s a new era. And this is just the beginning.

    Times are still changing. We all swing the hammer to forge the future in a way we like it.


Leave a Reply

You must be logged in to post a comment.

Our Software