iMessage is one of the new features that came with iOS 5. It was one of ten features unveiled on stage at WWDC’11. But it’s one of those features that you don’t need to set out to use. This is because iMessage —at least for iPhone— is blended in with the Messages app and is automatically used whenever the person you are trying to message has an iOS 5 device with iMessage enabled1. Though, once you do get to use iMessage, you will realize how much more of a joy it is compared to SMS: it’s fast, it supports delivery (and read) reports, and it does this all well within the time it takes to send a regular SMS text message.
Because iMessage is such a clean and easy way to communicate, I found myself using it far more than I had ever used SMS. I quickly started using it as a replacement for typical instant messaging communication. It was during such use that iMessage started showing some of its, at times annoying, limitations:
- Notification overload
- Recovering from offline time
- Starting a new iMessage message
1. Can you hear me now?
In the Messaging app every incoming message triggers a notification —the text tone alert and a vibrator buzz. This is less of a problem if the app is left open and your phone’s ringer is silenced. However, depending on your Sounds settings, you will still receive a —somewhat audible— buzzer alert even when your phone is silenced. This alone has the potential to drive you, and the people around you, crazy during a lively conversation.
But it gets worse. iMessage supports message synchronization across iOS devices. This allows you to start a conversation on one device, and pick it up on another exactly where you left off. This works great in theory, but in practice it’s based on a rather naive implementation.
iMessage is expected to be leveraging Apple’s XMPP infrastructure to deliver every incoming message (and outgoing message) to every other iOS device that is set up for iMessage with the same Apple ID. Whenever an incoming message is delivered, it triggers a notification —the text tone alert and the default vibrator buzz— on each device that is set up this way. This behavior is desirable in case of a new message. However, once you have an active conversation going on a device, every subsequent incoming message keeps on triggering all other devices as well.
This explanation is even a simplification of the reality. An incoming message does not trigger a notification alert, if the message has been read, and has been registered as such with iCloud, before it arrives at the other devices. This sometimes happens when the conversation is open on the faster iPad 2 and the iPhone 4 is locked. It seems that in this case, both the ‘new message with id A’ as well as ‘message with id A read’ arrive at roughy the same time. In which case the iPhone’s display might light up, without any visual or audible notification.
Short of constantly silencing all iOS devices and frequently toggling the vibrate option in silent mode on the iPhone, there really is no way to make this experience any less annoying. However, this led to a few missed calls and unnoticed messages as I would often forget to re-enable vibrate and leave it in silent mode.
A solution for the notification overload could be the introduction of the concept of an active conversation. A conversation is active if the Messages app is opened and the device is unlocked. Whenever a conversation is active, notifications are adjusted accordingly. Only the active device will receive a minor heads-up of a new message. While other devices just keep up with this conversation without any visible or audible alerts. The former change is a relatively easy local change, while the latter requires server-side adjustments. It would be my guess that the limitations I describe here (and in point 2.) are the result of Apple keeping the protocol exceedingly simple and generic for its first release, both on the side of the device (uniform notification) as on the server side. In any case, it’s futile to reason about what they could do differently server-side without a basic idea of their messaging architecture.
2. Message in a bottle
Then there is the issue of the iOS device that was out of network range, or in airplane mode. What happens when such a device reconnects and needs to sync the conversations that took place when it was offline? I was able to record this video with the iPad camera of my iPhone about halfway through the sync process. Earlier in the evening I had put the iPhone into Airplane mode2, because it was buzzing along with my iMessage texting. When I was ready to go to sleep, I disabled Airplane mode and was on my way out of the living room when I heard the massive stream of notification coming from the iPhone. I rushed back in, unlocked it to the Message app, picked up the iPad and started recording.
This video shows a massive stream of text messages that are limited to the messages and images of my messaging contact. I could tell that these messages are not necessarily received in the correct order and that the images are all packed together at the end. The video doesn’t show that a short time after the syncing process had completed, the Message app inlined the conversation with my own messages and images and put them in the correct order.
Clearly, this way of handling iMessage synchronization when recovering from network interruption is far from ideal. Which leads me to believe that it is something Apple is bound to fix in a later release. Messages that have already been read, seem to be marked that way in iCould. That’s the reason you don’t need to re-read a single message on all devices. However, the incoming event notification does not take this read state into account, or its read state is not send as part of the message itself, resulting in an alert. In any case, it is clear from observing the synchronization behavior that a control message exists for marking a text message as read that is separate from the text message itself.
3. Hold the phone
If a contact starts an iMessage conversation with you by addressing it to your phone number, the messages you exchange show up exclusively on your iPhone, and not on any other iOS device. Given that iMessage is an SMS alternative, it wouldn’t surprise me that the phone number is commonly used to address a contact. Making this a rather bizarre shortcoming. On the other hand, sending an iMessage from an iPad to a phone number works as expected. Strange indeed.
On the flip side, it is impossible to type or otherwise select an email address for a contact in the To-field of the New Message screen. Although it is possible to paste in an email address, or choose to send a message to a contact’s email address from within the Contacts app.
A better messaging service
With iMessage, Apple wanted to build a better version of SMS. With this goal in mind, I believe it succeeded in doing that for a number of reasons:
- iMessage delivers text messages a lot faster.
- iMessage works on all iOS 5 devices and requires no configuration at all.
- Messages are synced across all owned iOS devices.
- Messages can be of arbitrary length, instead of just 160 characters.
- Support for images out of the box, without carrier complexities (MMS).
- Support for delivery and (opt-in) read reports.
- Automatic fall-back to another messaging service (SMS).
- Works over data and WiFi.
- Messages cost a fraction of what carriers charge for SMS.
Each advantage on its own would be a great addition to SMS. Add all of them together and you blow it out of the water.
SMS has quickly grown into a massive cash cow for carriers all over the world. As is typical for a profitable product, the continued investment in keeping or expanding its profitability, stifles all innovation. That is why SMS text messaging hasn’t changed at all in over 10 years. This is especially damning given that the protocol was not designed with such use and volumes in mind. This allows newcomers as RIM and Apple to swoop in with an alternative messaging platform that is an improvement in every possible aspect, except one: openness.
Both RIM’s and Apple’s messaging service are closed off for devices of other vendors. For many reasons, it is highly unlikely that either of these networks will be opened up. For one, such a seamless and cheap service helps sell devices —at least in Blackberry’s heydays. But more importantly, it keeps control of the service in the hands of the vendors. For Apple this means that the user experience is fully determined by Apple itself. Sending an image will never fail because another vendor has shipped a client that does not fully respect the protocol for handling images. It just works3.
iMessage already is a great SMS alternative, but I hope Apple doesn’t stop there. iMessage has the potential to be a great instant messaging service too. If Apple does not open up iMessage, I hope at least it is considering to extend support to the Mac, similarly to what it did with FaceTime.