Apple's presentation at WWDC of an alternate approach to background processes for the iPhone, compared to Microsoft's Windows Mobile, has implications for both developers and users. It requires developers to invest in new systems and takes away some of their direct control of the iPhone, but it also improves the user experience and allows Apple to develop an enterprise revenue stream.

Background on Background

Historically, many smartphones have used background processes to respond to external push notifications and e-mail. One problem with that approach is that an undisciplined background application can chew up the battery and steal performance from the user interface. This has been a major criticism of background applications on other smartphones.

The dilemma is that if the phone manufacturer uses a faster, more expensive CPU to improve the user experience, the battery life is reduced. As a result, it's hard to have a snappy interface, background processes, and a long battery life. Something has to give.

One of the typical things developers like to build into their smartphone apps is notifications, and notifications have typically used background processes to respond. For example, a forthcoming iPhone app called Loopt, will be able notify the iPhone user than a friend has just come within a certain distance -- the friend might be available for, say, lunch. On another platform, a background process would be waiting for that notification, and that creates the problems described above. Add a few more like that, and the phone starts to feel like molasses.

Photo Credit: Getty Images

The WWDC Keynote

At WWDC, Apple's annual Worldwide developer Conference on June 9th, Scott Forstall, Apple's Senior VP for iPhone Software, spoke about this issue. [The keynote is the only part of WWDC not under a non-disclosure agreement.] Mr. Forstall described a limitation of the current SDK for iPhone developers, namely, there is no way of generating external notifications when the developer's app isn't running. As a result, developers who've been working with the SDK have asked Apple for a solution. Since push technologies are very popular on other platforms and Apple was under pressure to check all those enterprise boxes, the company did indeed need to come up with a solution.

For reasons that will be explored later, Mr. Forstall explained that Apple believes background processes are not the right way for the system to respond to incoming notifications. The reason, he said, is based on experience with other mobile OSes -- a gaggle of background apps can seize control of the CPU, degrade the user experience by interfering with the smooth operation of the phone, execute without the user's knowledge and chew up the limited battery power of a smartphone.

With all that in mind, Mr. Forstall made his point by demoing a strained solution in Windows Mobile ... and poked some fun at it ... a task manager. With a task manager, the user is required to tinker and decide what resources a process gets. If the user makes a mistake, and degrades or quits the wrong background app, something annoying could happen - a missed event. "This is nuts," Mr. Forstall said.

Apple's Approach: Some Push and Shove

Mr. Forstall explained that Apple absolutely wants to solve the problem, but it's going to do it without utilizing background processes and geeky task managers. The way they plan to do it is with a push notification service that developers can invoke to push badges, sounds and text alerts. [Badges are those tiny red numbers next to an iPhone app icon that tell you how many items you have waiting.]

In the case of a badge, the user who notices the badge can launch the associated app and let it receive the data to be pushed. In the case of a text alert, for example, there's a button that can launch the app to receive the data. The good news is that when the user later quits the application, it's stopped for good and there's no danger of a lingering background application, unknown to the user, chewing up the battery. The catch is that the notification must come only from an Apple server via a persistent connection of Apple's design.

Mr. Forstall showed a diagram similar to the one below that shows how Apple's notification system will work. With desktop systems, the app (or a background daemon) can always be running, and there's no problem. However, with Apple's solution, the layer below the dotted line must now be added for iPhone users.

Developers React

The issue, of course, is that now the developer will have to deploy a new server to interface with his or Internet services and they will have to connect with only an Apple server that has the sole privilege of maintaining that persistent connection to iPhones. That may or may not be the way the developer would like to communicate with their product running on your iPhone, but that's the plan.

Some developers may have even missed the subtext of having to set up their own servers. For example, if a developer wants to write a Twitter app that pushes, he also needs to set up a server (or even a bank of servers) that will login to Twitter, pull each user's data, and then turn around and push a notification to Apple. When the notification gets sent to the iPhones subscribed to the service, the user then knows it's time to wake up the Twitter app.

Craig Hockenberry, one of the principals with The Iconfactory, makers of Twitterrific, told iPO that this may not be a problem. "Sure, you have to setup your own servers. For most developers, that's a better situation anyway -- more control over what gets sent as a notification," he said.

Such a system will have an inherent startup cost. Mr. Hockenberry sees that as beneficial as well. "[The cost] keeps developers from doing it 'just because it's easy.' Alerts are something that should be carefully considered: they require the users attention, and in a mobile environment, that attention is precious," he added.

Sam Altman, the CEO of Loopt agreed. "We've done push services on other platforms and have an understanding of how this works," he told iPO. "Apple has done a good thing here. They faced a tough decision, and I can understand why they did it that way."

"We also 'get' the idea that some [background] applications just shouldn't be trusted with battery management," Mr. Altman added.

However, not every developer, with a great idea and well accustomed to the Mac OS X way of writing applications, may have the resources to do what these two companies plan. Also more ambitious applications, too ambitious for the current state of the iPhone technology and SDK, may have to wait.

One developer worries about security issues. "Let's assume ten developers set up Instant Messenger applications, and each of them sets up a server bank to handle badge updates so you can see how many new AIM messages you have right from your 'home' screen. Are you willing to let those ten developers store your AIM username/password on their servers just so you can check out their app?" he asked.

Digging Deeper

While Apple hasn't divulged all the details of exactly how the system will work, starting in September, 2008, it's possible to make some educated guesses based on other smartphones. James Lee, the President of Tropical Software, told iPO that because the iPhone is so new, it has to remain lightweight for the time being. That is, when the phone rings, it must ring immediately. "To get that instant response, Apple is probably doing its own preemption, reserved to just them. All computing, for example Safari, is secondary to phone activities. The question is," he said, "how much control is given to the user in order to guarantee a certain kind of experience." That control, of course, places corresponding constraints on the developer's liberties.

"For example, there may come a day when viruses do develop for the iPhone, and a company would like to develop, say, an antivirus application that scans the storage system in the background," Mr. Lee pointed out. That's not possible right now. "Apple might allow that down the road, but for now, they're taking baby steps."

Another issue is that Apple, by virtue of its high level preemption system, doesn't allow background "pull." So if a developer wanted to write an alternative e-mail client that would continuously pull down e-mail and always have it ready, it couldn't do that.

There are other implications for Apple's technique. Smaller developers may be forced to pool resources and share a single notification server, suggested Gray Rothkopf, the President of Zero One, a global groupware services company. "This absolutely will happen," Mr. Rothkopf said. "It'll be the source of some new innovation." The downside, however, will be that smaller developers will be depending on someone else to notify their customers. That could give them pause.

Apple's Business Case

Clearly, there are pros and cons to Apple's notification system. Some developers may feel constrained for the time being and others with more resources can afford to grow with the iPhone platform. How can one assess those pros and cons?

Mr. Rothkopf suggested that the way to analyze what Apple is doing is to look at the industry as a whole. "RIM is an important example," he told iPO. "RIM has been extremely successful building a revenue stream around their phones. They've done that with middleware required for enterprise use combined with an easy to use device. Apple has the second part, but not the first. It's a business strategy to invoke the required control and and maintain a level of quality."

"For example, most customers don't understand these technical issues with misbehaving background applications. They just want the phone to work. And if their iPhone doesn't work right, who do they blame? Apple."

Mr. Rothkopf agreed with Mr. Lee that Apple is still a startup company when it comes to the iPhone. As a result, he believes Apple will, as it builds that revenue stream, continuously monitor the situation and change its business model accordingly as the platform grows. That could eventually give developers more control over the iPhone operation and user experience.

For now, however, Apple iPhone developers and their customers will have no choice to go along with Apple's strategy. Understanding both the technical issues and Apple's business model will go a long way towards appreciating how that new iPhone 2.0 will work in 2008 and possibly change down the road.