Apple seeds developer tools for background-conscious iPhone apps
Apple has equipped some of its developers with the tools needed to begin authoring iPhone applications that can receive data over the internet, like instant messages, even when they're not running.
The capability to produce these applications, sometimes called background apps, has been atop the wish lists of iPhone developers, mainly because Apple prevents the iPhone from running more than one application at a time.
That means that an instant message conversation in AOL's free AIM app for the iPhone would abruptly terminate should a user receive a phone call. The user wouldn't receive any new incoming messages until the phone call was over and the AIM application was relaunched. The same would happen if a user clicked on a web link sent via instant message, triggering the Safari app to launch and the AIM app to quit.
Apple's argument against traditional background-capable applications is a sound one, and one that's in the best interest of iPhone users. During the company's recent developers conference, iPhone chief Scott Forstall noted that implementations of background applications on rival mobile operating systems are largely flawed in that they lead users to believe that they've quit applications when those apps remain open.
This in turn eats at battery life, where the iPhone 3G is already limited by power-hungry 3G and location services, and also weighs on processor performance with each additional application that continues to run as a background process.
To solve this problem, Forstall said Apple was developing an alternative to background applications known as a "Push Notification Service" that developers could tap through a series of APIs, or easy to use programming functions, beginning in September. Instead of allowing potentially dozens of third party services to simultaneously access an iPhone directly, the push service would funnel all transmissions from developers' servers through a central Apple server, which would then relay the data to iPhones through a single persistent and well-managed background connection.
Apple's overview of its Push Notivation Service.
Through this technique, Forstall said developers can push badges to icons (like the email count indicator seen on the iPhone's Mail icon), notification sounds, or pop-up text alerts like those that currently appear when an iPhone receives a text message. This management system was also developed to scale easily with larger apps, the exec said.
The first beta release of iPhone Software 2.1 last week whet the appetite of iPhone developers waiting on the push capabilities when it included some references to the feature. However, a second beta that arrived last night finally includes a rough implementation of the push services API, according to MacRumors.
"This is the second beta of the iPhone SDK targeting iPhone OS 2.1, including bug fixes to iPhone OS as well as an early implementation of the Apple Push Notification Service API," Apple said. "This API is not yet integrated with a live push server."
Only a select group developers are reported to have received the latest beta, which as Apple noted, isn't fully functional. Still, the iPhone maker has two months left to meet its self-imposed deadline to roll out Push Notification Service tools to its broader developer community. If it makes good on its promise, the first background-conscious iPhone applications should start cropping up on the App Store later this fall.
The capability to produce these applications, sometimes called background apps, has been atop the wish lists of iPhone developers, mainly because Apple prevents the iPhone from running more than one application at a time.
That means that an instant message conversation in AOL's free AIM app for the iPhone would abruptly terminate should a user receive a phone call. The user wouldn't receive any new incoming messages until the phone call was over and the AIM application was relaunched. The same would happen if a user clicked on a web link sent via instant message, triggering the Safari app to launch and the AIM app to quit.
Apple's argument against traditional background-capable applications is a sound one, and one that's in the best interest of iPhone users. During the company's recent developers conference, iPhone chief Scott Forstall noted that implementations of background applications on rival mobile operating systems are largely flawed in that they lead users to believe that they've quit applications when those apps remain open.
This in turn eats at battery life, where the iPhone 3G is already limited by power-hungry 3G and location services, and also weighs on processor performance with each additional application that continues to run as a background process.
To solve this problem, Forstall said Apple was developing an alternative to background applications known as a "Push Notification Service" that developers could tap through a series of APIs, or easy to use programming functions, beginning in September. Instead of allowing potentially dozens of third party services to simultaneously access an iPhone directly, the push service would funnel all transmissions from developers' servers through a central Apple server, which would then relay the data to iPhones through a single persistent and well-managed background connection.
Apple's overview of its Push Notivation Service.
Through this technique, Forstall said developers can push badges to icons (like the email count indicator seen on the iPhone's Mail icon), notification sounds, or pop-up text alerts like those that currently appear when an iPhone receives a text message. This management system was also developed to scale easily with larger apps, the exec said.
The first beta release of iPhone Software 2.1 last week whet the appetite of iPhone developers waiting on the push capabilities when it included some references to the feature. However, a second beta that arrived last night finally includes a rough implementation of the push services API, according to MacRumors.
"This is the second beta of the iPhone SDK targeting iPhone OS 2.1, including bug fixes to iPhone OS as well as an early implementation of the Apple Push Notification Service API," Apple said. "This API is not yet integrated with a live push server."
Only a select group developers are reported to have received the latest beta, which as Apple noted, isn't fully functional. Still, the iPhone maker has two months left to meet its self-imposed deadline to roll out Push Notification Service tools to its broader developer community. If it makes good on its promise, the first background-conscious iPhone applications should start cropping up on the App Store later this fall.
Comments
I suppose the biggest worry is that it will be overused. (digg.com shouts anyone?) but as long as there are options to turn them off, and you keep an eye on what apps you install that use them, I suppose it will be bearable.
Okay... so we're not really talking about applications running in the background as the article sounds at the start, are we? We're talking about the push notification service which has already been announced and is expected? Big difference...
I hope this doesn't become the new twitter(always exceeding capacity).
I wonder if they learned their lesson from the mobileMe launch?
Hopefully they will have adequate server capacity to handle all the notifications.
Every developer and his uncle is going to want to use this.
I hope this doesn't become the new twitter(always exceeding capacity).
I wonder if they learned their lesson from the mobileMe launch?
Hopefully they will have adequate server capacity to handle all the notifications.
Every developer and his uncle is going to want to use this.
Interesting... I didn't really consider possible network issues. But I can't imagine how that would be a problem now that I do. Not only will the volume of data in this case be much smaller than anything Apple is dealing with in terms of activating an iPhone (and especially media-rich activity on MobileMe), but the consequences of delay or trouble at the start are much smaller. They're probably going to be transmitting a simple notification (one for each badge, or a numerically weighted notification) which is then assigned to an app. It might not actually be transmitting the app's data, though it could be pretty cool if they make that possible. Say they underestimate it -- delay will mean badges don't show up on time or don't show up at all (either not much worse than the present case of having no notification of all). I imagine it will go smoothly, though.
But yes, I imagine there will be a huge demand for this. Nearly half the apps on my iPhone, by my count, could take advantage of some kind of notification service. I think it would be a great service.
I got curious when I first started reading the article. It makes it sound like background activity will be allowed (are you misbehaving, AppleInsider? Trying to get clicks?) -- something which would be very cool for programs like Pandora. Apple's reason for avoiding this is, indeed, very legitimate, though. They'd have to police an author's implementation to prevent instability and bogged down phones.
Every developer and his uncle is going to want to use this.
And that may be where we have a problem, like Stukdog said, you DON'T want everyone using this or it will get overused.
Say they underestimate it -- delay will mean badges don't show up on time or don't show up at all (either not much worse than the present case of having no notification of all). I imagine it will go smoothly, though.
It's been a year and Apple still can't get email notification right (despite adding new configuration options), *and* they've utterly failed with MobileMe. Is there any reason to expect it will go smoothly? I guess something's better than nothing.
I got curious when I first started reading the article. It makes it sound like background activity will be allowed (are you misbehaving, AppleInsider? Trying to get clicks?) -- something which would be very cool for programs like Pandora. Apple's reason for avoiding this is, indeed, very legitimate, though. They'd have to police an author's implementation to prevent instability and bogged down phones.
There's a fair amount of instability with the current 3rd party apps, and it's not all due to the 2.0 firmware. The whole idea of the app store is that they're "policing" these apps (supposedly); though I agree by default all apps should shut down when not on screen, I don't see why they can't make allowances for the small subset of apps that need background audio, a feature of one of their built-in apps and really the only legitimate reason for any app to keep working in the background now that push is being made available.
I think after WindowsMe, anything with Me at the end is cursed.
"Their" is not the same as "they're" - sorry to be a grammar Nazi, just noticed that mistake in the opening sentence.
Hey, it's no worse than "Push Notivation Service".
Okay... so we're not really talking about applications running in the background as the article sounds at the start, are we? We're talking about the push notification service which has already been announced and is expected? Big difference...
LOL yeah, talk about a "loaded" story title!
I think this ability will be both popular and useful. I've already had quite a few iPhone developers contact me about getting some Mac servers set up to push their notifications. They're excited to have the ability.
I suppose the biggest worry is that it will be overused. (digg.com shouts anyone?) but as long as there are options to turn them off, and you keep an eye on what apps you install that use them, I suppose it will be bearable.
I don't see that being an issue. Developers will think carefully, as they won't want a heap of users uninstalling "their" app.
Skype will be useless even with this notification stuff. How can an incoming call come through if the app doesn't run.
The push service might be able to "wake" the sleeping app somehow. Badges, textual alerts and alert sounds.
A textual alert for the Skype app might be:
Sarah is calling you on Skype?
Ignore - Answer
Tapping Answer could then launch the skype app and put Sarah and you in connection for that voice call.
I thank you.
Skype will be useless even with this notification stuff. How can an incoming call come through if the app doesn't run.
It lets you know that a call is incoming, and then you decide whether to accept it or not.
It's been a year and Apple still can't get email notification right (despite adding new configuration options), *and* they've utterly failed with MobileMe. Is there any reason to expect it will go smoothly? I guess something's better than nothing.
What kind of email notification? A .Mac thing? I never cared for .Mac so I wouldn't know about that -- it was pretty obvious that Apple was focused on something much bigger. If you are talking about Apple Mail, I don't share your concern. That has been a solid app for me for... well... forever.
And spare me the MobileMe drama. :P
Apple is trudging through a rocky road, definitely, but it has just come out and I have a feeling they'll be ironing this out rapidly until it becomes a well oiled machine. Unlike .Mac they have a winner, here, and I think they know it. There's nothing else on the internet quite like what MobileMe can be. If you think mistakes in regard to rolling out such an exceptional new service somehow reflect on a company with such a rock solid background of providing wonderful revolutionary products, I would suggest you look up the definition to 'perspective' in the dictionary.
There's a fair amount of instability with the current 3rd party apps, and it's not all due to the 2.0 firmware. The whole idea of the app store is that they're "policing" these apps (supposedly); though I agree by default all apps should shut down when not on screen, I don't see why they can't make allowances for the small subset of apps that need background audio, a feature of one of their built-in apps and really the only legitimate reason for any app to keep working in the background now that push is being made available.
We don't know how much instability of mobile apps has to do with 2.0. It is definitely conceivable that there are a few gloomy bugs in the framework which could be affecting some of them. But most of the apps I have on my iPhone perform solidly -- I've only experienced a few application crashes since I got the phone -- so I'll wager it has a fair bit to do with a platform of young new software which is just now getting its real-world testing, on a completely new platform to which developers are just now being introduced. Then again, I don't download a program if every other feedback post talks about its instability.
I agree with you and the other poster about a background audio service, though. I think that is something Apple could implement and it is exactly the sort of thing the misleading title of this article got my hopes up about. I would love to have Pandora going while I did something else on my iPhone. It is a rocky road, though, as all it takes is some irresponsible programming in a few apps to flip the iPhone experience over on its head.
What they really need is some sort of background audio framework, so that apps like Pandora or AOL Radio could do what the iPod app does and keep playing even when you've moved to a different app. Unlike Push, only one app could use it at a time, and it shouldn't require keeping the entire app open, just some little 'helper' that keeps up the streaming going (or whatever the app in question does to get its audio)
I second that suggestion.
In addition, I'd like to see something whereby, if you're listening to your iPod and you run a 3rd party app which wants to take control of the audio subsystem, you can choose which audio stream you want. Or better yet, just allow proper audio sharing between apps.