High Order Blog

Last week Ars Technica posted an interesting article about whether or not it’s feasible for small iPhone developers to support the “push notification” service Apple plans to include in version 3.0 of the iPhone OS.

I can speak to this not only because we’re a small company (tiny, really) building iPhone applications, but because at least one, maybe two, and probably more of our applications could be improved by adding “background notifications,” regardless of whether the implementation takes the form of processing done on our server and a small notification pushed to the phone, as Apple proposes, or processing done in the background on the client.

First, let me say that I can understand the reasons why Apple is hesitant to open up the phone to background processing. My own iPhone currently has about 5 or 6 “pages” of applications. The vast majority are ones I’ve downloaded, run once or twice, and have never run again, a pattern which seems to be representative. Furthermore, the quality of those apps varies dramatically.

Many of these apps would run in the background if they could. Would I want them to? I’m not sure. While it would be possible for developers to write background processes that are well-behaved, and therefore don’t needlessly suck up CPU cycles and battery life, I’m not convinced that would be the common case.

The cost to the user of a misbehaving background app is pretty high. Worse, troubleshooting the problem isn’t exactly straightforward. All the user knows is that his phone seems sluggish, or that his battery life doesn’t seem to be what it was. Is it the phone or an app? If it’s an app, which one out of the 30 or 40 that have been installed is the problem?

I can definitely understand why Apple wants to sidestep this whole issue.

All that said, I think the utility of Build Watch would be increased dramatically if notifications of failed builds could be pushed to users in the background. Let’s consider what would be required for Build Watch to leverage push notifications.

First, we’d have to replicate most of the business logic that’s implemented in the app within a web application. This would include storing the list of servers for each user, the show/hide status of each project (since we don’t want to be sending notifications for projects they don’t care about), and the most recent build status for each project, so we know when that status changes. This would all have to be new code, since we’re not going to be running Objective-C on our web servers. The iPhone and web applications would then have to be maintained in parallel as new features are added and bugs are fixed. (Maybe this duplication means that the architecture of iPhone apps leveraging background notifications will fundamentally shift over time. All important state and business logic will live on the server, and the native iPhone client will reduce to just a pretty front-end.)

Some functionality won’t work at all. For example, it’s currently possible to hide and unhide projects even when the phone doesn’t have an Internet connection. This is just configuration stored locally, so the current implementation is simple. Getting this working in conjunction with push notifications requires us either to forbid the behavior altogether, which is a clumsy compromise, or devise some mechanism for syncing the user’s offline changes with the server’s state. The latter can only be performed the next time the user opens the app while connected to the Internet. In the meantime, perhaps confusingly, they’ll continue to receive updates for projects they don’t care about and/or miss updates for projects they do care about.

More critically, consider people whose build servers are protected behind corporate firewalls. I suspect the majority of our users fall into this category. A web service pushing notifications doesn’t work at all for these users. One might argue that they’re not any worse off than they are now, but push notifications as a general purpose solution has no answer for this problem. Background processes, on the other hand, would work quite nicely.

Next we have to consider cost. Build Watch currently costs $2.99, and that’s a price point we like and will likely follow for future apps that are similar in scope. That’s about the price of a small latte. If we want to support background notifications, we can no longer just code up the app, release, and move on. We now have server processes we have to continue to develop, pay for, and maintain, with no obvious path for earning continuing revenue from the user.

All this must be overcome just so our little app can download a few kilobytes of RSS data and alert the user if necessary. Seems a little disproportionate, doesn’t it?

This becomes an even bigger problem for small shops like us as background notifications become a user expectation. Will users even bother checking out our apps if we don’t support this behavior?

I’m not terribly concerned with the scaling issue pointed out in the Ars article. Granted, we’re not building Twitter clients, but even if we were I’d consider scaling problems to be a good one to have. Several hundred thousand paying customers sounds just fine to me. I’m much more concerned about its limited usefulness for a large class of applications that could benefit tremendously from background processing.