Two interesting developments came up while I’m studying for my next post about code signing.

Firstly, every developer who has signed up for the $99/year program has gotten a letter which says, in part:

We have received your enrollment request. At this time, the iPhone Developer Program is available to a limited number of developers and we plan to expand during the beta period. We will contact you again regarding your enrollment status at the appropriate time.

The message for non-US developers also mentions that the program will be implemented in the US first. At this point, some developers went off in a huff, interpreting it as a rejection, and numerous complaints and conspiracy theories have been aired. So far (as I know) nobody who applied to the $99 program has been formally accepted – the ones who said they were are apparently newbies interpreting their ability to download the SDK as “acceptance”. On the other hand, a handful of companies have stated they’ve been accepted into the $299 enterprise program.

Well, my understanding of English may be faulty (it’s only my fourth language, after all) but let’s look at the 3 sentences I quoted above:

We have received your enrollment request.

Nice of them to reply.

At this time, the iPhone Developer Program is available to a limited number of developers and we plan to expand during the beta period.

This is just repeating what Steve Jobs said during the iPhone event… nobody would expect Apple to accept all applicants immediately and at the same time. There certainly are several thousands at the very least.

We will contact you again regarding your enrollment status at the appropriate time.

Meaning, as soon as we dig out from under, we’ll check your application. I see no problem there either.

Apparently, some people are indeed interpreting this as a poorly worded rejection, or at best as an ambiguous directive that you have to go to the end of the line or try again. Now, I’m the type of person who has difficulty in understanding the logic of “I’m afraid I’ll have to tell you that your credit card has been declined” – the first time I heard that in person I couldn’t follow at all (heh! he’s afraid of what? will he have to say what in some unspecified future? Why doesn’t he then say whatever he will have to say, then?) But I can’t see anything like that buried in that last line either.

Second item is that the SDK’s restriction on background process has been much-commented on, among others by John Gruber and Mike Ash. Along the way, there have been complaints about this and other restrictions imposed on third-party applications. Some have even pointed out (I can’t confirm or deny) that the APIs published in the SDK are just a small subset of the APIs ferreted out by people examining the previous iPhone firmware. Some commenters even seem to believe that Apple not publishing certain APIs is illegal in some way… witness the comments about unpublished APIs called by WebKit/Safari some weeks ago.

Well, Apple can certainly opt to tell people not to use certain APIs. In fact, on the Mac in the past, some large software publishers went ahead and used some of those “hidden” APIs anyway, with the result that Mac OS X still has to support lots of legacy calls that are broken, but can’t even be properly fixed without breaking those applications!

So, on the iPhone, they’re certainly making sure to avoid the legacy/unsupported/hidden API problem at all costs. Apparently the SDK license says that applications may not use any unpublished API, period. Note that this does NOT mean that Apple will have to examine your precious source code line-by-line; no, they’ll just run a tool that looks at your executable, sees what symbols in which frameworks are referenced, and produce a listing of whatever non-documented stuff you’re calling.

So, there are no documented APIs that let you run an application in the background, or start a background process. I’m sure we all agree that having any GUI application continue in the background after another GUI application starts will be too resource-hogging – after all, if you allow one, you have to allow any. From what I’ve read, no Apple application does that either; a few seem to have a background process or daemon running to take care of communications, but that’s of course much more lightweight.

I agree with Mike that obviously the iPhone OS does support multitasking in a generic way. I also agree that the relatively limited RAM (I heard that 64M are available to a third-party application) and CPU speed are no obstacles. To mention an even older example than he gives, I managed to write an embedded system running on a 4MHz Z80A CPU, with 32K of RAM, that handled a GUI, a foreground thread, and two background threads tracing several realtime signals on a screen.

But make no mistake, embedded systems are hard to keep responsive, even if you have no arbitrary code running at all. Apple apparently elected not to have full virtual memory swapping in the iPhone OS; here again, it’s not a limitation of the hardware (Flash memory can support swapping) or of the OS (it’s Unix-based after all) or of the CPU (it does have page tables etc.).

No, I think Apple simply is trying to keep “teh snappy” always happening, keep battery duration as high as possible, and avoid Flash RAM filling up by swapping. Also, swapping pages takes time and burns battery power. A wait of 2 or 3 seconds may be shrugged off if you sit at a desktop computer but may be unacceptable if you’re trying to answer a call on the iPhone.

Consider the MacBook Air with SSD. It has 64GB of flash and 2GB of RAM, with full swapping virtual memory of course. I’ve seen people leaving 20 or 30 applications running on a Mac and not noticing that their swap files grew to 12 or 20GB… but even that may already become a problem on the Air. I suppose Apple didn’t want to face telling people that they should leave 2 or 3GB free on their 8GB iPhone… and risk crashing or hanging when it suddenly fills up.

Still, I feel that if you do have a compelling application that absolutely depends on having a background process running, you’ll probably be able to ask Apple for an exemption… if you can prove that your process won’t hog the system. Also, Leopard (for one) has facilities to start processes on-demand – using launchd, you can have the system watch a certain port or socket and start up your process when data arrives there. No doubt we’ll see more such facilities being deployed.