With the 2.0 release of the SDK Apple promised to provide some sort of notification mechanism so that third part applications could be notified of incoming messages and potentially even handle those messages. Unfortunately Apple has failed to provide such an SDK, and I think the reason has to do with background processing: Apple doesn’t want a whole bunch of iPhone applications launching executables in the background. The problem, of course, is that any SDK which triggers a background process gives a developer the opportunity to hog CPU cycles, draining the battery and slowing the iPhone down.

I have a modest proposal as to how to handle such a mechanism which would not require a background process to be triggered which could potentially be abused.

There are three classes of applications in Apple’s iPhone suite which receive background notifications. The first class, the SMS message system and the phone system, updates the message count in their application icon, plays a notification sound, and they also post a text string summarizing the message on the home screen before the phone is unlocked. The second class, such as the iPhone Mail application, plays a notification sound and updates the message count in the application icon, but does not display a message on the home screen. And the third class, such as the App Store, displays a message count but does not play a sound.

It seems that one could easily provide a notification infrastructure through the Mobile Me servers to provide the second and third class of service to third party applications.

This would be done as follows:

(1) In order to figure out which phone should be notified, an extension to the iPhone’s API to get the device IMSI identifier would need to be provided. This would allow an application on the phone to obtain and transmit the IMSI, so the user of an application can be linked to his specific phone.

(2) An extension to the Mobile Me service would need to be made to allow a notification message to be sent to a specific device identified by its IMSI. This value would also be linked to the specific receiving application using the application’s bundle identifier, and the packet would allow a limited amount of information to be sent–perhaps around 80 bytes, more than long enough for a UUID or a small token to be sent to the phone. Ideally this would also allow the notification packet to fit within a SMS style packet over WDP.

(3) A new message notification task would need to receive the WDP notification messages for the device. This notification task service would handle receiving the incoming notifications and putting them in a database queue sorted by application identifier.

(4) Each application which can receive notifications would need to be extended with a configuration bundle containing a short snippet of XML which would indicate how incoming messages are handled. There is no application code here; instead, the XML would indicate that when a notification was received:

(a) The application’s notification number should be set to the number of incoming messages, or the number of incoming messages are added to the notification number in the application, or (for applications which send one notification indicating multiple things) if the notification number should come from the message body. (Thus, there are two orthogonal options here: each message represents 1 or more than 1, each message adds or does not add to the existing application badge value.)

(b) If the phone should play a notification message if a notification for that application is received,

(5) A new API which, on application launch, allows the application to get the incoming notifications from the notification service database.

This would allow applications to receive notifications from a remote server without having to actually execute on notification.

Now of course the channel into the Mobile Me notification service should be hardened: perhaps a two-way SSL certificate can be set up so that incoming messages from a developer must use a signed certificate to establish the SSL connection, along with some sort of handshake to verify the identity of the server sending the message and if it is authorized to send messages to the specific application. And naturally the notification service would need to throttle messages from a remote service to prevent ‘spamming’ devices, and a developer’s notification service channel would also need to exist for testing purposes.

But I think this is entirely doable, and would provide what a developer would need to develop an IM-style application or messaging application without running a background process to check for new messages.