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.

I agree. Have you reported them as bugs to Apple?I've submitted maybe 30 bug reports and feature requests regarding iOS5 and iCloud over the past few days.

Having worked at Apple for ten years, I know: engineering is DRIVEN by bug reports. If you submit a bug, especially if lots of other people are submitting the same bug, it's pretty likely to get handled before the next release. Feature requests --- maybe handled --- sometimes they agree, sometimes not, sometime it's just a low priority.But random rants on blogs --- unlikely to change anything unless some Apple engineer happens to read your comment and think "fantastic idea".Reply

This is a feature, not a bug, to everyone else in the world that doesn't want to hear your phone make noises endlessly because you aren't in the room.

"Set ringer based on location and date/time."

Agreed, this would be nice.

"Set WiFi & Bluetooth based on location and date/time."I find this unnecessary. I leave both of those on 24/7 and always make it through the day on a single charge. Push notifications and location uses far more battery than those two and having them turn on/off based on location is going to cause more battery usage than just leaving them on all the time.Reply

"Unfortunately, iTunes Wi-Fi Sync asks that your phone be connected to a power source for the feature to work. This shouldn’t be too hard to grasp considering the massive power drain issues people would have inevitably faced had it not been otherwise."

A quick but notable clarification in the review which gives the impression the wi-fi sync function requires a device to be powered to work. It needs to be plugged in to work automatically once a day. However, a device can manually be synced over wi-fi without being plugged in. Go to settings -> general -> iTunes Wi-Fi Sync and hitting the Sync Now button.Reply

You mentioned the newton force etc to take a picture. You can actually take pictures now with the headset using the up volume button. So you could hook up to a tripod etc or set the phone down somewhere and click away as fast as you can press the buttons on the headset. You could probably use a bluetooth up volume button too.Reply

I've yet to have WiFi sync actually automatically sync my phone when plugging it in for the night. Perhaps iTunes must be left running on the computer, but that kind of defeats the purpose of automatic sync; I'm not going to leave a bloated app like iTunes running 24/7 just in case my iPhone decides to sync.

If this is a requirement, WiFi sync will be largely useless for me until they can at least have a service launch iTunes on the PC when the phone wants to sync.Reply

Yes, iTunes has to be running for the wi-fi sync to initiate automatically. No, the iOS device won't launch and then quit iTunes.

One other thing I've noticed is that leaving iTunes running with wi-fi sync enabled is an enormous power drain on the battery on my iPhone 4. I've noticed my fully charged phone will be down to 40% charge by the morning. Of course, if you leave the iPhone plugged in all night, it will still be fully charged in the morning but apparently, there's a lot of power-draining activities going on between iOS device and computer during the night. This is one reason I've decided not to use auto wi-fi sync since I don't want to keep iTunes running and unnecessarily using power overnight. I still like the wi-fi sync option a lot but I manually sync wirelessly and then quit iTunes. Reply

"A company that executes consistently may not be competitive on day 1, but after a couple years of progressive iteration it may be a different beast entirely." sums up what WebOS failed to do successfully.Reply

I was wondering why GPU benchmarks weren't included? The results at Barefeats show that Apple seems to have much improved GPU drivers in iOS 5 compared to iOS 4.3.5. Devices seem to show around a 25% improvement in GLBenchmark for instance. It would be good if you could validate this result in GLBenchmark and GLview as well as add in the iPhone 3GS which Barefeats is missing.

And do you know how GLBenchmark's online results database reports it's scores? For each device, in the details they seem to list multiple GPU driver and OS versions, which makes me think they are using a running average of submissions. Seeing performance changes with OS version, that would make he GLBenchmark online database very inaccurate. It's great that you are able to run the benchmarks on your own devices so that the results are unambiguous.Reply