Push Notification a Burden to Small Developers?

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?

Rene Ritchie

Editor-in-Chief of iMore, co-host of Iterate, Debug, Review, The TV Show, Vector, ZEN & TECH, and MacBreak Weekly podcasts. Cook, grappler, photon wrangler. Follow him on Twitter and Google+.

More Posts

 

1
loading...
0
loading...
0
loading...
0
loading...

← Previously

iPhone 101: How To Set Up Parental Controls on Your iPhone

Next up →

Rumor: 3 New 3rd Generation iPhones Coming This Summer

There are 7 comments. Add yours.

Drake says:

Maybe it's apple just trying to push the idea of a premium app store again. Not allowing little devs to do what they want is pushing them out of the way for bigger companies.

Bob cobb says:

I'm SO anxious for an RSS reader that does push. 3.0 can't come soon enough

gruswitz says:

I guess Erica didn't stop her pointless and self-absorbed whining when she went to Ars Technica. I'm sure push notifications will be a real burden for profoundly important programs like Moo.
I'd much rather have the computational burden and update checks be on the server side as it doesn't compromise the performance of the device. I still wish Apple would allow a few players through for background audio streaming. I also hope Apple adds voice command across all apps. Otherwise I'm fine with relegating all apps to push notifications, though I hope we see a better integrated notification menu that won't drive me nuts with non-ignorable pop-ups every few seconds.

Jordan314 says:

I'm considering using google app engine to host my service. It hosts up to 5 million views for free and scales well. After that it costs money. I have to learn python though, the only language it supports.

fassy says:

Yes, it places a burden on developers. In addition to developing the iPhone app itself, you have to develop, secure, and test a server environment, typically in another language. That adds a ton to development costs, and in itself creates a lot of extra risk for a developer to shoulder. Add in the ongoing hosting costs -- say for the Amazon EC2/S3 package (comments on GAE below), $100-$150 per month, every month, and that is a lot of risk to ask a developer to bear for a market that with very few exceptions has shown little inclination to spend more than $5 for an application.
That is not to say PNS does not have advantages, but it does impose a substantial burden on developers. Rene's suggestion of an Apple-provided PNS service for developers would be a good one in attracting and keeping new developers to the iPhone platform.
@Jordan314
Regarding Google App Engine, as of last week there is a preview release supporting java, as well as many languages that run on the JVM. (Yes, JRuby on Rails can be made to work, with some effort.) If the enrollment is still open, you might want to jump in on it. Even if not, you can still develop locally to get a feel for their environment and restrictions.
I also have been looking at GAE for push, but those restrictions, notably regarding threads, will pose problems for the types of use a PNS notifier service would have. Last week, the Google folks also released a limited cron service for GAE developers, which might be enough for some types of applications, though I have not yet put that through its paces.

frog says:

Sounds awfully messy. I still see Apple caving in on background apps eventually - maybe in a few generations when battery life isn't an issue.

Galvanick Lucipher says:

Yes, it IS a burden to small developers (like me.) The whole system seems to assume that all apps which want push, will ALREADY be client/server apps. But I want to make an app that only has local data, and also wants to make notices on the local device. (Think calendar.) Under the current model, I have to bring up a server, sync ALL of my customers to my server, and run a job on the server that monitors the sync'd data and sends notices to Apple, who sends them to the devices, etc... All of this to get the iPhone to generate an alert about a piece of that data that it ALREADY HAS in local storage! Not only is this stupid, not only does this force the developer to carry more overhead - it also adds more potential points of failure.
Yes, if Apple offered an API for the iPhone app to schedule notices directly with their servers, knocking one whole level out of the loop, that would help a lot. Then maybe once an app starts to generate a certain volume of notices, such that it's no longer "small", give the developer 3 months to get his own server and update his app to use the new server.