Comments on: Apple's deadline for iPhone push notification passes

In June, Apple promised to give developers a way to let their applications receive updates from the outside world even when they weren't running by September. It's October.

[mbenedict]

Without Push, the iPhone is simply not competitive vs. the Blackberry or Windows Mobile for the kinds of business-friendly messaging apps Apple really wants to take a part in.

Also, Android will have Push notifications from day one. iPhone users will get sick of hearing "too bad you can't do this on your iPhone" from G1, Blackberry and WM users real quick.

[jaypres]

@mbenedict
The Push the article mentioned is about IM pushing so that a user may close the application and yet still appears online and can receive new IM messages as they arrive.
iPhone already supports Exchange pushing.

[mbenedict]

@jaypress

No, the Push the article mentions is what Apple calls "Push Notification Service" for the iPhone SDK. It has nothing to do with IM, though it can be used for IM.

There are many many (many!!) non-IM uses for Push. In trading applications, you can set the server to push data when some conditions are met (price triggers, for example.) Or your news site can push breaking news to you if it meets certain keywords. Or your warehouse can push notification when certain items are low stock. Or you can be alerted if severe weather is approaching. Facebook can let you know if someone posted on your wall. Etc., Etc.

These are things you can currently do on the Blackberry, on Windows Mobile, on Symbian, on the upcoming Android... but not on your iPhone.

Without Push, programs need to be able to run on the background and "Poll" data periodically. Oh wait, that's not possible on the iPhone either....

[ilias_14]

@mbenedict

Indeed, push notifications are an absolute must for the iPhone, but your chosen examples are rather dubious: firstly, ability to run an app in background app is not synonymous to receiving custom push notifications (i.e. unrelated to email or SMS). Android runs background apps, not push notification services--it does not implement a system-wide push capability as far as I know. Same with Windows Mobile. And for Blackberry, I was not aware that RIM provides hooks in the Blackberry server and APIs for the devices to push custom messages to user-developed apps. Probably it doesn't. But allows running in the background, I guess.

I also doubt that running Facebook in the background and maintain connection (that consumes battery) for the purpose of receiving posts, updates etc is a killer app (although it's nice). Such notifications can be received by push email.

On the other hand, IM is useless without the ability to run in the background or receive notifications when not the active app. And right now, IM on iPhone is useless.

[aasc77]

i agree IM is useless with no push. The only work around is using aol. which has a im to sms feature. Also. some im clients like trillian have plugins that allow you to forward an im to a text but. you then would then need to login to an im app to respond. app push is a much needed feature along side copy and paste across apps

[mbenedict]

@ilias:

If one can run any thread or process in the background, then one can implement real Push notification. It is in this sense I equate background apps with Push.

In the Apple iPhone world, a non-threaded App wanting to quickly show network-signaled updates today (even on the foreground) must "spin" continuously, polling the server for a notification every "n"-seconds where n is a small number (could even be sub-second.) This is a "Push simulation" scheme unfortunately used by many IM-like Apps. It is not efficient at all -- sucks a lot of bandwidth and eats the battery.

In its WWDC presentation Apple would let you believe that background Apps would have to do the same (spin-poll) to support notification. This is non-sense.

Instead, on any other system except the iPhone*, a background process or thread can open a TCP socket connection and then do a "select" system-call (or equivalent.) The task will then do a blocking sleep -- WITHOUT consuming any CPU or network cycles -- until there is activity on the TCP socket. When a signal is received on the socket, the background task wakes up and delivers notification.

Thus anytime you can have background tasks (plus the select call), it means you can implement true Push.

Having a "system-wide capability" for Push is a red-herring. The "Push Notification Service" proposed on the iPhone is there only because you can't run background processes on the iPhone. It's a hack (I mean "workaround") on Apple's part; The Blackberry or WM or Android don't need such a service, though one could be trivially implemented (i.e., simply dedicate a single background process for notification.)


[*] note: I'm not sure about PalmOS. Last I programmed PalmOS was 10 years ago and like the iPhone it did not have background processes, mainly due to licensing issues if I recall.

[AppleSuxLeo]

The deadline for AAPL to drop hasn`t passed yet however ;)