Apple has gone out of their way to point out the cons of multi-tasking background applications -- a claimed 80% reduction in battery life while on standby with a single 3rd party IM client enabled. Push Notification, likewise, has been promoted by Apple as providing a single point of coordination for 3rd party alerts routed through servers on Apple's end.
But unlike the code-once, release-done model of background processing for a single app, Push Notification requires developers to create a server system on their end as well, one that's constantly and reliably available to send alerts to Apple, and scales to an iPhone and iPod touch user base already exceeding 30 million units.
Ars Technica's Erica Sadun goes into detail on the process and problems:
Consider an application with just 10,000 users. It might service a million uses per day, assuming update checks every 15 minutes. More time-critical uses might demand checks every few minutes or even several times a minute. As the computational burden builds, so do the hosting costs. While cloud computing provides an excellent match to these kinds of needs, that kind of solution comes with a real price in development, maintenance, and day-to-day operations.
For more on additional issues, like security, and whether or not small developers will even be able to afford to implement Push Notification, check out the rest of the article.
Any developers out there avoiding Push Notification for just those reasons? What could Apple do to help you out? Offer a hosting system for small developers on Apple's end?