Apple Turns on Push Notification Services for Developer Testing

[MacRumors]

http://www.macrumors.com/images/macrumorsthreadlogo.gif (http://www.macrumors.com/2009/04/10/apple-turns-on-push-notification-services-for-developer-testing/)


http://images.macrumors.com/article/2009/04/10/061841-push_425.jpg

Apple notified developers yesterday that Push notifications have been turned on and that iPhone developers can now start testing their applications with the service.Start testing your applications using the Apple Push Notification service today. Log in to the iPhone Dev Center and review the Apple Push Notification Programming Guide and Getting Started videoThe Push Notification service is Apple's substitute for background processes and was originally planned for a September 2008 release. Apple announced in March that they would finally be delivering the service alongside iPhone 3.0 which is due this summer.

This system allows iPhone applications to receive updates while they are not actively running. Apple has claimed that allowing background processes on the current iPhone would sacrifice too much battery power for it to be practical.

Article Link: Apple Turns on Push Notification Services for Developer Testing (http://www.macrumors.com/2009/04/10/apple-turns-on-push-notification-services-for-developer-testing/)

[wrldwzrd89]

YAY! This is good news for app developers - at least for anyone that could make use of Push Notification Services.

Alas, I can't afford the $99 fee to actually put an app in the App Store, so... :(

[JP M.]

The time has come!

[instaxgirl]

I find the icon kind of creepy. Otherwise, :)

[neil1980]

about time :)

[Mac-Addict]

Ahh only nearly a year late.

[hhaeschen]

I'm quite curious about what the developers have to say about it.
I just hope push notifications won't get annoying in practical experience...

[Aqueus]

bring it on.. oh wait.. don't have an iphone yet.. mdr

[kornyboy]

Wirelessly posted (iPhone: Mozilla/5.0 (iPhone; U; CPU iPhone OS 2_2_1 like Mac OS X; en-us) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.1 Mobile/5H11 Safari/525.20)

I'm glad that it appears that they will get push notification working soon. I'm also glad they waited to "get it right"

[Prenvo]

Using push notifications is a lot simpler than I had originally thought: I'm expecting a lot of apps to use it as soon as 3.0 apps are available on the App Store.

Thankfully you'll have the option to selectively turn them off (or globally) in the Settings app :)

[JoelHodder]

Finally :D

[stevejobbers]

I find the icon kind of creepy. Otherwise, :)

Who Watches the Watchmen?

[harry20larry]

his puffy cheeks are so cute!...
anyways
can anybody up the quick guided tour to youtube?

[Voidness]

Push Notifications is a great idea, but it definitely won't scale well with the iPhone's current notification pop-up.

What if I'm doing something on the iPhone (i.e. writing an e-mail), and I get a continuous stream of notifications from different applications (SMS, IM, Facebook, an RSS client, etc). First it'll be difficult to keep track of which notification from which application, and second I'll be constantly interrupted from what I'm doing.

I think Palm webOS notification system is a perfect solution to this problem. I hope Apple comes up with something similar if not better.

[wrldwzrd89]

Push Notifications is a great idea, but it definitely won't scale well with the iPhone's current notification pop-up.

What if I'm doing something on the iPhone (i.e. writing an e-mail), and I get a continuous stream of notifications from different applications (SMS, IM, Facebook, an RSS client, etc). First it'll be difficult to keep track of which notification from which application, and second I'll be constantly interrupted from what I'm doing.

I think Palm webOS notification system is a perfect solution to this problem. I hope Apple comes up with something similar if not better.
PNS doesn't have to be implemented in the way you describe. It could (and probably will) be as simple as a badge over the app's icon in the home screen. Completely unobtrusive.

[Michael73]

Push Notifications is a great idea, but it definitely won't scale well with the iPhone's current notification pop-up.

What if I'm doing something on the iPhone (i.e. writing an e-mail), and I get a continuous stream of notifications from different applications (SMS, IM, Facebook, an RSS client, etc). First it'll be difficult to keep track of which notification from which application, and second I'll be constantly interrupted from what I'm doing.

+1. I think of it like when I'm on my phone at home and during a conversation I keep getting interrupted by my call waiting. I hear that little click sound and I say, "hold on" while I pull the phone away from my ear to check the caller ID to see if I want to switch over. If not, I can't tell you how many times I saw the name, made a mental note to call the person back after my conversation was over and then forgot.

[koobcamuk]

+1. I think of it like when I'm on my phone at home and during a conversation I keep getting interrupted by my call waiting. I hear that little click sound and I say, "hold on" while I pull the phone away from my ear to check the caller ID to see if I want to switch over. If not, I can't tell you how many times I saw the name, made a mental note to call the person back after my conversation was over and then forgot.

a) I assume there's a way to turn off push for each app

b) I also assume that a little red marker will pop up, rather than a full scren interruption... ??

[scottness]

This is good, but I still want background apps. :(

[Voidness]

PNS doesn't have to be implemented in the way you describe. It could (and probably will) be as simple as a badge over the app's icon in the home screen. Completely unobtrusive.
True, but what's stopping developers from using the notification pop-ups? All the applications that were demoed during the iPhone OS 3.0 Event were using those pop-ups for Push Notifications, in addition to the red badges.

[arubinst]

It's up to the developer. You may:

(a) Put a (short) notification on screen, just like sms pup-ups,
(b) Play a sound (any sound, can be customized by the developer)
(c) Update a badge on the app icon
(d) either combination of the former 3 points

[Craiger]

It's up to the developer. You may:

(a) Put a (short) notification on screen, just like sms pup-ups,
(b) Play a sound (any sound, can be customized by the developer)
(c) Update a badge on the app icon
(d) either combination of the former 3 points

Well in that case,

To any devs reading this,

If you annoy the heck out of me, I will not buy your app! Can you have the USER choose which one to do? Like in the app's settings...

[AAPLaday]

Who Watches the Watchmen?

Your quite The Comedian :D

[Voidness]

Well in that case,

To any devs reading this,

If you annoy the heck out of me, I will not buy your app! Can you have the USER choose which one to do? Like in the app's settings...
See, that's the thing. Applications should not be able to annoy the user when the it's not running, no matter what the developer does.

[babyj]

Can someone provide a simple explanation of how push works?

From what I've read, the developer has to send the push to a central Apple server which in turn sends the push to the mobile network the phone is on which in turn delivers it to the phone - basically the same way an sms is handled.

Is that right?

[diamond.g]

Can someone provide a simple explanation of how push works?

From what I've read, the developer has to send the push to a central Apple server which in turn sends the push to the mobile network the phone is on which in turn delivers it to the phone - basically the same way an sms is handled.

Is that right?

Yup that pretty much is it.

[Breckenridge]

Hopefully Apple fixed battery issues. Although I like email push, I don't want to run out of battery midday and risk not receiving simple phone calls.

[scottness]

Well in that case,

To any devs reading this,

If you annoy the heck out of me, I will not buy your app! Can you have the USER choose which one to do? Like in the app's settings...

I'm sure the developers will give you the options. Otherwise no one would buy their annoying apps. Right, developers?

[joeshell383]

http://www.youtube.com/watch?v=auMrN_d_kTo

I hope that Skype will be able to make use of this. Although it will be strange to receive a notification for an incoming call, hit answer, and be redirected to a screen that says "You can only answer calls while connected to Wi-Fi".

[twoodcc]

great news! glad that this is finally getting started

[fuzzhack]

any dev's care to share the video?

[Littleodie914]

This is close but not quite. This is great for users who: (1) have internet on their device, and (2) who are using some type of application that needs to interface with a server.

You're telling me I need to establish all of these systems/servers just to trigger some kind of alarm or alert popup? And to do this there would need to be some kind of unique identifier/account information to maintain whose alarms are whose?

Don't talk about them "waiting to get it right" just yet, because they haven't. :rolleyes:

[DavidLeblond]

You're telling me I need to establish all of these systems/servers just to trigger some kind of alarm or alert popup? And to do this there would need to be some kind of unique identifier/account information to maintain whose alarms are whose?

Exactly. I can't very well put notifications in any of my apps because I don't have a server. Even though notifications would suit several of them very well.

[babyj]

You're telling me I need to establish all of these systems/servers just to trigger some kind of alarm or alert popup? And to do this there would need to be some kind of unique identifier/account information to maintain whose alarms are whose?


How would you send anything to an iPhone without a system / server in place? This requirement has got nothing to do with the way Apple have implemented push, you'd need it no matter what. I haven't checked how you send the notification but I'd imagine you could send it from a basic web server or from your home computer.

As regards the unique identifier, I'd imagine this will just be the Apple device id which some applications already use. Again, no matter what the implementation you'd need some way of identifying the target of the push.

All you've basically done is taken the basic requirements of a push system and tried to turn them in to issue due to the way Apple have implemented it, which has got nothing to do with it. The way Apple are doing it seems pretty efficient to me and I wouldn't be surprised to see others copying it.

[DavidLeblond]

How would you send anything to an iPhone without a system / server in place? This requirement has got nothing to do with the way Apple have implemented push, you'd need it no matter what. I haven't checked how you send the notification but I'd imagine you could send it from a basic web server or from your home computer.

You would have to have a process running on a server to send out a notification. I don't think a home computer would cut it, what if you put it to sleep? No more notifications!

Having to have a notification for an app such as an IM app is no problem, you'll have a server anyway. But lets say I have a timer app that you can set an alarm in. Do I really need to stand up a server to keep track of everyone's alarms so that people can get notified when the app isn't open? Doesn't anyone else find that a little overkill?

[babyj]

But lets say I have a timer app that you can set an alarm in. Do I really need to stand up a server to keep track of everyone's alarms so that people can get notified when the app isn't open? Doesn't anyone else find that a little overkill?

If the alarm's are stored on the iPhone, then you're talking about not being able to run it as a background app which is a different issue.

If the alarm's are stored at your end, then you're talking about push and you'd always need a server of some sort to store, manage and send the alarm's out.

It comes down to where the information triggering the notification is stored. If its on the iPhone then its the lack of background support that is the problem. If its stored outside of the iPhone then you're talking push every single time, which will always require a server.

[Smith288]

This is close but not quite. This is great for users who: (1) have internet on their device, and (2) who are using some type of application that needs to interface with a server.

You're telling me I need to establish all of these systems/servers just to trigger some kind of alarm or alert popup? And to do this there would need to be some kind of unique identifier/account information to maintain whose alarms are whose?

Don't talk about them "waiting to get it right" just yet, because they haven't. :rolleyes:

I wonder if there will be some guy who makes a wholesale notification service you register with them your app info and send them the notifications you want then they handle it for you. I think I can see something like that being EXTREMELY convenient.

[Gokunama]

Wish Apple had allowed push notifications from within the iPhone itself, like for example, when I want to be reminded to do something from a to-do app, but I don't have internet connection at that time I want to be reminded.

[Smith288]

You would have to have a process running on a server to send out a notification. I don't think a home computer would cut it, what if you put it to sleep? No more notifications!

Having to have a notification for an app such as an IM app is no problem, you'll have a server anyway. But lets say I have a timer app that you can set an alarm in. Do I really need to stand up a server to keep track of everyone's alarms so that people can get notified when the app isn't open? Doesn't anyone else find that a little overkill?

I believe the notifications being sent to apple are literally bytes of info. No huge amoung of bandwidth required at all. The problems occur when Apple wants you to check their feedback service and to maintain a list of devices no longer responding to your notifications (they removed your app, its off, cancelled service, etc etc) and you need to remove them from your notification queue. That becomes more of a project.

[iMacoo7]

I think the dev's will make sure the pop ups do not overwhelm our screen... Hopefully;)

[Smith288]

I think the dev's will make sure the pop ups do not overwhelm our screen... Hopefully;)

If a particular app is driving you nuts, you can limit that app's annoying level by going to the settings screen on your iPhone.

[str1f3]

PNS doesn't have to be implemented in the way you describe. It could (and probably will) be as simple as a badge over the app's icon in the home screen. Completely unobtrusive.

The problem with that is you have to go through eleven pages of apps looking for a badge above the icon. The implementation is garbage and it has to be changed. I cannot believe that apple would release it like this. The iPhone is all about ease of use. It will be like hitting a xxx site.

[jhsfosho]

So how soon until I can download these push-enabled apps on my 3.0 touch 1st gen?

[Gokunama]

Hopefully the notifications can be opened again later just in case you were busy and forgot what notifications came in.

[JayMan8081]

Apple keeps making the iPhone platform more and more attractive as they open up more features in the SDK. I'm looking forward to seeing what the developers can come up with!

[mouchoir]

So how soon until I can download these push-enabled apps on my 3.0 touch 1st gen?

I'd expect June when the 3.0 is out of beta and released to the public.
I'm not sure devs are allowed to submit 3.0 apps until then.

[michael.lauden]

I think the dev's will make sure the pop ups do not overwhelm our screen... Hopefully;)

yeah dude. foreel. it happens enough as it is with SMS

[DELLsFan]

Wirelessly posted (iPhone: Mozilla/5.0 (iPhone; U; CPU iPhone OS 2_2_1 like Mac OS X; en-us) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.1 Mobile/5H11 Safari/525.20)

I'm glad that it appears that they will get push notification working soon. I'm also glad they waited to "get it right"

By "get it right", does that imply they've managed to solve their biggest concern: Battery life? So what's the news here? They finally caved, battery-life be damned, or is this smiling face push deal something special that addresses their concern?

[msb65]

Will this also apply to the Ipod Touch?

[apeacock]

What I'm really hoping for is that Apple gives the ability to put an icon in the status icon area - up where the playing icon goes now without the need to jailbreak. Right now you can do this with the jailbroken app statusnotifier and I find it extremely useful - I can just hit the top button to turn the screen on and look at what apps have notifications. There would need to be a way to limit those icons to just a few apps (since there isn't much room), but for stuff like IM/RSS/Mail it would be great.

[iPhoneNYC]

Cool - Push will help alot of apps. I also vote with the person who finds the logo creepy!

[matt.uhs]

The problem with that is you have to go through eleven pages of apps looking for a badge above the icon. The implementation is garbage and it has to be changed. I cannot believe that apple would release it like this. The iPhone is all about ease of use. It will be like hitting a xxx site.


We must remember the search feature that was introduced...

[Smith288]

What I'm really hoping for is that Apple gives the ability to put an icon in the status icon area - up where the playing icon goes now without the need to jailbreak. Right now you can do this with the jailbroken app statusnotifier and I find it extremely useful - I can just hit the top button to turn the screen on and look at what apps have notifications. There would need to be a way to limit those icons to just a few apps (since there isn't much room), but for stuff like IM/RSS/Mail it would be great.

I cant believe they havent done that already for the SMS/MMS and Email. Ridiculous they havent yet.

[Goona]

Ahh only nearly a year late.
So what?

[B2k1977]

See, that's the thing. Applications should not be able to annoy the user when the it's not running, no matter what the developer does.

mmmmm I smell spam via push notification.

[Goona]

http://www.youtube.com/watch?v=auMrN_d_kTo

I hope that Skype will be able to make use of this. Although it will be strange to receive a notification for an incoming call, hit answer, and be redirected to a screen that says "You can only answer calls while connected to Wi-Fi".

Maybe you can only receive calls on Skype on wifi.

[Goona]

The problem with that is you have to go through eleven pages of apps looking for a badge above the icon. The implementation is garbage and it has to be changed. I cannot believe that apple would release it like this. The iPhone is all about ease of use. It will be like hitting a xxx site.

Yeah I'm sure everybody has 11 pages of apps. :rolleyes:

[stagi]

better late than never

[finalcut]

waiting on this. this will be a great update

[TuffLuffJimmy]

So do any developers have their apps working with Push yet?

[CrzyCanuck72]

Can't wait till this is working with facebook and beejive - those are the only two apps I would use it for

[Stella]

The iPhone 'push' technology is a poor substitute for background applications. If Apple offered both Push and background apps, that would be great.

Additionally, isn't the iPhone Push technology soley dependent on Apple? If Apple choses to pull the plug / or choose to do maintenance, thats it - no more Push?

I run multiple background apps on my phone / multi-task - having several apps running at once ( i.e, IM, web browser, e-mail etc ) . Having the background apps running all the time, to be honest, doesn't affect battery life that much.. I'll lose a few hours. Instead of recharging the phone every 3 days, I'll have to recharge it every 2.5 days.

Apple are making excuses and a bit song and dance IMO.

I can only assume there's still technical reasons above 'battery life' for why Apple won't allow background apps. This wouldn't be the first time: initially Apple wouldn't allow users to install native applications - but would only offer crappy online widgets. The 'mobile OSX' just wasn't mature enough.

[jnguyen4]

The iPhone 'push' technology is a poor substitute for background applications. If Apple offered both Push and background apps, that would be great.

Additionally, isn't the iPhone Push technology soley dependent on Apple? If Apple choses to pull the plug / or choose to do maintenance, thats it - no more Push?

I run multiple background apps on my phone / multi-task - having several apps running at once ( i.e, IM, web browser, e-mail etc ) . Having the background apps running all the time, to be honest, doesn't affect battery life that much.. I'll lose a few hours. Instead of recharging the phone every 3 days, I'll have to recharge it every 2.5 days.

Apple are making excuses and a bit song and dance IMO.

I can only assume there's still technical reasons above 'battery life' for why Apple won't allow background apps. This wouldn't be the first time: initially Apple wouldn't allow users to install native applications - but would only offer crappy online widgets. The 'mobile OSX' just wasn't mature enough.

right... ever 3 days?? what phone is that?? i doubt it.

[Matt23]

I agree that Push Notifications are not a good replacement for allowing applications to run the background. For example, when you're talking to someone via the Skype App and you want to look something up on Mobile Safari, you'd have to end your call.

What if you want to have an App that pings a server with the iPhone's current location periodically? You can't, the push information goes only one way.

I hope that push notifications are only the first step. Just like how in the beginning, Apple told developers that if they wanted to develop for the iPhone, they'd have to do it via web apps in Mobile Safari.

[Stewie86]

Who Watches the Watchmen?

Haha, that's exactly what I thought. The "1" is the blood stain. lol

[W1LLk]

Well in that case,

To any devs reading this,

If you annoy the heck out of me, I will not buy your app! Can you have the USER choose which one to do? Like in the app's settings...

Bravo sir, bravo.

[iMacoo7]

Either way we slice this, it will be a benefit for us all. Dev's to end users. Who knows, the effectiveness of the notification might be more of a better feeling than what we are giving it. We will find out what is what when it hits in the final version.

[txr0ckabilly]

http://www.macrumors.com/images/macrumorsthreadlogo.gif (http://www.macrumors.com/2009/04/10/apple-turns-on-push-notification-services-for-developer-testing/)

Apple announced in March that they would finally be delivering the service alongside iPhone 3.0 which is due this summer




oh wow so the third iteration of the iPhone hardware has just been confirmed! :D

i believe you meant iPhone OS 3.0 , this could start a rumor fiasco if left unchecked. ;):cool:

[jbrandonf]

What I'm really hoping for is that Apple gives the ability to put an icon in the status icon area - up where the playing icon goes now without the need to jailbreak. Right now you can do this with the jailbroken app statusnotifier and I find it extremely useful - I can just hit the top button to turn the screen on and look at what apps have notifications. There would need to be a way to limit those icons to just a few apps (since there isn't much room), but for stuff like IM/RSS/Mail it would be great.

Somebody finally brought this up. I do not want notifications popping up on my screen every couple of minutes as that's distracting, but I also don't want to have to scroll through 5 pages of apps to see which ones have a badge on it. A status bar icon (the happy face for apps, and separate mail, SMS, missed call icons for stocks functions) system should be implemented. I can doubletap on the status bar and be brought to a quick launch board where all apps that have notifications are presented. This quick launch screen could also be accessed by swiping up from the springboard.

Does that sound reasonable?

[jbrandonf]

Can't wait till this is working with facebook and beejive - those are the only two apps I would use it for

Meebo will also be releasing a multiple chat client this summer, and while Beejive pleases me in a way that a woman never could I would like to see what Meebo has to offer.

[Emulsion]

Pretty sure that there will be a better way of handling notifications in the next beta release. There's no way they would have you simply leave a badged app on page 8. My guess is they're going to utilize the top black bar like one user said. It makes since. This would let you see what notifications you have at all times. A simple double tap via call on hold, and it should bring you to spotlight with all the apps with notifications. Just a guess. Having it in the next update would make since also because it can't be used now because developers haven't used notifications yet. Just a guess.

[Veri]

So, to keep an IRC conversation going while checking a Youtube video on a normal system I just need to switch to a Safari window and then switch back to the IRC client.

But with this stupid push notification system, when I move to the Youtube video:
1. My iPhone disconnects from IRC;
2. Some Third Party service provides a bot that logs back on as me and caches messages (assuming the Third Party IP range isn't banned entirely from the server thanks to too many weirdly behaving simultaneous clients);
3. When I get messages they're delivered to my iPhone by some awfully intrusive notification rather than something simple like a scrolling status bar;
4. I go back to my IRC client;
5. The Third Party service logs itself out and my iPhone logs back in.

Lame lame lame lame lame.

[scottness]

I agree that Push Notifications are not a good replacement for allowing applications to run the background. For example, when you're talking to someone via the Skype App and you want to look something up on Mobile Safari, you'd have to end your call.

What if you want to have an App that pings a server with the iPhone's current location periodically? You can't, the push information goes only one way.

I hope that push notifications are only the first step. Just like how in the beginning, Apple told developers that if they wanted to develop for the iPhone, they'd have to do it via web apps in Mobile Safari.

Exactly. I don't care so much for push... Background Apps can't be replaced. :(

[macfan881]

its funny all of you wanted apple to come out with push and they did now everyone is complaining up a storm about it i come to reliaze 90 percent of the fanboys can never be happy :rolleyes: I for one will love 3.0 once it is uploaded to my ipod touch

Edit: for those complaing they want backround apps just jail break and install backrounder best thing i have on my ipod right now

[Jimmetry]

Please provide me with a waaaambulance.

Lame lame lame lame lame.

You're missing the point. An iPhone IRC app should be connecting you from a third party server on the internet. Even WITHOUT Push this is necessary because cellular connections are NOT that reliable. Your phone, with its unique identifier, simply synchronises with the server that is holding your actual messages.

Push can be a simple audio notification when someone says your name. OH NO, HOW INTRUSIVE. As intrusive as, oh I dunno, any IRC client on a computer. And just like a computer, any decent app will allow you to turn features on and off. There are plenty of ****** apps in the store at the moment, and of course ****** Push implementation is no exception. If the app is bad, don't buy it. Easy. Quit your bitching.

And on that note... Apple REVIEWS ALL APPS. That means apps that spam crap all the time won't be accepted. This isn't a free market like the Android. Oh wait, they deny apps too if the cell network tells them too :rolleyes: They just don't have a junk filter.


Someone also said "What if Apple pulls the plug?"... the chances of that are about the same as them pulling the plug on the app store. Doesn't happen.


Push is a good solution. Yes, it doesn't suit everything... AirSharing, for example, still needs to have the ability to run in the background. But by releasing Push NOW you prevent a bombardment of ****** apps that expect a constant connection when it's absolutely unnecessary. What they should do is release an API for building 'Services' in a few months, with VERY strict guidelines as to what will be allowed. If it can be done with Push, a service with the same functionality should be denied.

Why do people always do this? No matter what the product is, you all flame without thinking about what you're saying. Just let it be released and learn the culture before starting a war. :cool:

[leandromp]

You're missing the point. An iPhone IRC app should be connecting you from a third party server on the internet. Even WITHOUT Push this is necessary because cellular connections are NOT that reliable. Your phone, with its unique identifier, simply synchronises with the server that is holding your actual messages.

Push can be a simple audio notification when someone says your name. OH NO, HOW INTRUSIVE. As intrusive as, oh I dunno, any IRC client on a computer. And just like a computer, any decent app will allow you to turn features on and off. There are plenty of ****** apps in the store at the moment, and of course ****** Push implementation is no exception. If the app is bad, don't buy it. Easy. Quit your bitching.

And on that note... Apple REVIEWS ALL APPS. That means apps that spam crap all the time won't be accepted. This isn't a free market like the Android. Oh wait, they deny apps too if the cell network tells them too :rolleyes: They just don't have a junk filter.


Someone also said "What if Apple pulls the plug?"... the chances of that are about the same as them pulling the plug on the app store. Doesn't happen.


Push is a good solution. Yes, it doesn't suit everything... AirSharing, for example, still needs to have the ability to run in the background. But by releasing Push NOW you prevent a bombardment of ****** apps that expect a constant connection when it's absolutely unnecessary. What they should do is release an API for building 'Services' in a few months, with VERY strict guidelines as to what will be allowed. If it can be done with Push, a service with the same functionality should be denied.

Why do people always do this? No matter what the product is, you all flame without thinking about what you're saying. Just let it be released and learn the culture before starting a war. :cool:


AMEN my friend, AMEN!!
Ur answer is so good, im about to cry right now.
lmao.

[kkaragitz]

I honestly believe services will eventually come. It's just a matter of time. Maybe iPhone OS 4.0 ;)

[Veri]

An iPhone IRC app should be connecting you from a third party server on the internet. Even WITHOUT Push this is necessary because cellular connections are NOT that reliable.
So what? TCP provides the reliability, and IRC servers are quite happy to wait a minute or thirty before ping timeouting you, depending on configuration. Even young whipper-snappers should remember tying up the family 'phone line with their unspectacular modem connection, and the Interweb was designed to run over media far less reliable than that.

Your phone, with its unique identifier, simply synchronises with the server that is holding your actual messages.
Great, so we have two more points of lag and failure - the third party server and Apple's push notification servers. And we haven't even got on to the privacy implications.

Push can be a simple audio notification when someone says your name. OH NO, HOW INTRUSIVE.
Audio notification is something I want when I'm not using the equipment and I'm expecting something important. Otherwise I want something visual but non-modal, a la Growl. If something like that is provided, then strike off this complaint.

And on that note... Apple REVIEWS ALL APPS. That means apps that spam crap all the time won't be accepted. This isn't a free market like the Android. Oh wait, they deny apps too if the cell network tells them too :rolleyes: They just don't have a junk filter.
This straw-filled gentleman betrays your motives. I want Apple to produce better software, and I don't think Apple always knows best. What about you?

Someone also said "What if Apple pulls the plug?"... the chances of that are about the same as them pulling the plug on the app store.
If you think the platform will be profitable until the end of days, you're insane: when the profitability stops for Apple, they'll stop supporting the App Store. Just as Apple pulled the plug on third party developers in the late '90s: in that case, it was of Mac-compatible hardware, which became profitable for everyone but Apple.

But by releasing Push NOW you prevent a bombardment of ****** apps that expect a constant connection when it's absolutely unnecessary.
Dude, there is nothing wrong with a constant connection. You can keep a TCP/IP connection open for a week if you want and exchange no data.

What they should do is release an API for building 'Services' in a few months, with VERY strict guidelines as to what will be allowed.
Please, not another annoying buzzword-compliant lock-in framework.

Why do people always do this? No matter what the product is, you all flame without thinking about what you're saying. Just let it be released and learn the culture before starting a war.
Because there are only so many years one can take of marketing and their neophyte engineer lackeys fixing what's not broken before one gets bored and moves to another field. I thought I might spend my life in software engineering, but now I'm a mathematician-in-training - it's so refreshingly bull-free.

Happy Easter!

[mikeinternet]

Still no link to the developers video?

[kdarling]

If the alarm's are stored on the iPhone, then you're talking about not being able to run it as a background app which is a different issue.

Apple has made it the same issue, by bluntly claiming that push notification removes the need for background apps. (Of course, they ignored their own background apps.)

Other OS's have had push notification for years. Most especially Java on phones, which has had a push registry since 2002. But it also had auto-start on notification or timed alarm, which adds to its usefulness.

Reminder, location based, and background music apps need real multi-tasking... not user initiated upon a remote server notification.

As for tasks that usually require network activity, yes a few of them fit the notification model. Others, such as background video downloads or Pandora, don't. Moreover, it's quite a burden on a developer to create a server app, pay for its existence, and maintain its user database, just to save some battery.

[queshy]

Haha, finally. It's almost a year late.

[Stella]

right... ever 3 days?? what phone is that?? i doubt it.

Smartphones:
Blackberrys ( certain models ) can manage 3 days
Some Nokia E-Series can manage 3 days
My old SE P900 could manage easily 3 days

I hope your not trying to say because the iPhone can't manage 3 days then no other (smart)phone can't.

[jbrandonf]

Smartphones:
Blackberrys ( certain models ) can manage 3 days
Some Nokia E-Series can manage 3 days
My old SE P900 could manage easily 3 days

I hope your not trying to say because the iPhone can't manage 3 days then no other (smart)phone can't.

I really hope there are smartphones out there that can manage 3 days, but what 3G smartphones out there can run for three days with all those programs running in the background like the OP described? It sounded like quite the exaggeration.

[tokevino]

I really hope there are smartphones out there that can manage 3 days, but what 3G smartphones out there can run for three days with all those programs running in the background like the OP described? It sounded like quite the exaggeration.

Besides you do lose quite a bit CPU cycles. The Palm Pre video is a good example. I am waiting to see how Palm Pre's real-use battery life is going to be when the actual product is released to public, and how does Pre handle the background processes - especially when WM is already a pain in the a%$.

The "Pre" is an awful name IMO, but if Palm can get the battery life, save the cpu cycles, and do background processes effectively at the same time, I say Apple should worry a little bit then. But based on the technologies we see as of today, Pre doesn't look good, as Apple made it clear: it was easier to do the background processes than the push notification detour if battery life and cpu cycles are not issues.

[kas23]

As for tasks that usually require network activity, yes a few of them fit the notification model. Others, such as background video downloads or Pandora, don't. Moreover, it's quite a burden on a developer to create a server app, pay for its existence, and maintain its user database, just to save some battery.

Agreed. During the keynote, Apple made it sound as if PUSH was going to totally eliminate the need for background running apps. However, apps like Pandora are not going to benefit from PUSH (not unless they are going to constantly be pushing songs to your iPhone). What would be a good compromise is to allow 3 or so apps at a time running in the background, in addition to PUSH.

You also make a good point about developers' resources. In oder for a Todo app to benefit from PUSH, the developer will have to have a server that knows your Todo list. No longer can a developer just produce an app and release it the App Store. Now, if they want to take advantage of Apple's PUSH, they're going to have to keep a database of your Todo's and set up a server to send them to Apple. We're probably going to see a "survival of the fittest" here and amateur developers are likely going to see the demise of their apps (if an alternative app exists that psuhes your content). Sort of like how family owned stores were put out of business by Wal-Mart. But, hey, maybe this will be a good thing for the App Store.

[Veri]

What would be a good compromise is to allow 3 or so apps at a time running in the background, in addition to PUSH.
What would be good is for modern consumer operating systems to have less primitive scheduling algorithms. The literature has been discussing methods of prioritisation since the '60s. Your goals are simple:

1. Don't let background apps harm the UI experience of the foreground apps _at all_, by giving them little to zero quantum when a UI response/update is required;

2. Use flow control to improve network performance of interactive applications;

3. Don't let background apps suck up too much total CPU power over time. Publish recommended limits and the throttling algorithm used on misbehaving processes. I still don't understand why modern consumer operating systems don't react more gracefully to that runaway 99% process: why isn't it customary to inform your OS if you're about to use a huge amount of resources, so if you're doing it otherwise it can be assumed you're broken and need aborting?

The consumer scheduling method prevalent in the late '80s through to mid-'90s was cooperative multitasking, of course. Now I'm certainly not suggesting that across the OS, but imagine as a first approximation the foreground app never relinquishing control to other apps (ignoring necessary background daemons) except when it's idling. When there's a UI event, the foreground app immediately gets control back.

[scottness]

I'd be happy with allowing 2 background apps + push... For now.

[zenjabba]

Instead of recharging the phone every 3 days, I'll have to recharge it every 2.5 days.



I was happy to read upto then, but 2.5 days, every iphone I've seen will last 7 hours with WiFi turned off, 2.5 days, just aint possible unless its in airplane mode.

[Howardchief]

You're missing the point. An iPhone IRC app should be connecting you from a third party server on the internet. Even WITHOUT Push this is necessary because cellular connections are NOT that reliable. Your phone, with its unique identifier, simply synchronises with the server that is holding your actual messages.

Push can be a simple audio notification when someone says your name. OH NO, HOW INTRUSIVE. As intrusive as, oh I dunno, any IRC client on a computer. And just like a computer, any decent app will allow you to turn features on and off. There are plenty of ****** apps in the store at the moment, and of course ****** Push implementation is no exception. If the app is bad, don't buy it. Easy. Quit your bitching.

And on that note... Apple REVIEWS ALL APPS. That means apps that spam crap all the time won't be accepted. This isn't a free market like the Android. Oh wait, they deny apps too if the cell network tells them too :rolleyes: They just don't have a junk filter.


Someone also said "What if Apple pulls the plug?"... the chances of that are about the same as them pulling the plug on the app store. Doesn't happen.


Push is a good solution. Yes, it doesn't suit everything... AirSharing, for example, still needs to have the ability to run in the background. But by releasing Push NOW you prevent a bombardment of ****** apps that expect a constant connection when it's absolutely unnecessary. What they should do is release an API for building 'Services' in a few months, with VERY strict guidelines as to what will be allowed. If it can be done with Push, a service with the same functionality should be denied.

Why do people always do this? No matter what the product is, you all flame without thinking about what you're saying. Just let it be released and learn the culture before starting a war. :cool:

You're the man.

[Stella]

I really hope there are smartphones out there that can manage 3 days, but what 3G smartphones out there can run for three days with all those programs running in the background like the OP described? It sounded like quite the exaggeration.

I was happy to read upto then, but 2.5 days, every iphone I've seen will last 7 hours with WiFi turned off, 2.5 days, just aint possible unless its in airplane mode.

I have to clarify, that my experience of 3 days+ isn't with 3G turned on nor having constant internet connection. The internet connection is turned on as required. Bluetooth is always on. ( Why have your phone connected constantly to internet if you don't require it?)

Yes, using 3G will kill your battery life, no doubt about it.

Having said that I still stand by saying that it is still possible to get 3 days battery life on other smartphones ( and not just in offline / airplane mode!!).

Like I said, don't compare other smartphones battery life to that of the iPhone. The iPhone battery isn't that great.

[QuarterSwede]

By "get it right", does that imply they've managed to solve their biggest concern: Battery life? So what's the news here? They finally caved, battery-life be damned, or is this smiling face push deal something special that addresses their concern?
No, what happened is that they were surprised to see the amount of devs interested in PNS. They had to do a total PNS rewrite to deal with massive amounts of people who will be using the system. That's why it's so late.

I was happy to read upto then, but 2.5 days, every iphone I've seen will last 7 hours with WiFi turned off, 2.5 days, just aint possible unless its in airplane mode.
And that's underestimating it. My iPhone easily lasts 24 hours with WiFi on (I'm on EDGE not 3G) and with normal usage. 3G is the biggest battery hog by far. However, I don't buy the 3 days bull either. You can definitely get 3 days if you don't use it much for sure. What would be the point of that though?

[Stella]

However, I don't buy the 3 days bull either. You can definitely get 3 days if you don't use it much for sure. What would be the point of that though?
iPhone isn't a gold standard!

Get out of the mentality of "if iPhone can't do it then no other phone can"!

[jbrandonf]

I have to clarify, that my experience of 3 days+ isn't with 3G turned on nor having constant internet connection. The internet connection is turned on as required. Bluetooth is always on. ( Why have your phone connected constantly to internet if you don't require it?)

Yes, using 3G will kill your battery life, no doubt about it.

Having said that I still stand by saying that it is still possible to get 3 days battery life on other smartphones ( and not just in offline / airplane mode!!).

Like I said, don't compare other smartphones battery life to that of the iPhone. The iPhone battery isn't that great.

I still don't know what phone this is. Turning data on and off doesn't work for me. Why? Well for one I have my emails pushed directly to me, not possible with data off, and if I want to look something up quickly, or check Facebook quickly, or check a pending IM, I'd have to wait 6-7 seconds at least for data to connect.

iPhone isn't a gold standard!

Get out of the mentality of "if iPhone can't do it then no other phone can"!

QuaterSwede said that quote..not I.

Based on reviews for other cell phones, it seems they all compare them to the iPhone. Wonder why..

Actually the iPhone has decent battery life..better than other 3G smartphones. I charge it once a day. And I do a lot of browsing. The problem isn't that mentality but with money as tight as it is for me, I'd like to feel like I'm getting the best bang for my buck..My software is kept up to date with almost quarterly firmware updates. I'd gladly get a Touch Diamond or a G1..problem I have with them is that battery sucks on TD and it doesn't have a glass screen, and the G1 is bulky and a hard qwerty keyboard isn't necessary for me. (I'd consider switching to Palm's WebOS if it came in a GSM version with no keyboard..)

[scottness]

Has anybody had any experience with Push since it's been turned on? I'd like to know where the devs are on this.

[RaZaK]

Is Apple trying to be the next RIM with the PNS? :D. How long before we see CNN reporting on Apple's PNS servers being down due to a poorly planned upgrade? LOL

[CharBroiled20s]

Who Watches the Watchmen?

Dr. Manhattan & his hefty blue swinging.......ahem... would someone get that guy a bathing suit!

:p

I'm so geek'd over all the new features & speculations!
Push Notifications
MMS
Landscape everything
Copy/Paste
Global Search
H2DP
Turn-By-Turn Navi

A new iPhone with:
a better camera (perhaps 2 cams, one forward facing?)
a magnetometer
video recording
802.11n
native tethering support
a processor speed bump
better battery life!

Did I forget anything?!

I'm greedy & impatient.... Is it July yet?

[deconstruct60]

What would be good is for modern consumer operating systems to have less primitive scheduling algorithms. The literature has been discussing methods of prioritisation since the '60s. Your goals are simple:

1. Don't let background apps harm the UI experience of the foreground apps _at all_, by giving them little to zero quantum when a UI response/update is required;


That research literature doesn't mention anything about starvation?
What is the utility of giving background tasks zero quantums for an extended period of time? How is the OS scheduler suppose to know what is OK to starve one to death. And if it is OK to starve an background process to death why is it running in the first place? Do you alert the user you are about to starve it?

Second, once you allow unbounded background processes they will compete against each other in addition to with the foreground app. It is not just a one foreground and one background problem.

iPhone OS can simply borrow from the unix priority/nice mechanism that Mac OS X uses (if it already doesn't). There is little evidence that foreground apps not getting enough cycles is problem for iPhone OS. (the CPU is severly underpowered) Everything Apple has talked about in the design rational for turning off apps has been about battery life. Not that their selected ARM core is underpowered.

Finally, you say "foreground apps". Well if you start enough of those then you eventually run out of resources. Or you want the priority to follow the UI focus? (I'll dive deeper into adding lots of inserts into the scheduler and multithreaded apps later ). And it isn't them consuming UI events that is really going to kill off performance and/or resource consumption. Unless adding multiple users you are limited by how many events a user can generate. No single human is going to overwhelm a modern CPU running a managable workload.




2. Use flow control to improve network performance of interactive applications;


Is it really going to improve performance? It is one thing to run traffic shaping on a external router. All the overhead in that case get sucked up on that external CPU. Likewise, if you have "too many" cores inside your box and you are plugged into the wall for power, you can throw the overhead at these under leveraged resources.

Does that even remotely sound like the normal context of an iPhone?

Furthermore, traffic shaping is usually on protocol/pattern. You are talking having to track not just what is tracked now, but also ports and the process id that each port is using. Then your shaper has to factor yet another dimension into its shaping process. Sure it could be done, but how much overhead have you added?

Again.. where is the evidence this is primarily a bandwidth problem?
Lots of home network routers use ARM cores very similar to the one in the iPhone. They can do traffic shaping and what not also. However, they are also plugged in.



3. Don't let background apps suck up too much total CPU power over time. Publish recommended limits and the throttling algorithm used on misbehaving processes. I still don't understand why modern consumer operating systems don't react more gracefully to that runaway 99% process: why isn't it customary to inform your OS if you're about to use a huge amount of resources, so if you're doing it otherwise it can be assumed you're broken and need aborting?



A couple of factors to consider:


And if low CPU cycles but turn on the radio full blast for an hour?
Or low CPU cycles and burns lots of energy rewriting flash cells?

It doesn't have to be a runaway fork bomb that is burning up the power. It is not solely a "misbehaving program" problem. If there 5 programs all chirping away at moderate rate the internet over a 3G network that is going to be a significant power drain. 6, 7, or 8 of them will be even more. It isn't the individual programs managing but the aggregate power. That is yet another data structure for your scheduler to count and manage. You'd have to be able to do accurate blame assignment for all the downstream energy consumption. Don't really even do that for CPU consumption. The scheduler hands out the quantums in the first place. Furthermore you going to have to insert lots more data into your kernel schedule data structures. That requires getting locks. While you structures are locked up the scheduler can't do its job of doling out new quantums because it is not much more busier getting updates.


Fourth what about zombies? There could be mostly comatose processes but they sip resources over a long time.

Why isn't it customary? One, if you inform the OS about every loop construct you are about to enter how many more kernel traps is your program going to take now? Is that kernel trap going to prematurely end your quantum ? ( what if there are 5 other programs all insisting they are more important than you. ) Aren't these kernel costing you overhead. In normal circumstances how much more energy/time are you burning up

The pre declaration makes sense for batch jobs. Regularly run and fairly predictable jobs. For anything that depends upon either user input and/or shared resources how is the code doing to do a accurate estimate?



Never mind that you now need a GUI application to show folks what is running on their phone. You want the average joe blow phone user to manage deamons. Seriously?


Also just how huge is your scheduler? The more complex you make it and the more time it takes to get in and get out of it.





The consumer scheduling method prevalent in the late '80s through to mid-'90s was cooperative multitasking, of course. Now I'm certainly not suggesting that across the OS, but imagine as a first approximation the foreground app never relinquishing control to other apps (ignoring necessary background daemons) except when it's idling. When there's a UI event, the foreground app immediately gets control back.

First, the kernel is further in front of the line than the foreground app. It has to get the UI event that is already prioritized ahead of all of the apps. The notion that the event is not caught and handled immediately isn't true now. If the foreground app is paused on a "wait next event" kernel trap it will get put on the "ready to run" queue and get the next quantum it is priority allows it to get.

Second, your ignoring multithreaded applications. One thread in an app could be doing a "Wait next event", but other threads could be off doing other work. A app doesn't have to idle just because it is waiting on UI events. For it to be idle all the threads would have to join and declare they all had nothing to do. (for example on a game even if the user doesn't do anything they could be competing with objects in the game. Those objects in the game aren't going to stop just because the user isn't doing anything. )


The current iPhone application approach now is somewhat a form of cooperative mutlitasking now. When you are in foreground you run. When you go background you turn yourself up. The emphasis is on startup/shutdown store/recovery state.


P.S. another reason is security. One reason folks don't want to drop background worker drones onto the iPhone is that you can't have installable background worker drones. Your virus or trojan would only run when the user ran it explicitly.

[deconstruct60]

Agreed. During the keynote, Apple made it sound as if PUSH was going to totally eliminate the need for background running apps. However, apps like Pandora are not going to benefit from PUSH (not unless they are going to constantly be pushing songs to your iPhone). What would be a good compromise is to allow 3 or so apps at a time running in the background, in addition to PUSH.


Apple's service is to push small notification messages. It is basically an alert to bring some application into the foreground ( in general. ). It is not a bulk file transfer service.

Running a radio isn't a "background" app. What some folks seem to advocating is running two (or more applications at a time). That is questionable with such a small screen.







You also make a good point about developers' resources. In oder for a Todo app to benefit from PUSH, the developer will have to have a server that knows your Todo list.


If talking about an alarm clock notification. Can't do that with the current Alarm clock (or its API). Set an alarm entry that says "Start application xxxx now for some breifly explained reason". There is zero reason to use PUSH for that.

Apple isn't positioning this as a way to run background apps. They are positioning it as a service that can tell you when to wake up an app when there is some external event. If the events are on the iPhone/iPhone there is now need to externally drive them. But that still won't get you a background service.





No longer can a developer just produce an app and release it the App Store. Now, if they want to take advantage of Apple's PUSH, they're going to have to keep a database of your Todo's and set up a server to send them to Apple. We're probably going to see a "survival of the fittest" here and amateur developers are likely going to see the demise of their apps (if an alternative app exists that psuhes your content).

If developers need better API to an alarm clock notifications then ask for it. It has to be there because the iPhone has an alarm clock. Posting an event entry though doesn't mean your app has to be running in the background. Your trying to build the alarm clock into your app when it already exists outside your app.

Also don't really buy into the background download video thing and just download the video went matched with home/work computer. If you are in a location with crappy bandwidth you don't want to slow that process down by competing for resources. It is a bit restrictive, but it is a phone/ipod... not a general use computer.

[Diseal3]

Nobody mentioned privacy, if my information is being jumbled around on 5000 different server's theres bound to be a exploit somewhere. I highly doubt each developer is going to put any type of encryption on there server's due to load it takes to constantly en/decrypt information etc. If my information gets lost somewhere or i'm now a victim of identity theft I'de be one unhappy fellow, then who get sued? Apple or the Developer? Apple must have SOME plan for this.. if not, there jumping out a airplane 15000 feet over ocean without a parachute and diving gear.

[scottness]

What some folks seem to advocating is running two (or more applications at a time). That is questionable with such a small screen.



Not really. I want to talk to clients on Skype while checking my calendar, mail, or looking at a PDF or maps. Push won't do this. This is huge for productivity. I don't care about radio--it won't help me get work done on the road. The items I mentioned will.

[Slayter]

To me, the PUSH notification is not the best solution at all.
Let´s say in IM is good idea, but how about radio stream?
Secondly, I hope, that there will be an option to set it in all apps differently.
in some apps only badge, in others popup window.

But I still dont think, that apple is right about battery usage. A use backgrounder with one or two backround apps(usually for a limited time) and battery life is not that bad as the say, and solution to have one or two apps in background is allways better.

With new model-with better RAM, better battery, ...
PALM pre is able to have BG, why an iPhone isn´t?
and how about capacity of apple push servers? if millions of users will for every app use this service, I would preffer shorter battery life, then situation, that the push service will not be runnig due to data overload

[scottness]

To me, the PUSH notification is not the best solution at all.
Let´s say in IM is good idea, but how about radio stream?
Secondly, I hope, that there will be an option to set it in all apps differently.
in some apps only badge, in others popup window.

But I still dont think, that apple is right about battery usage. A use backgrounder with one or two backround apps(usually for a limited time) and battery life is not that bad as the say, and solution to have one or two apps in background is allways better.

With new model-with better RAM, better battery, ...
PALM pre is able to have BG, why an iPhone isn´t?
and how about capacity of apple push servers? if millions of users will for every app use this service, I would preffer shorter battery life, then situation, that the push service will not be runnig due to data overload

I agree. Push is better for some things, but it's totally useless in others. We need background apps for this to be a worthwhile upgrade. I can't justify another purchase otherwise. Not for now anyway.

[Veri]

What is the utility of giving background tasks zero quantums for an extended period of time?
Unless your foreground process wants 100% CPU for an extended period of time, why would this be contemplated? And, if this is required - say, for an advanced game - then sometimes my "first approximation" won't cut it, and we need to allocate some proportion of resource usage to background processes. For a second non-profiled approximation, let's allow the foreground process to be guaranteed up to 80% CPU time, but no more, on a system with busy background processes. I say "sometimes" because there are tasks that are happy waiting until the system is idle.

How is the OS scheduler suppose to know what is OK to starve one to death.
In any final implementation our usual option is not to starve to death but to reduce CPU time/bandwidth/etc allocated to the app.

Considering this option, your question becomes, "How can a process guarantee a sufficient amount of resource x per time unit t?" it might ask for it, and be granted it in the competition among background tasks. For example, with my 80% second approximation a request for 5% CPU might mean guaranteed minimum 1%, but usually 5%.

And if it is OK to starve an background process to death why is it running in the first place?
But, you're right, something needs to be done about, say, those 50 processes you've launched which each would like to consume 5%. When a task can no longer be given what it has explicitly asked for, or accounting data shows that it's always being pre-empted because it's using its maximum default allocation, you can notify that task about where it's over-consuming. This gives it the chance to degrade gracefully in a way it knows best (e.g. if you're running a P2P client, seed to fewer people); if it does not adjust its behaviour, or if some resource is so low (e.g. memory) that it is imperative that some processes exit, then after optional further warnings, you demand that it gracefully shut down.

A task can describe its purpose to indicate to the system whether it's appropriate for it to be targeted early in the throttling / quitting procedure. For example, a word processor which might have high memory usage has no problem being quitted and restarted, so it can announce itself as happy to be the first to go. A P2P client can indicate that it normally has heavy requirements but be happy to gracefully reduce its consumption. A chat client (without offline messaging), which in fact spends most of its time just select()ing in the background anyhow, would be within its rights to ask to be the last to die.

Do you alert the user you are about to starve it?
If you're killing a process, such as the chat client above, the death of which will actually make a difference to the user, then yes, you need to tell the user. If you can't reasonably do 2 things at once on the hardware, such as real-time voice recording and encoding while playing some OpenGL masterpiece, then yes, you notify the user - as early as possible, so you don't get the usual desktop experience of a pointless combination of stuttering audio and jerky gameplay.

But mostly you'll just be gracefully degrading performance of background apps or quitting apps which will re-open in exactly the same state as before, and the user need not know this.

Everything Apple has talked about in the design rational for turning off apps has been about battery life.
OTOH, "need to conserve the battery" might be modelled as a resource-hungry process. But what is it about background apps that Apple thinks is going to take up so much battery? They're mostly not touching the UI or the USB, so that leaves the CPU and the radios. The average ARM CPU runs a few hours at 100% load on four AAA cells, and the average background process is likely not CPU-bound (even if CPU were a problem, you could throttle to a nice slow clock)... so my stab in the dark is that, if Apple were telling the truth, they would be worrying about network usage.

Of course, if the background app is one that does a lot of network transfer anyway, then that's the user's business. This leaves the case of, say, a backgrounded chat client, which pings the server every so often (or vice versa), whereas a push scenario would start with a custom notification event Y. So is it that a ping requires either some data connection to be maintained across the cell network, or the connection to be brought up and torn down at each ping? whereas to send Y can be done in a different manner across the cellular network (i) quickly; (ii) without requiring high power to the radio between Ys. Do GPRS/3G/etc connections really not have an idle mode which only requires occasional keep-alives and allows the radios to stay in low power?

And it isn't them consuming UI events that is really going to kill off performance and/or resource consumption.
What does that mean? Using any modern desktop under heavy load confirms that interactive response almost always suffers. Using, say, certain builds of BeOS or QNX confirms that it shouldn't have to.

It is one thing to run traffic shaping on a external router. All the overhead in that case get sucked up on that external CPU.
Nothing you have told me about traffic shaping suggests that allocating bandwidth appropriately among half a dozen processes is going to be resource intensive.

Does that even remotely sound like the normal context of an iPhone?
Absolutely. A typical power-user iPhone might run a voice app, IM app, web app and downloader simultaneously. The voice must not degrade at all, we don't want the IM/web app to lag, and the downloader can wait on everything. Request priorities; shape!

And if low CPU cycles but turn on the radio full blast for an hour? Or low CPU cycles and burns lots of energy rewriting flash cells?
These are just more resources to be rationed.

chirping away at moderate rate the internet over a 3G network
Why are you "chirping away at moderate rate" by being continuously connected at full power to a high speed, power-hungry network?

going to have to insert lots more data into your kernel schedule data structures. That requires getting locks.
Lots more? Locks? Why can't each thread simply have a number incremented by the scheduler when its turn is over? Similar accounting figures reflect network, etc access. A separate kernel accounting process is responsible at regular intervals, and when the scheduler feels overworked, for collecting all this data, sorting by process, and changing priorities or instructing processes to change their behaviour. Maybe for some data it's more efficient to lock and pool by process/system from the start - a fine-grained lock that's typically only needed for half a dozen instructions isn't hugely expensive!

Why isn't it customary? One, if you inform the OS about every loop construct you are about to enter how many more kernel traps is your program going to take now?
Why the hyperbole? If Photoshop is about to convert a 100MB image, or an unzipper about to unzip a 500MB file, they know they're about to do a lot of CPU/disk/memory work. Profiling allows typical resource requirements as a function of input size to be examined during testing, and this information can be embedded in the release. This sort of information can be collected dynamically, though I'm sure you'd prefer to switch that off for your end users.

In normal circumstances how much more energy/time are you burning up
In answer to this question in general - profile! Of course you're going to get some overhead, just as you get overhead for choosing ObjC/Cocoa over straight C. You're asking questions as if none of this sort of thing has been implemented before, on operating systems over two decades old running on hardware less powerful than what you find in your pocket (hello, pile of VAXstations in the corner!).

Never mind that you now need a GUI application to show folks what is running on their phone. You want the average joe blow phone user to manage deamons. Seriously?
No you don't - see above. One of the things Apple got right in all of this was to mock the WinCE task manager. But instead of observing that they'd just discovered a problem with operating system resource allocation, they decided that the OS was fine and that it was time to bolt on some new nonsense.

First, the kernel is further in front of the line than the foreground app. It has to get the UI event that is already prioritized ahead of all of the apps. The notion that the event is not caught and handled immediately isn't true now.
But handling a UI event usually requires some processing to provide an immediate UI response. It's that sort of thing that gets pre-empted when the average system is under high load. This is why I can shake a desktop window around the screen hopelessly but it won't redraw for 10 seconds.

for example on a game even if the user doesn't do anything they could be competing with objects in the game. Those objects in the game aren't going to stop just because the user isn't doing anything.
Idleness happens on a centisecond scale though. If it takes me 10ms each to update the screen 20 times per second, while worker threads update object state 30 times a second each time taking 10ms, I still have a 47% idle machine, even allowing for 5% scheduler overheads. If I'm writing my game with the aim of maximising performance by using 100% CPU, well, the scheduler can just pretend to the app that hardware is 20% less powerful - if this is going to destroy performance, the programmer is making an unusual level of assumptions about precise hardware specs.

P.S. another reason is security. One reason folks don't want to drop background worker drones onto the iPhone is that you can't have installable background worker drones. Your virus or trojan would only run when the user ran it explicitly.
Sorry, this is a complete red herring. If you're writing malware and managing to sneak it onto the App Store then Apple telling you not to write background apps is not going to ensure that you create an app that only behaves maliciously in the foreground.

Thanks for the interesting response. I need to go AFK, so I may not read reply.

[Aqueus]

I'd be happy with allowing 2 background apps + push... For now.

2nd that.. as someone else said maybe come 4.0