thomas fitzgerald.net

There was much made of the fact that the recent beta 4 of the iPhone 2.1 software which removed until further notice, the much vaunted “push notification service”. The service which was touted by Apple as an “elegant” solution to the lack of background processing allowed by the iPhone SDK. Some were relieved that Apple wasn’t going to push (pardon the pun) out a half baked iPhone feature that could lead to more instability while others were decrying yet another Apple screw up. Overall though the delay was mostly welcomed as it would allow Apple to perfect the service before launching. Yet the news once again stirred mixed feelings about the whole idea of the service in the first place.

The idea behind the push notification service is a pretty novel concept and in many ways it seems like a good idea. If you’re not familiar with the plan, it is basically this: to avoid applications running in the background on the iPhone, and so that you can still get notifications of things like alarms and incoming instant messages, an application developer’s website can send a notification to a server at Apple which can then send a notice to the users iPhone. This is all well and good in theory, but there are some pretty big problems with this concept. First of all, in order for this to work, the developer is going to have to run their own server which collects the relevant data from a users iPhone and then acts on it to provide the notifications. This might be fine for something like instant messaging, where the information already exists online, and you are AOL for example, and already have a large internet service. How many small independent developers, whose apps would benefit from being able to provide notifications to its users, would have the resources to deploy an internet service for possibly hundreds of thousands of users if an app is relatively popular?

What about something like an alarm, or a to-do application that simply wants to tell you that you have a task due. In order for that to work the developer would have to maintain an online service that syncs with your iPhone and can then send the relevant reminders via the push notification service. It is completely ridiculous, that for the simple task of telling you that an appointment is due, for example, an app would have to rely on a complex multi tiered online service. This is complete overkill for something that happens on most other platforms as par for the course.

There are other problems with this too. One of the concerns about allowing apps to run in the background is that of battery life but if, as Apple puts it, they maintain a permanent IP connection to the iPhone, what is that going to do for your battery life? Having push email turned on already shortens the battery life significantly so what happens when there’s a whole bunch of other data flying back and forward as well. Surely a timer running in the background to let you know that an event is due would use less battery life than running the phones data connection the whole time? And then there’s a whole other can of worms when it comes to privacy issues. Will it be secure? Apple haven’t mentioned anything about that end of things? One would presume it would be, but considering MobileMe apparently isn’t secure you just don’t know. They are allowing developers to push text notifications to a users phone via the Apple servers, and what if that contains sensitive information? A task reminder for example, might have meeting details or something similar? Will that info be sent encrypted or in the clear?

And then there is the issue of reliability. A valid concern is Apple’s ability to actually run such a service. It may sound simple on paper but there’s the potential for hundreds of apps trying to send data at any one time to potentially millions of iPhones. What if someone is relying on an app notifying them of something and Apple’s servers go down? What if you miss an important message because Apple’s servers never passed on the message? There’s a huge can of worms waiting to be opened there and given the way MobileMe launch went I suspect many developers have this worry at the back of their mind. (If not they will after reading this!) There’s also the potential for such a system to be venerable to spamming and other such hacker attacks. If a developers server is sending a message to Apple’s service to be pushed to your phone, it’s not inconceivable that someone could spoof that message and flood the service spamming thousands of iPhone users with fake messages. I’m sure Apple will put security in place, but it’s a possibility, and another issue that will need to be tackled by Apple to have a reliable service in place.

I’m not trying to knock the iPhone, and I understand the reasons Apple doesn’t want unlimited background processing, but the push notification service seems like a rube goldberg solution to a problem that really doesn’t need to exist. It is a valid concern that unlimited background processing could lead to your phone becoming locked up or unusable, but then since the 2.0 software was released lots of people have been suffering these problems anyway.

So what about a solution? Rather than put in massive amounts of infrastructure just to get an app running on your phone to be able send you a message, I think Apple should look at some kind of limited background processing, or better still, have a built in notification service, running on the phone rather than a server, that developers can tap into. Rather than having to bounce across the internet, why not have a single process that runs as a service in the background on the phone for handling such notifications. Apps can submit requests to the service that would either give a notification at a certain time, change the badge on an icon or give an alert. It could also allow requests to be submitted that would check an internet address at certain intervals or when an IP connection is already established, much like the way mail works when push is off, and allow it to either notify the user or perform some action based on that data. Surely they could make such an extensible service that allows an app to request a notification be sent to a user at a certain time for example, or to check if a certain event has occurred and then give a report. This has to be easier for everyone than what would be involved in such a complex route as the push notification service.

I’m sure that if Apple is clever enough to come up with something as sophisticated as push notification they can get something simpler but similar to run locally on the iPhone giving developers far fewer headaches and considerably less resources to have to put in place for relatively simple notifications. Push Notification can still have a place for things like IM but Apple should reconsider this being the only option to help users and developers get a better experience in the long run.