I ordered a T-mobile G1 prerelease and was one of the lucky ones who received theirs on October 21st. I've been playing around with, and installing many different applications such as Locale, which allows you to set system configuration based on your physical location, for instance if you want your phone to go on vibrate when you get to work or after 10PM. This application relies on the ability to run in the background, monitoring your current location and then taking actions as appropriate. Because of that requirement, it could never be ported to the iPhone, which does not allow background processes. It got me thinking about whether this restriction will prevent any great applications from being developed for the iPhone, and relegate it to a high-quality consumer device that is unfit for enterprise use in the same way that macs once developed that stigma.

[On a side note: remember that up until Mac OS X, the Macintosh had a non-preemptive process scheduler, meaning that the foreground process got basically all of the CPU and could more-or-less refuse to cede it; this was great for low-latency applications like digital music, but annoying to horrendous for day-to-day computing. The parallels with the current iPhone decisions are striking.]

Here is the problem in a nutshell: the refusal to allow background processes imposes an application development philosophy that is incompatible with building something of depth and sophistication. An application must be designed to focus solely on interactions with the user and to do no offline, out-of-band processing. That works fine for web browser, email, and other interactive applications, but you only have to Google "iPhone instant messenger" to see the problem. IM is something that you naturally start and stop, and that needs to sit in the background waiting for more information. There are IM applications for the iPhone, but you can't do anything else while you use one.

As an application developer, this is a deal-breaker for me. I literally cannot conceive of a useful application that doesn't have some sort of background processing capability, and while there are certainly many well-designed and useful applications available through the app store, the current software selection has been widely criticized for its shallowness. I think that those two things go hand-and-hand. The foreground-only restriction encourages the development of simple tools with flashy user interfaces and games, both of which are in abundance for the iPhone. It prevents the development of applications that passively observe context, process information asynchronously, take actions on the users behalf, and push information to them at appropriate times, all key pieces of software that I and many others like to develop, and find personally valuable.

Apple has argued that these background processes consume an inordinate amount of battery life, although that seems like an odd argument given that it would be easy enough for a user to turn on and off as needed. To address the issue, Apple stated a deadline of early October for integration of a new push-notification feature into the SDK and the OS that would allow users to send notifications to Apple servers, which would be queried by individual iPhones. This attempts to get the best of both worlds in that applications can send a message to an external server to do processing in the background, and then push notifications to the user so that they can switch back to that application to get the new information while still preventing background processes from chewing up battery. This has two problems in my mind, the fact that they missed the deadline and even this level of functionality is still unavailable notwithstanding:

1) Application developers must now structure all their applications as client-server, where the iPhone is just a pretty interface and all processing is done on application servers. For instance, (assuming I am understanding how push notifications are supposed to work) for an IM solution, the server software would have to proxy for the user to check for incoming messages and push notifications to the apple servers for that user, which then show up on the phone. Since IM clients currently don't work that way, except for web-based tools like Meebo who are well-positioned for this kind of thing, they would have to be totally rewritten to take advantage of this capability, and the application developers would need to stand up a bunch of servers to do the proxying.

2) It still doesn't let an application developer monitor the phone's context and take action. Locale would still not be possible since when it was not in the foreground, it wouldn't have access to the user's state. iPhone-style Push notifications would be just as useless as the current setup for these types of applications.

There is no doubting that the iPhone was disruptive to the wireless industry, is a marvel of engineering, and has sold a zillion units to satisfied customers. I wonder though if it will all be undermined by this simple problem, or even if it is a continued consumer success, it will always feel like a toy compared to where a phone like the G1 may evolve to. Certainly it will be a long time before we know the answer, but I find one thing very telling: whenever I describe Locale to an iPhone user, I always get the same wistful and slightly concerned look.