Over the past few weeks, several Mac news sources have reported on Apple’s apparent failure to deliver a working solution for background processing, or at least something similar to that, on the iPhone. Whether it’s a server problem that just doesn’t scale for the number of potential users who would take advantage of it, or some other issue is unclear as Apple traditionally does not communicate about products in the pipleline (at least not until they get released). Clearly, there are apps out there which would welcome the ability to be able to receive messages/alerts while not being used. Reasons for the delay have mentioned lost revenue at AT&T if IM clients were to proliferate, the aforementioned demands such a service would place on existing iPhone hardware, or simply because the company doesn’t want to repeat the same problems it had during the initial iPhone 3G/MobileMe launch.
There is however, a fairly straightforward solution that almost no one has mentioned: Give 3rd party applications access to the same API calls and frameworks which allow the “Dock” apps (Phone, Mail, Safari, iPod) to run in the background. As it stands now, such an approach violates the SDK agreement and is reserved for use only by Apple:
**APIs and Functionality** **3.3.1**: Applications may only use Published APIs in the manner prescribed by Apple and must not use or call any unpublished or private APIs.
But given that the latest version of Google Mobile for iPhone took advantage of private frameworks in its last release, giving this to developers (at least the big ones), makes sense. In this case, I’m reminded of a Daring Fireball piece which explored the API question and reached an interesting conclusion:
There is no real technical barrier, at least in Cocoa and Cocoa Touch, that prevents third party software from calling private APIs. The public/private distinction is a social barrier, not a technical one. The difference, from a developer’s point of view, is that public APIs are more than just a list of what works now; they constitute a promise, a commitment, from the platform provider of what will continue to work in the future. A private API call is subject to change or vanish in the future. There is some reason why a private API is private. Could be that it is here to stay, that the platform vendor simply hasn’t gotten around to documenting it yet. But it could just as easily be a stopgap that the vendor intends to completely replace. And when the platform vendor in question is an opaque entity such as Apple, you just don’t know. If there is no technical limitation as to why developers can’t call private APIs in their applications, Apple could alter the SDK to allow private calls that the iPhone OS already uses, or make those specific multitasking APIs public so that all developers could use them. On the other hand, the company may have decided that the Push Notification Service was too hard to implement and instead turned it into something completely different. Apple needs to address this, especially now considering that issues of battery life, application performance and stability seem to have been resolved for most users.
(iChat for iPhone with Yahoo! Messenger support wouldn’t hurt either.)