Apple announced its Push Notification system during the 2008 WWDC Keynote, pitching it as a more efficient alternative to allowing third-party apps to run in the background. It was scheduled to ship in September of that year but didn’t actually reach customers until iPhone OS 3.0 was released in July, 2009. The delay was attributed to taking an additional six months to re-architect the system to make sure it was scalable.
Recently, at WWDC 2011, Apple said that it has delivered over 100 Billion push notifications to iOS devices. Of all the numbers they tossed out during that presentation that was the one that surprised me the most. 100 Billion is an order of magnitude greater than what I’d have guessed if I’d been asked to aim high in my estimation. It would appear that taking their time and doing it right has paid off for them again.
The interesting thing about Push Notifications is an implementation detail. Third party applications are, through a combination of operating system and App Store policy, prohibited from keeping a persistent connection to a server. iOS maintains just one persistent connection in order to reduce battery drain by using the CPU and radios as efficiently as possible. Ostensibly this connection is for the timely delivery of Push Notifications to all iOS devices. In reality this connection serves as a communication channel to every iOS device with a network connection. The Push Notification infrastructure allows any iOS user to be addressed individually, across all their registered devices, with a remarkably minimal latency.
Let’s consider a few magical features and think about how we’d implement them if we were Apple.
(NB: This is an extrapolation from publicly available information, I’ve not tested, reverse-engineered nor do I have any direct insight or knowledge about how this stuff works. If I did this entry would just be a photo of a kitten.)
The “Push Notification” persistent connection enables:
- Push Notifications. In badge, sound and text flavours.
- Find My iPhone. Asks the device for its position and provides for sending a message, locking or remote wiping a device.
- FaceTime calls. Works with iPhones, iPods (let’s drop the ‘touch’, iPod Classic is dead) and iPads. Oh, and now Macs.
- iBooks bookmark syncing. Transparent and works across all iOS devices.
- Enterprise Wireless Configuration. iOS provides a mechanism through which enterprise customers can remotely reconfigure the devices they have in the field. It’s all very boring until you think about how that might work.
So there’s a fair amount of functionality we take for granted in iOS devices that’s already being provided over this one persistent connection. Not all of these features are likely to run entirely over the persistent push connection, but it is the control line that kicks things into action. iOS 5, and the set of services branded as iCloud, seem set to blow this pipeline wide open.
Whenever I type iCloud I’m sorely tempted to place it within quotes. I don’t believe iCloud is any more of a definable thing than OS X or iOS — I believe it’s collection of services that are well suited to work together and, more importantly, will be presented under one technical and marketing umbrella. That may seem like an odd take but, really, iOS and OS X are complex stacks of technologies that come together largely through the application of an editorial, or at least cultural, voice. From what I can tell iCloud is similar in that regard. There is no singular aspect to iCloud — it’s a collection of services, nicely abstracted, upon which third parties can build. From what I can tell the system that was set up to enable low latency Push Notifications is to iCloud as the Mach microkernel is to iOS and OS X. It is the enabling base for the greater system built atop.
There are three major new components atop this infrastructure that have been introduced under the new iCloud branding: ubiquitous short-form state (similar to iBook bookmarks), ubiquitous document sharing and coordination (long-form state) and iMessage. Each of these new features tickle the persistent “push” connection and trigger some action on the device. The short-form state may be transmitted immediately and set on any connected device within moments. Document syncing is likely to trigger a negotiation process to compare the state on any one device with The Truth stored on Apple servers and replace the document on the device with the latest revision — this has the advantage of limiting the window between syncing where conflicts are most likely to occur. iMessage piggy-backs on the persistent connection, and I’d wager on some of the infrastructure set up to service FaceTime, to provide a very low-latency text-chat-with-in-line-attachments environment. I’d bet that Mail could pick up a few new tricks like updating Read Counts that the standard IMAP protocol doesn’t support well.
Of all the announcements at WWDC 2011 iMessage struck me as the most immediately important. It is obviously a swing at RIM’s BBM (BlackBerry Messenger) which I’ve previously argued is one of the last true core attractions to RIM devices. BBM was never mentioned on stage but the comparison is obvious to everyone. If iMessage works as advertised, and I believe it will, then the network-effect will start to play against RIM and they’ll have lost their last leg — BBM was never about BBM it was about a chat network between friends that was secure, free, more immediate and gave better feedback than simple SMS messages. iMessage looks set to deliver upon all of that, even covering arguably annoying cases like providing read receipts.
I find iMessage so intriguing because it builds upon an existing infrastructure, it duplicates or betters a competitors approach and it’s not something I’d have expected from Apple. Now that it’s here it feels like an obvious move, but I’d not have predicted it. There are major ramifications for Apple, and their users, with iMessage.
First, and the one most talked about, is that iMessage is an obvious thumb in the eye of carriers. There’s a certain glee to sticking it to the carriers, no one likes their carrier — they are suffered. But iMessage makes each iPhone on a carrier’s network less valuable. No longer do iPhones in the field represent potential income from SMS charges. Furthermore springing iMessage on the carriers telegraphs that Apple will, at a time it chooses, ditch tradition and move to a purely Internet driven solution. If you’re a carrier then this has to be unsettling. I’d expect some tougher negotiations for Apple ahead and more love for Android devices as a play to offset Apple’s advantage.
The second major ramification I can see with iMessage is that it places Apple, for the first time, squarely in the sites of politics. No longer are iOS devices just end-points for communication, with iMessage Apple will become a major carrier of information. Recently Apple was called out by the United States Senate over location logging, one has to wonder what sort of political kerfuffle will arise once Apple starts distributing a non-inconsequential amount of chatter. We’ve seen RIM be called upon by foreign governments to either censor or allow access to their messaging systems. For the first time I can think of Apple is placing itself in a position, intentionally, to which there are very few good outcomes. Internet driven companies, like Google or Facebook, have had to deal with this sort of thing and have done so with varying degrees of success. This is something new for Apple though and I’ll bet it’ll be a bigger story than the hissy fit the carriers are going to throw.
All of that said, that’s just the side-show. The interesting thing, to me, is how this is being built. As far as we can tell all of this sits atop the operating system managed communication channel. Updating short-form data (iBooks syncing), triggering more complex actions (FaceTime), negotiating document changes, all of this is driven by one central service which the OS can manage efficiently. And that’s the real trick, iCloud isn’t a bunch of processes running on your phone that sync up with a server and each other, it’s a system level service that benefits from being that low level. The differentiator between “iCloud” and competing platforms plays exactly upon the strengths of the iOS platform: Apple runs the show and third-party developers do as they’re told.
iCloud builds on a single, high capacity, short message distribution system. Apple has called it “Push Notifications” before but, really, there’s a lot more to it than that. The advantage Apple gains from this isn’t apparent if you’re looking at software checklists — I’d bet there’s an Android announcement in a week or so that claims all the features iOS 5 promises. The thing is this, and it’s an important thing — always bet on the technologies that scale. When OS X launched Apple bet on improved GPUs and the ability for graphics hardware to back each window. That was a great bet, Microsoft took a few years to catch up with that move. Apple is now betting that multiple applications maintaining their own connections to disparate servers will end up performing poorly on mobile devices. I believe they’re right. Betting on batteries improving by orders of magnitude is a poor bet. Betting that radios will somehow cost less power to broadcast and receive is also a poor bet. Apple has bet on consolidating these costs into a single, well defined, and manageable system. An “open ecosystem” can’t possibly match the efficiency of such a set up. We’d need to see battery life become a non-issue and some incredibly compelling applications before alternative platforms could become a threat.
The truth is that there are cold, hard limits to what can be done with portable devices. We’re too often tempted to think of them as little computers, but they’re not. The fact that they don’t plug into the wall should be a giant hint. Apple has made an interesting play with iCloud, one that will push them further into public and political discourse, and one that will set them further apart, in technical terms, from what their competitors can deploy.