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 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 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


View All Comments

  • windywoo - Tuesday, October 18, 2011 - link

    That article is a prime example of what I'm talking about. Subjectives passed off as objectives. Until recently the android browser was ahead in any benchmarks yet he claims it's slow. And in any case, Android gives a choice of browser if there are any rendering errors. Safari is not without its own flaws, and when it does go wrong you're stuck, because Apple doesn't allow other browsers.

    He finds Widgets useless, but doesn't appreciate that other people might not and Android allows them the freedom to spend battery juice on trinkets like live wallpaper if they so choose. Why is it that Apple users always consider it an advantage to have Apple make decisions for them and will pay over the odds to be nannied?

    The market argument is almost entirely irrelevant. Let's leave aside the fact that he can't have looked very closely if he thinks there is no software on the Android market, the same argument used to be addressed at Macs. Apple fans would claim then that the quantity didn't matter so long as the major functions were there. Apps are a con anyway. If consumers weren't so gullible, many of them could be written as web apps, making platform irrelevant. But consumers are dumb. They like being fed nuggets of code like junk food.

    He lists the good things at the end so why does he consider them less important than what he sees as faults? The answer is of course, fawning subservience to the mighty Apple.
  • Phynaz - Tuesday, October 18, 2011 - link

    Who told you Apple doesn't allow other browsers. I've tried at least three alternatives, and my current browser is Atomic. Reply
  • name99 - Friday, October 21, 2011 - link

    Let me just point out that obsessing about numbers can be counterproductive. Let me give you an example:

    No phone reviews (yet, anyway) measure the speed of the file system, the speed of launching apps, that sort of thing. But we all know from desktops that, for most purposes, what makes a machine feel fast or slow is not the speed of the CPU, it is the speed of the disk.

    So, suppose one is using a phone where most of the storage is an SD card (which are, or at least can be, quite a bit slower than the internal flash storage iPhone uses). That's not going to show up in benchmarks like Linpack, or Sunspider, or how fast the GPU is --- it's not going to show up on ANYTHING that current reviews benchmark.

    Now, does this make any sense? The single most important determinant of perceived performance is not being mentioned? You can either close your eyes and say "la la la, I don't care", or you can face reality and accept that slowness in IO leads to general complaints about "feels sluggish".

    And, look, it is STUPID of Android fans to ignore these complaints. Presumably you want your phones to feel fast, right? So what is more likely to get manufacturers to install faster flash in their phones?
    - a bunch of people saying "what performance problem? The speed of our phones is perfect in every way. Heck, don't change anything ever"
    - a bunch of people saying "yeah, the phone is nice in a lot of ways, bnut damn it feels slow when I perform the following operations"
  • _tangent - Wednesday, October 19, 2011 - link

    That blog illustrates Apple's greatest achievement in technology: convincing people that choice only serves to complicates matters. The browser comparison is a perfect example. There are browsers available which perform far better than the stock android browser. On an SGS2 (7 month old handset), firefox comprehensively beats the new 4S is JS benchmarks. Yet the blogger behaves as if visiting the market and downloading a third party browser is a complication too far for the average smartphone owner.

    I wish people would stop evangelizing the dumbing down of technology. There's nothing wrong with engaging your brain a little to get the best out of your tech. Too many people are bought into Apple's belief that we're all a little too stupid or too busy to think. iOS is to technology what pop is to music: instant gratification for very little investment of time or effort. But ultimately the same rules apply to everything: you get out what you put in. And on that topic, the author of that blog can't have put much effort at all into looking for apps, because i have never struggled to find quality games/widgets/etc on the android market.
  • kylewat - Monday, October 24, 2011 - link


    I believe you represent the worst in IT evangelism. The reality is that simplicity is what people want; and choice does serve to complicate matters. It is probably hard to understand how complexity makes things harder because it allows people to get involved. When people get involved 'complexity' creeps in. It's very difficult to fight. Apple's achievement is getting rid of complexity.

    How often does a good project good bogged down by feature bloat? You go to a certain new product because it is sleeker and simpler, yet does everything you want. Then someone starts adding 'features' and a few years later the product is slow and complicated. Someone has started making a new product that is small and fast.

    This is what enabled Apple to enter any market they have entered. The mp3 market was complicated; iTunes made it easy to share music (especially on university campus' for anyone who was alive in the early 2000s.) and the iPod caught on.

    The same thing has happened to basically every major invention. Over time, simplicity and best practices trump 'choice' which allows people to get in the way.
  • steven75 - Monday, October 31, 2011 - link

    Do you know what my friend's favorite thing about switching from Android to iPhone is?

    How much better the browser is.

    So much for benchmarks, eh?
  • TEAMSWITCHER - Tuesday, October 18, 2011 - link

    Products like smart phones, tablets, and computers are multi-faceted beasts. An overall evaluation of each is what reviewers typically strive to determine. Apple is not perfect by any stretch, but taken as a whole the products are quite good. What you perceive as media bias, is actually just Apple making great products. Reply
  • windywoo - Tuesday, October 18, 2011 - link

    No, what Apple make are products which are simple, and pleasing to the eye. They "just work" because they restrict the user in how much they can do, and therefore limit the amount of mistakes they can make.They usually trade off on other features such as customisation and flexibility. Then they add in the missing pieces as they go along. Why is this Apple method so beloved of reviewers? Why handle them with kid gloves for such obvious flaws that have just now been fixed? No-one applauds Fisher Price for simplifying things. Do Apple really deserve such praise for putting stabilizers on a bike and then taking them off when their users are suitably indoctrinated? Reply
  • tbutler - Tuesday, October 18, 2011 - link

    Because, just maybe, Apple designs products primarily for people who are willing - and often even *happy* - to trade maximum customization and flexibility in return for simplicity, fewer hassles, and limiting the possibility for mistakes? Heck, I've been using computers since the late 70's and consider myself a fairly experienced user, and I still like having a platform I can just pick up and use with a minimum of fuss.

    To answer a point further upthread: Benchmarks and feature checklists are suitable metrics for people who view benchmarks and feature checklists as the primary reason for using a platform. For those who think UX trumps raw performance or features*, not so much. And how do you quantify UX?

    *(A feature with a UX that makes it more trouble to use than the benefit you get from the feature is a null feature in my book.)

    For example, let's talk about the PlayBook, which I was able to grab for $200 recently. To back out of an application and return to the launcher/task switcher, you swipe up from the bottom of the screen. This leaves your finger in a good position to either swipe between apps, or tap an icon to launch. Offscreen controls are typically located in a toolbar you reveal by swiping down from the top of the screen; again, the gesture leaves your finger in position to do what you want.

    Compare this to Honeycomb, where the home icon and app drawer controls are on complete opposite corners of the screen; the same sequence requires going to the lower-left corner to return to the home screen, upper-righte corner for the app drawer, then back to the center to select an app.

    One platform feels fluid, with one action naturally leading into another; the other feels interrupted, with your finger jumping all around the screen. How do you reduce this to metrics for a review? Measure the number of inches your finger has to travel across the screen?
  • Daniel Egger - Tuesday, October 18, 2011 - link

    I have just read the one linked article and I must say I have to agree quite a bit save for the "Sharing" experience. I do have a Gingerbread phone and only an iPod Touch on the IOS side (besides my main phones are a Palm Pre for the "business" stuff and a Nokia 6310i for the phoning part).

    The Android phone, while allowing for a hell of flexibility, just feels clumsy compared to the other smart devices: animations are not fluid, the UI of all non-Google applications feel like design by blender; about every single app looks vastly different and most don't provide any classy feel, save for Wunderlist, which must be the most wonderfully crafted Android application out there.

    Apps get swapped out erratically while other uninteresting tasks stay in -- why the heck does CSipSimple get swapped out several times a day while Maps launches itself? Managing running apps is a royal PITA on Android while it is supposed to be a "don't care".

    The Android market is utterly swamped with crap; it's about impossible to find decent apps and even more so without annoying ads all over the map. There really needs a separate right "Displays Ads" rather than "Full internet access". Also the market is not really helpful in finding good apps compared to the App Store. I've literally hundreds of very good apps and games, about 90% of which didn't cost me anything, on the iPod while I'm really struggling to hit 10(!) solid ones on the Android device.

    Then there's the standby time. The Pre and the iPod have SIP accounts XMPP registrations over WLAN up for over 2 days, the Pre even with UMTS on. The Android phone will need a recharge after less than one day, without cell or GPS reception on yet it has the largest battery of all devices.

    Then there's usability issues, maybe caused by vendor modifications (but fragmentation is also another con rather than a pro), like when you plug in USB while the phone is locked is will display the USB selector but you can't select anything until you use the hardware buttons to get to the hidden lock screen and disable the lock first...

    I was about as psyched to get the Gingerbread thingy as much as I was to get the Pre and and my iPod but I really hoped for a *lot* more than I received. There're so many inherent problems in the Android platform that I'm certainly not going to let me lure into trying Android another time soon...

Log in

Don't have an account? Sign up now