Filed under: Analysis / Opinion, Hardware, Software, Apple, iPhone, SDK, iPod touch
In search of Push
Wherefore art thou, Push? Macworld has gone in search of the much-awaited iPhone feature that would let applications get their own notifications even while not necessarily active (so apps like Twitterific could have a little red number on them showing the number of unread tweets, and so on). But the Push system was "pulled" (still makes me laugh) from the 2.1 firmware during the beta phase, and as you probably know by now, it's still not on your iPhone.Unfortunately, there's no official news on the subject (Apple hasn't canceled the service completely, as far as we know, but would they really tell anybody if they did), but Macworld has a few ideas: it could be that Apple has abandoned the system, thinking that it didn't really help as much as they thought it would, or Apple is still working on it, or Apple is working on something even better. Which one of those you decide is true probably depends on what you think about Apple in general, so we'll let you make your own guesses on that.
But we will say this: we're near the end of the known roadmap for the iPhone, and people are already talking about a new version of the hardware. If we don't see an update on Push in the next refresh, it's probably likely that the only thing the notification system will be pushing is daises.
Get a WordPress.com Blog
![TUAW [Cafepress]](http://www.blogsmithmedia.com/www.tuaw.com/media/tuaw-cafepress-promo.png)
Reader Comments (Page 1 of 3)
Ed said 7:17AM on 2-03-2009
My guess is that we'll see an iPhone 3.0 software update that will support background/persistent apps of some sort. Push notifications only solves the lack of background processes for one small class of apps.
Apple is going to have increasing competition and they can't avoid supporting real persistent apps, in some way.
Modern OSs like OS X can easily support providing apps with limited CPU time, this would go a long way towards solving the battery useage issues Apple uses as their justification for Push.
Push puts a large burden on app developers, providing the back-end hardware. It'd be hard for them to support free apps with Push. Equally, it can't be used for many of the more interesting apps - anything that relies on input from the phone's hardware (e.g. geo tracking)...
I really hope Apple has seen the light.
Reply
Daniel Tull said 7:41AM on 2-03-2009
I think providing a hook to run a small part of the app in the background is the way forward. So the iPhone OS manager would call to the registered apps, calling a specific potion of code that isn't the whole app, but could write to a file or change a badge icon.
Allowing apps to register for system events, such as song playing, location change etc or just ask to be called every x minutes would save the developer having to organise a server to send notifications.
This allows for gps trackers, and messaging apps that want to check every so often for updates. I can't think of another reason why an app would want to run in the background?
Ed said 9:09AM on 2-03-2009
That could work, you're thinking of a 'services' model. They'd still almost certainly have to run as separate processes (seperate both from the OS and the main App process), but I guess they could be purely event triggered - including timers. Timers could be limited to a certain resolution, once a second perhaps.Still, just giving the app very limited CPU time would have the same effect.
Zimmie said 10:33AM on 2-03-2009
Keep in mind that the current iPhones also have extremely limited RAM and current apps tend to take up large chunks of it. There would have to be a memory limit for background services as well as a CPU time limit.
Daniel Tull said 11:06AM on 2-03-2009
Yeah that's exactly what I mean Ed. These services really wouldn't need all that much CPU or RAM to accomplish a small task such as checking a connection/page and then displaying the badge or getting the current location and storing it in a file that could be access by the full app later on.
Really don't see why Apple isn't going down this route and expecting client devs to set up servers to push from... or are they? hmmmm!
Tariq said 12:25PM on 2-03-2009
When Apple debuted their Push Notification Service back at WWDC, they said that they were going to set up the server farms, and that all the developers had to do was write the code to support it. It wouldn't be any cost on the developer to set up/maintain servers or anything like that.
Ed said 12:40PM on 2-03-2009
Tariq, I don't remember that - are you sure? I thought they'd just provide an interface that dev's servers could push notifications too. It seems unlikely they'd provide webhosting to any appstore developer for free... It's not as if it's trivial to implement a push model - 'push' vs 'on phone' is completely different code (in structure and language)...
Facebook uses a similar model, and the cost to provide (say) live, customised, updating news as a facebook app is huge - you have to push the content to each user one by one - even when they aren't using Facebook. The 'pull' model is much cheaper and more natural to program - the cost for the developer of you using the app is nil (beyond support costs).
matt said 7:19AM on 2-03-2009
I'm going to be a complete are here, but its "cancelled" not "canceled".
Reply
russ said 7:53AM on 2-03-2009
Be a complete what?
And it's spelled both ways, with the most common having one "l".
infty said 7:33AM on 2-03-2009
while 'canceled' or 'cancelled' may be slightly controversial (like, for instance, 'focussed' or 'focused'), 'wherefore' *not* meaning 'where' is entirely uncontroversial. it means, more or less, "why," just as 'therefore' doesn't mean "there".
again, tuaw shows, well, tuawiness. for shame.
Reply
Seph2409 said 7:43AM on 2-03-2009
infty, rather than seeming intellectual as you no doubt hoped, you've made a fool of yourself and missed the point, that TUAW were actually paraphrasing Shakespeare, who happily uses wherefore incorrectly in Romeo and Juliet, "Wherefore art though Romeo". The great bard also uses 'comma after and' as well as random capital letters at the start of words in sentences.
Would you suggest that TUAW should account for changes in the English language over the centuries like this: "Wherefore [sic] art though"? Doesn't quite have the same ring to it does it?
Seph2409 said 7:55AM on 2-03-2009
Maybe I should also point out your seeming inability to start a sentence with a capital letter, but this is only a blog, who cares about that kind of thing?
Oh yeah, you do.
Joe RIckerby said 8:16AM on 2-03-2009
@Seph2409
erm, no. When Juliet was saying "Wherefore art thou Romeo" she is saying "why does your name have to be _Romeo_" because Romeo was a Montague name
Harry said 8:16AM on 2-03-2009
Um, in what way does Shakespeare use 'wherefore' incorrectly? He certainly doesn't use it to mean 'where'.
cancelled/canceled on the other hand is just a UK/US difference.
DrWho said 9:01AM on 2-03-2009
Shakespeare is using wherefore in this context to mean why and more specifically the "for what purpose" meaning of why and the use of wherefore makes this unambiguous. Juliet is questioning Romeo's being Romeo (i.e. a Montague) as in 'why do you have to be a Montague'.
Which means that TUAW's usage of wherefore in this context is incorrect if it was intended to mean 'where' and not 'for what purpose' is push notification.
Seph2409 said 9:46AM on 2-03-2009
Thank you for correcting me, turns out I'm as useless with Shakespeare as TUAW are.
Victor Agreda Jr said 1:33PM on 2-03-2009
You're right: wherefore doesn't mean where.
That said, I don't think TUAW is the only website on the planet to make mistakes. But I could be wrong.
EC said 7:45AM on 2-03-2009
That's some serious insight from MacWorld...either it's happening or it's not happening AND if it's happening it might look different. With analysis this good, why bother thinking on your own at all?
Reply
Jon said 7:54AM on 2-03-2009
I think that was just a poor summary by TUAW.
KarlW said 7:48AM on 2-03-2009
I think Apple realised that they can't support a service like this. It just doesn't scale. There are tens of millions of iPhones out there, and each might have 10 applications with push support. That's 100 million push connections. Apple's servers would have an insane amount of traffic to deal with. Even if all push notifications were tunnelled through a single device connection, each app gets messages from a different server, so the 100 million number still stands.
Ruling out push notifications, Apple need to come up with something else. There's a need for background apps, and everybody knows it and has acknowledged it (Apple, its customers, and the app developers). Apple can't not deliver anything.
Reply