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.

iMessage Sent iMessage Delivered

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.

Notifications and the Notification Center iCloud: An Introduction
POST A COMMENT

89 Comments

View All Comments

  • lurker22 - Tuesday, October 18, 2011 - link

    So there is no fix?

    I have to remember to send messages to people using their email address in order for it to be sure and deliver to all their iOS device? Which means I have to know what phones all my friends use which is nuts.

    Why doesn't iMessage just route imessages sent to a cell number to all the values associated with the apple ID?
    Reply
  • name99 - Friday, October 21, 2011 - link

    Truth is, there are a HUGE number of rough edges associated with iCloud and all the related services. A different set of examples would be the duplicates of events in calendars, or the duplicates of contacts in Address Book; and there is no consistent mental model for how data is supposed to behave "in the cloud and on devices". Mail behaves one way, calendars and contacts another, iTunes music a third --- and I don't think any human understands how Notes are supposed to behave.

    My HOPE is that this is all teething troubles --- Apple was faced with a deadline --- they needed to get iPhone 4S out by a certain date --- and iCloud was rushed before various bits were quite ready. If this is so, hopefully we'll see the worst discrepancies resolved in iOS5.1 and OSX 10.7.3 in three months or so.
    And if not --- well, that is NOT a good sign. Apple's whole value proposition is, of course, "it just works". And while Android seem unlikely to compete on that front soon, it is possible (not inevitable, but possible) that MS might actually get it right in Win 8, right enough at least to become the new press darling, the company whose cloud offerings make sense, unlike Apple whose every product behaves poorly and inconsistently across the cloud.
    Reply
  • unixfg - Wednesday, October 19, 2011 - link

    I don't really understand your claim here:

    "So regardless of how and where you’ve gotten your music from, if its there on the iTunes Store, it automatically gets legalized and added to your account..."

    Do you mean to imply there is no distinction on Apple's servers as to the source of your Music? I know the AAC files you buy have a tag linking it to your account, and can't imagine they wouldn't keep track of the source.

    That aside, I don't see how it would "legalize" anything. I'm a huge fan of your articles, and hate that this is the first time I've felt the need to register and comment, but...

    <citation needed>
    Reply
  • name99 - Wednesday, October 19, 2011 - link


    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.


    It's worth remembering that Apple also did not say, on day one, that FaceTime would be available on desktops. In fact they announced
    - FaceTime for Phones in June 2010.
    - FaceTime for iPods in Sept 2010.
    - FaceTime for Macs in Oct 2010.

    I'd say, given the FaceTime experience, there is no reason to assume iMessage for Macs won't appear as soon as Apple feels the time is appropriate. (Who knows when that will be, but it will probably be thrown into, to spice up some Mac related announcements, rather than just appearing silently in OSX update 10.7.3).

    The limitation to the Apple world may be a bigger hassle longterm, at least in terms of wanting to avoid SMS charges. I guess if you have lots of non-Apple using friends, you need to stick with Viber and suchlike.

    The REAL attack on the telcos comes when
    - FaceTime offers a voice-only mode AND
    - Apple offers VoIP transport to foreign numbers (like Skype does)
    My guess is Apple has plans for both of these, but they'll be introduced at the point where the Telcos no longer have the power to screw Apple over (which Apple probably feels requires a larger critical mass of customers than they have today).
    Reply
  • alpha754293 - Thursday, October 20, 2011 - link

    How does the new iOS affect battery life? Reply
  • techloverLA - Thursday, October 20, 2011 - link

    Hello,

    I own a Mac that recently got the iCloud upgrade. I turned it on and registered a new .me ID just to try it out for fun. Later when I turned it off, it gave me the message that "turning off iCloud will delete all iCloud data from the Mac. User can still access iCloud data with other iDevices." That scared me a bit, as I thought all my calendar/contacts on my Mac will get deleted. I logged on to iCloud.com and found nothing has been sync'd, so I went ahead and turned iCloud off. Nothing happened to my existing data on Mac. However this makes me wonder, does turning off iCloud wipe off data from the advices? I don't own an iPhone, but am considering one. However I don't want to have to delete data from my device should I choose not to use iCloud. Do you find that true in your test? Thanks.
    Reply
  • RosiePerkins - Friday, October 21, 2011 - link

    I think that if you are so pedantic as to worry about mising calls constantly. Or enough to be thrown by the fact there is no 'repetitive and annoying' alerts, then you should either get into a habit of constantly checking your phone. Which you would be if people were ringing you so often that you always miss calls or text messages.

    You're being rather lazy by expecting a feature in an already highly advanced phone to compensate for you not wanting to hit the wake button. If you are then unsatisfied with the way you have to wake your iPhone now and then maybe you should reconsider ever having it leave your person. This way there is no need for features that would cause stress for every one else around you.
    Reply
  • IndyJaws - Saturday, October 22, 2011 - link

    Thank you for one one of the most thorough recaps/reviews I've seen on iOS 5 - excellent work!

    One thing I'll share with others at the risk of looking stupid...I couldn't figure out why iTunes kept launching on my 2 computers for no reason at all (phone was not connected at the time). I'd shut it down and it'd start back up, seemingly randomly, from time to time. Silly me, I had iTunes configured to sync to iCloud, but to still launch iTunes when the iPhone was connected. So...the wireless sync would kick in (at intervals much more frequently than I would have expected), causing iTunes to launch. Clearing that checkbox fixed the issue. Just an FYI in case anyone else runs into the same issue - I'm sure there are others, but not willing to admit it!
    Reply
  • mashimaroo - Tuesday, November 01, 2011 - link

    Mirroring in the iphone 4s and ios5 makes doing presentations on my iphone so much easier. I can simply connect it with a vga connector or a/v connector to my aaxa p4 pico projector and im good to go. I can use whatever docs goodreader or keynote. i can even play games with it and stop staring at my tiny phone screen. Reply

Log in

Don't have an account? Sign up now