Apple's missing link for the iPhone has been a two-way connection with the cloud. With its new push notification service, Apple enables greater interactivity for the handset's applications and users.
But at the same time, the Apple Push Notification Service (APNS) highlights the way Apple's ban on background processing and multitasking still hamstrings the iPhone's two-way interaction with the Web.
Can you manage an iPhone like a BlackBerry?
APNS lets an iPhone application register to receive remote updates. Those updates might be a new tweet on Twitter, an item added to newsfeed, or a challenge from an online game player. APNS sends the update directly to the registered iPhone. The update can trigger a sound, show a text message, or prepare an iPhone app to launch in response.
It's already been quickly implemented by iPhone game vendor Tapulous, with the help of start-up Urban Airship, which is kind of an APNS middleman.
The new API is part of Apple's version 3.0 of the iPhone operating system released earlier this summer.
But push comes at a cost -- not for users but developers.
The service requires creating and maintaining a server, or group of servers, that is constantly linked with the Apple server farm to process the message requests. It's a daunting requirement for many small software developers, who also may lack experience in handling socket connection pools. And the new service has revived rather than muted some complaints that Apple still won't permit apps on the iPhone to run at the same time in the background and make periodic checks for information updates.
Apple's argument is that background processing and multitasking can consume CPU cycles and memory resources and exhaust the battery. With a push system, iPhone apps in effect are asleep, and the user wakes each one up separately to respond to a relevant notification.
Early impressions
Back in April, bloggers such as Mobile Orchard's Ryan Daigle (formerly a principal with Y Factorial, which merged with iPhone and web application developer DigitalToniq) noted the complexities of APNS.
In a blog post, Daigle notes that APNS relies on socket connections to deliver messages to the Apple gateway, which is set up similarly to an SMS gateway: a raw binary interface via long-lived or persistent socket connections. By themselves, sockets are "not that intimidating," he writes, but it does add complexity for developers who don't have experience in maintaining a server-based pool of connections. (Enterprise developers, with experience in server-side persistent or long-running applications in Java or similar languages, will find this much less of a challenge, he says.)
Developers will need to get the right tools and "think about this before designing their iPhone apps [with APNS]," he added.
All those issues remain, Daigle says today. "As a push notification implementation, APNS is robust, and architected to be highly performant," he says. "However, in its usage, it is flawed in that many apps are using push as a workaround to missing functionality on the iPhone."
In the past, an iPhone app could only retrieve information when it was running, explicitly launched by the user. This kind of polling is expensive, because the app has to go through the process of asking whether there is anything to download or not: It only knows when it asks.
"With push, the data can be sent to the app only when there's info to send," says Daigle. "It really opens up the real-time notification aspect in a broad class of applications, such as IM, Twitter, games, and so on," Daigle says. Push fits best when an iPhone app needs to updated based on a state change outside the iPhone's control, he says.
But for other kinds of information updating and sharing, APNS can be extremely costly, compared to alternatives. When the state change is completely within the phone's control, such as setting an alarm in 20 minutes, "APNS could be used but is egregiously excessive", Daigle says. A better alternative would be a local job scheduler, or chron in Unix terms, which would let the app wake itself up and take some action, such as displaying the alarm.
And allowing the iPhone to update a remote server, such as by sending periodic location updates so the phone can be tracked, "can only be implemented as a background process or local cron," Daigle says.
Early adopters
Yet these issues haven't stopped some established developers from moving quickly to embrace push notification. The first implementation of APNS was done by Tapulous, creator of Tap Tap Revenge, which combines gaming with music from an array of popular artists. It's been downloaded over 11 million times to date. Working with Urban Airship, the Tapulous software engineers set up a push capability for its gamers just a couple of days after the June 17 launch of APNS.
Tapulous wanted to use APNS to create a kind of news and alert feed to Tap Tap users. Via the push service, Tap Tap's iPhone icon now can be "badged" (referring to the marker with an icon to show the number of missed phone calls or unread emails for example) to show the number of unread notices in the news feed; and the Tapulous servers now can alert users through the app when they've been challenged by other players, says Jessica Kahn, director of engineering for the Palo Alto, Calif., gamer. If the player accepts the challenge, Tap Tap will launch to begin the game. A final notification tells the players the game results.
APNS may be especially attractive to users of the new iPhone 3GS, with its more powerful CPU, better battery life, and potential for faster cellular connections.
Kahn says the client side of APNS is "nothing too complex." "You just have to register as an app that wants to receive Apple Push Notifications, and then, if you want to be able to launch your app in response to a notification, you add a little code to do that," she says. "It's well documented by Apple, and [involves] just a couple of new APIs. We got this part working in a matter of an hour or two, with an additional day or two of work to improve our 'challenge a friend' [feature]...."
On the server side, the Tapulous software team simply added an Urban Airship library. It's the hosted UA service that does the heavy lifting and handles all the complexity mentioned by Ryan Daigle.
Urban Airship itself is almost as new as APNS: it took flight in early June, and the founders, who had worked together on a previous start-up, spent about a month writing the scalable middleware to work with the new Apple service, and to simplify access to it for developers like Tapulous.
Developers can build their own APNS services, acknowledges Scott Kveton, CEO of Urban Airship. But they would need to create their own server infrastructure to forge and maintain persistent or long-lived socket connections to the messaging gateway on the Apple servers, and they'd need to come up to speed on the relevant Apple protocols. Urban Airship offers a way to sidestep all that, for a price, of course.
Developers pay Urban Airship on a per-delivered-message basis, but the company won't say what it charges. "We're trying to keep it really reasonable," says Kveton.
"Developers integrate our software [with their application]," he says. "So when the app is downloaded to the iPhone, and a user opens it, the app talks to our service and registers. That tells us where to find that app in the future." Urban Airship queues the messages, tracks and keeps alive multiple interactions, including anyone who unregisters or who stops using the application, and interfaces with the Apple servers. "It gets pretty complicated, actually," Kveton says.
When the developer wants to issue a notice or alert to its iPhone users, "they make one call to us, and we deal with finding the device and getting the messages sent very very quickly," Kveton says. The Urban Airship service is maintained via a third-party hosting company, with experience in scaling online applications.
Tapulous contracted with Urban Airship partly because the decision was made to deploy APNS as quickly as possible to be among the first vendors to offer it, and partly because using the third-party infrastructure reduced the risk of deploying new features on the game vendor's production servers. "Add to that the fact that the 'Provider' portion of APNS is just a little bit different than anything we've done before, involving raw sockets, multiple concurrent persistent connections, SSL, and so on," Kahn says. With enough time, it could be done, but time was short.
Part of Urban Airship's offering includes performance monitoring via either a statistics API or a graphing interface on their customer Web portal, says Kahn. A few weeks ago, one of the Tapulous database servers fell behind and "needed to be caught up," she recalls. When it did, the update triggered a flood of calls to the Urban Airship service: both vendors tracked the flood through the graphs, watching it peak at about five times the usual number. "Their service handled it without breaking a sweat," she says.
Urban Airship releases its code, sample code, and libraries under the Simplified BSD License, so companies like Tapulous can dissect the software as completely as they want.
Urban Airship has launched support for a second interactive Apple API (also part of the 3.0 OS release) to enable what are called "in-app purchases." The feature lets users download new app features or content from within an existing iPhone app, which could use APNS to alert users to the new elements. Urban Airship plans to launch support for the new API with SubAtomic Studio, maker of the Fieldrunners game.
