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

  • simi13 - Tuesday, October 18, 2011 - link

    I could swear I am on 9to5mac.com (I read anand and that daily), hahaha. A very nice review, though. Reply
  • MobiusStrip - Tuesday, October 18, 2011 - link

    It does fail to mention a glaring omission in the OS, though: repeating, AUDIBLE notifications of MISSED CALLS.

    This was inexcusable in version 1, but after five or six years, Apple's phone still lacks an important, common-sense feature that was found on cell phones in the '90s. Aren't people sick of missing time with their friends and families because they didn't find out they called until the next day?

    Your phone is on its charger on your dresser, and you're taking a shower when someone calls; the phone gives one little chirp immediately after the call and never again. WTF? If you missed the call, it stands to reason that you're going to miss a single noise right after it. The thing should (OPTIONALLY) notify you periodically that someone called, until you cancel the notification.

    Even more bafflingly, Apple added repeat-notification controls for TEXTS. So if there's an emergency in my family and my parents want to get in touch with me, we're assuming they'll TEXT me? Brilliant, Apple. You have to wonder what kind of retards make these decisions over there.
    Reply
  • eallan - Tuesday, October 18, 2011 - link

    I hope Apple adds the option for people that want it, but man, that is one specific complaint.

    I don't think I've ever wanted the feature. Just wake your phone up after a shower? Whats the big deal?

    I think that may be the most rare complaint about iOS. Hardly makes them "retards" for not adding a specific niche feature. Relax
    Reply
  • Booster - Tuesday, October 18, 2011 - link

    "I don't think I've ever wanted the feature. Just wake your phone up after a shower? Whats the big deal?

    I think that may be the most rare complaint about iOS. Hardly makes them "retards" for not adding a specific niche feature. Relax"

    Sorry man, but it IS a big deal. Who in the hell would want to wake his phone periodically? Don't you realize how stressful this is? You'll never get to 'relax' knowing someone might have called or texted you etc. You'll be constantly checking out your iPhone and over time this will drive you crazy. Not a small matter by any means and surely not 'niche', since every freaking user suffers from this.

    If iPhones were really that good, they'd have a dedicated LED indicator for missed events and sufficient options to customize alerts, but they would be off by default so idiots wouldn't complain that their iPhone is bugging them. Leave it disabled by default, that's fine, might even add a warning before activating alerts, but this feature just needs to be there, man.
    Reply
  • Bob-o - Tuesday, October 18, 2011 - link

    > If iPhones were really that good, they'd have a dedicated LED indicator

    Agreed. It was only last weekend, when my neighbor was showing off her new 4S, that I realized you couldn't just look over at the phone to see if you have a txt/email/voicemail waiting for you. Something my Treo 650 used to do just fine.

    As great as new phones are, it is amazing how some of them have taken steps backwards in many little ways.
    Reply
  • robco - Tuesday, October 18, 2011 - link

    That's all well and good if you're home alone, your phone rings, you aren't available, you find out when you return. However, I do recall back in the day, being in a public place, someone's phone rings in their purse or jacket, they're off in the bathroom or in a meeting or something. Not only do you have to listen to their phone ringing, but then you have to listen to the audible beep every so often and that can get quite annoying. Convenient for you, not always convenient for those around you.

    Honestly, get into the habit of checking the phone when you've been away and out of earshot. One quick tap on the sleep/wake button will let you know if you've missed something. Otherwise yours is the phone people are going to want to smash with a sledgehammer because it's beeping every few seconds.
    Reply
  • Booster - Tuesday, October 18, 2011 - link

    "Honestly, get into the habit of checking the phone when you've been away and out of earshot. One quick tap on the sleep/wake button will let you know if you've missed something. Otherwise yours is the phone people are going to want to smash with a sledgehammer because it's beeping every few seconds."

    I'm more concerned with my personal psychologic wellness rather than with what irritates the others. Then again, why not include the feature but disable it by default? Morons won't even care to enable the cornerstone feature of any mobile device, but those who care - they will.

    You probably don't realize how retarded the 'quick tap' concept is, how extremely inconvinient for the user. Why should he or she pimp the damn square button every now and then? There is just no excuse for not really caring about end users.
    Reply
  • snuuggles - Wednesday, October 19, 2011 - link

    Hmmm, I think you are too-quickly dismissing a valid point. I mean, there are actual laws about car alarms that go off repeatedly because they are so amazingly annoying. I think your repeated noise idea is along the same line. A dedicated light might be a better compramise.

    Honestly, you seem a little unhinged, I somehow doubt that adding this single notification feature will allow you to have better "personal psychological wellness."

    Maybe you should get rid of the phone if it's that important. Unless you are a doctor or the president, being reachable isn't *that* important.
    Reply
  • kezeka - Thursday, October 20, 2011 - link

    I am in medical school and I can personally vouch against doctors wanting to be within earshot. If we aren't on call (you would have a pager for this) then there is no reason to constantly check the phone. There are instances where I can see it being necessary.

    That said, I leave my phone completely silenced all day, every day and just check it periodically to see if anyone has tried to contact me. If they have, I call them back. It isn't worth breaking your concentration to be completely on top of things (insert link to any number of articles suggesting the human brain is horrible at multitasking here).
    Reply
  • name99 - Thursday, October 20, 2011 - link

    I actually am with MobiusStrip here. Different people use their phones in different ways, and I'd appreciate a more aggressive reminding of missed calls.

    A similar problem (which I reported as a bug a year ago, but which is still not fixed) is audible notification of text messages. Suppose you have your phone connected to a BT headset or headphones, and a call comes through. The phone is smart enough to realize that it should still ring the phone speaker because you may not actually have the headset or headphones plugged in. But it does not extend that same level of intelligence to other notifications, most obviously text messages --- but I think also Skype or Viber calls.
    Reply

Log in

Don't have an account? Sign up now