Apple iOS 5 Review

iMessage

One of the largest new improvements in iOS 5 is the inclusion of a new messaging service for iDevices which behaves in a manner closely analogous to RIM’s BlackBerry Messenger. This new messaging platform is dubbed iMessage, and works between all iDevices that can run iOS 5 - iPod Touch, iPhone, and the iPad all become a platform between which iMessages can be sent.

What’s new about iMessage (and makes it analogous to BBM) is that the service operates over the standard packet switched internet rather than through the circuit switched backend of traditional SMS. The result is that iMessage is an SMS replacement that doesn’t require a wireless carrier SMS plan, and only requires a data connection to exchange messages. For iDevice users, this isn’t really anything new, as there are many third party applications which do functionally the same thing, and for BBM users, this is even older hat. Like most of the SMS-less messaging solutions that are available in the App Store already, iMessage simply uses Apple’s Push Notification Service (APNS) which we’ll get into in a second.

Of course, the benefits of using a packet switched messaging service over data in the place of SMS are immediately apparent. There’s no 160 or 140 (depending on encoding) character restriction in iMessage land, and as a result, no resulting necessity for messages to be split and sent as multiple texts and re-concatenated on the other side. I praised Apple for implementing cross-carrier SMS concatenation with the CDMA iPhone 4 (which enabled texts to come across to a GSM/UMTS AT&T iPhone 4 in one piece), however this broke a long time ago. It’s clear that Apple’s focus shifted to iMessage a while ago, and as a result this never was totally remedied. In the case of the CDMA iPhone 4, there’s also that annoying few seconds when sending or receiving an SMS where you have no data connectivity due to the 1x/EVDO (voice+SMS/data) dichotomy of a CDMA2000 network - with iMessage, there’s none of that stalling since everything is just data. Of course, the other improvement is that you no longer have to deal with the best-effort delivery mechanism for SMS where messages can occasionally get lost, never arrive, or the occasional duplicate flood from delivery assurance algorithms sending more than one message. In addition, iMessage uses both phone numbers and email addresses for recipient identification.

The unfortunate side is of course that iMessage is limited to iOS for the time being (nor is there a desktop version), meaning you’ll still likely need a messaging plan for talking to people who aren’t carrying iDevices. In addition, iMessage uses SMS as a failover delivery mechanism when iMessage doesn’t deliver within about five minutes. I encountered this behavior numerous times when Anand and myself were flying around - if the recipient isn’t able to get the APNS notification for that five minutes, the sender falls back to SMS. iMessages are shown in blue bubbles (and the send button is accordingly blue when you can send using iMessage), and SMS is shown in the traditional green (and you get a green button).

On the iPhone, iMessage looks just like the old messaging interface, but with this blue and green color scheme for distinguishing between iMessage and SMS, respectively. Below each message you’ve sent is a delivery report, and, if the recipient has enabled it, a read report. These collapse and show for the latest message in the thread as the conversation progresses. In addition, there’s a typing bubble when your recipient is drafting a message. This is again entirely analogous to BBM - iMessage has recipient typing status, read receipts, group messaging, and delivery reports.

A new UI feature is the ability to finally collapse the keyboard without having to go back, and then into the conversation again. Instead, just drag the conversation down and the keyboard collapses itself as you scroll up. This is a much better interaction paradigm that I hope other applications will adopt.

On the iPad, the interface gets a 4:1 split for a conversation list, and then the dialog happens in the rightmost pane. You even get an avatar here, and the result is that this strongly matches the desktop iChat IM client. If you have multiple iDevices and use an iPad as something of an accessory to an iPhone, iMessage synchronizes conversations (both sent and received messages) across both.

Further, since the software knows what platform you’re engaging with iMessage with (and reading things on), it keeps alerts persistent accordingly, so you aren’t swamped with unread message notifications when you switch back to another platform. It doesn’t completely eliminate the need for an iPhone (which you’ll probably still end up pulling out of the pocket for SMSes) but gets close. It’s a bit eerie sending texts from an iPad (and right about now is when a vibration unit would’ve made sense), but it works, and if you have the patience does make sense.

Inside settings are some new toggles for iMessage. Obviously you can just disable iMessage entirely, but there are also toggles for sending read receipts (if you don’t want people to know you’ve read their message and are opting to not reply), SMS failover disable, and receive locations. Inside that receive location window you can configure any email accounts you wish to receive iMessages with, alongside a phone number (if you’re on an iPhone).

The last window is Caller ID, which can be configured to be either your phone number (if applicable) or any of those email addresses you can receive at. By default that email address is just your Apple ID, so be ready for at least some brief confusion from recipients if they don’t have your Apple ID email address associated with your contact. The reason for that Apple ID email address set as default Caller ID is obvious - this has to be set accordingly for iMessages to be sent to other iDevices without cellular numbers.

Photos and videos can also be sent over iMessage, and in function this is virtually identical to how MMS works in previous versions of iOS. What’s new is that unlike MMS, there’s no longer an arbitrary file size limit enforced by the carrier’s MMSC (MMS Store and Forward Server). The result is that images are sent in their full size between iDevices, but here’s the big caveat - only when both recipient and client are connected over WiFi. I sent images and video captured from a 3GS to a 4, and from a 4 to a 3GS using iMessage with both the recipient and sender on cellular and WiFi (4 combinations) and only when both were on WiFi did photos and video come through uncompressed. Throw cellular in there and the lowest common denominator in the chain defines the resulting quality. In that circumstance photos and videos get compressed to where they’d be for MMS.

It’s unfortunate that Apple continues to apologize for and appease carriers with compression, but such is the state of things until we get ubiquitous 4G LTE. The upside is that when you’re on cellular and have limited upstream, photos and videos won’t take forever to send or receive. The downside is that email still is the only way to guarantee you get a full quality image somewhere when on cellular.

I mentioned earlier that iMessage uses APNS, and this is entirely true. Not satisfied with just reporting that fact, I decided to do a little Man-In-The-Middle (MITM) with an iPhone 4 running iOS 5 GM and my internet connection to check out what iMessage looks like over the network. The results are pretty surprising.

First off, what’s surprising in the case of the iPhone is that iMessage appears to prioritize cellular data for strictly text delivery. When I first configured my MITM, I thought I was doing it wrong, studied my setup, and then turned airplane mode on (to disable cellular) and re-enabled WiFi. After doing this, I then saw APNS working back and forth across my internet connection. After more experimentation, I’ve determined that messages prefer cellular, but larger payloads like photos and video go over WLAN. Why the strange dichotomy? Well, cellular networks (at least 3G ones) are generally safer and more trusted than any random WLAN (I was even using WPA2, so this isn’t a matter of things being different on public WiFi), so I can understand Apple’s hesitation to use WiFi by default for fear of someone eventually doing a MITM attack on TLS. That said, it’s just a bit confusing.

Next up, I mentioned that the 128 byte per SMS limitation doesn’t really apply to iMessage. While this is partially true, I’ve seen messages split at 1170 characters with some repeatability. This is a bit curious to me since Apple stipulates that APNS are limited to 256 bytes. Interestingly enough I’ve seen push notification packets with payloads of up to 853 bytes, so who knows whether those guidelines apply to iMessage (probably not). Meanwhile, read receipts and delivery reports seem to be 53 bytes. You can see traffic going to courier-push-apple.com.akdns.net. It shouldn’t be any surprise to anyone that Apple is using akamai for APNS at this point. I don't think 853 bytes (for maximum length) and 53 bytes for read and delivery reports are any coincidence, it's fairly obvious in retrospect that 53 bytes ends up being the minimum overhead, and thus 800 bytes is the maximum message payload. 

Apple claimed at WWDC that iMessage is encrypted, and this is entirely true. Encryption is courtesy of TLS just like other APNS as outlined on that same page.

I saw this same handshake happen in realtime as well, and periodically refresh just like you’d expect. It’s good that things are encrypted to prevent snooping when attached to some random public WiFi, but again even TLS isn’t invulnerable to some MITMs.

The only major lingering question and concern is what happens on Apple’s side of things - even though the phone to endpoint is encrypted, the contents of iMessage (if they’re treated like normal APNS) are plain text after the endpoint for Apple to route around and then ship back out over APNS to the recipient. The even more interesting thing to think about is how now Apple will have to provide a means for Lawful Intercept for interested parties. These are all very interesting questions that we look forward to seeing play out in some detail as iMessage becomes the preferred means of messaging for iDevice users.

When you’re sending an MMS message, it seems as though there are two parts to the process - a normal iMessage APNS, and another transaction which happens against content-.icloud.com.akadns.net. It seems simple enough - the photo or video payload is uploaded to Apple’s iCloud datacenter, the push message comes across with a link to it, and the recipient grabs it. I have to speculate a little bit here since things are indeed encrypted, but iCloud does appear to be a content store (by their own DNS name) for iMessage payloads.

Delivery on iMessage is speedy almost all the time, and is again contingent on having fast data connectivity. Most of the time, that isn’t a problem, however in crowded markets where there’s blocking on WCDMA you’ll find yourself falling back to SMS when messages don’t send over iMessage. I spent a week in Las Vegas on vacation with one of the iOS 5 Betas, and actually came away decently impressed with how well Apple has the timings for SMS failover configured. On both WCDMA and EDGE, messages deliver faster than they would ordinarily on SMS.

Apple has left some debugging and diagnostic data on for iMessage which they ship back to themselves nightly inside log-aggregated-[date]. In iOS 5, this debugging data is even visible without having to sync the device with iTunes inside General->About->Diagnostics & Usage->Diagnostic & Usage Data. Inside among the data you can see the delivery receipt time and send time for messages throughout the day, and I’ve been paying attention to this data since I first saw it. I kept about a week of this data, summed it all up, and made some plots.

The vast majority of iMessages are sent in under 2 seconds, and then delivery reports come back within another 2 seconds. This is so much faster than the 5 or more seconds you have to wait for an SMS to go out of the phone, sit in the SMSC, get routed around possibly to another carrier’s exchange, and then back out to the recipient. But equally as important is the fact that it isn’t as fast as IM.

I guess that’s the next major part of the discussion - the actual effect of iMessage’s increased speed on the conversation. This is again old hat for BBM users, but the speed of iMessage is somewhere between the pace of IM and SMS. To call it IM speedy is something of a disservice, since it isn’t instantaneous, yet it’s easily an order of magnitude faster than SMS across a carrier exchange. The result is a much increased conversational velocity that still isn’t quite as mentally burdensome as IM. I think it’s interesting and important to make that distinction - iMessage feels like a faster SMS rather than a slow IM. Whether the means of conversation is mentally taxing often determines how casual the communication is, and in this case iMessage preserves the informality of SMS with enough of a delay.

The final implication is what all of this means to carriers. Unfortunately, iMessage still isn’t a clean break since it’s limited to the confines of iDevices (and not even the desktop, yet), and it’s no way to make friends to tell people they’ll need at least an iPod Touch to text you. The end result is that unless all of your contacts are on iDevices, you’ll probably still need an SMS plan, or risk paying per-SMS rates. This is clearly a step in the right direction for making the carriers dumb pipes, as it makes what was previously a mysterious proprietary protocol (SMS) just some IP packets. The other effect of making this Apple-exclusive is that (like BBM) it makes it difficult for people to switch out of the ecosystem and further increases that attachment.

The result is that how much impact iMessage makes on your monthly SMS use varies on what your friends are carrying around in their pockets. For now however, Apple has come up with a seamless analog to BBM for iOS.