Twitter Facebook LinkedIn

Slow AT&T Network is Apple’s Own Fault

by Aaron Klein on June 22nd, 2009

I’ll preface this post by saying: Apple has some great technology. I’m a huge fan of many of their products. I love my iPod. I’m a former iPhone user and still like many of its features.

But Apple is annoyingly stubborn about some pretty important things. Among them are no keyboard on the iPhone, sealed batteries on many products, and the tendency to build closed systems (like how until recently, music you bought on iTunes couldn’t be played on any player but an iPod).

There have been a lot of recent comments about how it’s too bad that the iPhone is tied to the AT&T network, because that network is so slow. To which I say…if you look at some of the design decisions behind iPhone, you’ll understand that it’s Apple’s own fault!

The iPhone is like a computer with an Internet connection (albeit a relatively slow one). The iPhone mail program connects out to your mail server, and painstakingly downloads a list of messages. Then when you tap one of them, the mail program connects to the server again and painstakingly downloads it. The entire process takes time before you ever start reading your message.

(As a note: Apple claims to now support “push” e-mail, where the server pushes e-mail to the phone. But it’s not true push e-mail. In those cases, the server can “ping” the iPhone and say “hey, I have messages for you…come and get them.” Then the iPhone goes and pulls the message list down again.)

The BlackBerry has true push e-mail, and it gets there by having a centralized network operations center (“NOC”) that takes e-mail in from your server and then spoon-feeds it to your phone over the mobile network. The result is much more efficient use of bandwidth, and much higher e-mail speeds.

For example, when the BlackBerry NOC gets a message, it instantly pushes the first 32KB (about 32,000 characters of data) out to the phone. (Often, that’s the entire message.) So when your BlackBerry “pings”, you can instantly tap the message and you’re reading it. No delay, no connection to the server, no wait for it to download.

And as you keep reading the messages, the BlackBerry NOC keeps spoon-feeding it to the phone. So you rarely ever have to wait for it to download the rest.

Here’s another example of why this works so much better. When you move a message to a folder using BlackBerry, the message gets moved on the phone, and the phone queues up a command to the NOC telling it to move that message in your inbox. If your connection blips or you’re out of range, the command will go through as soon as the BlackBerry reconnects.

In contrast, when you move a message on the iPhone, it tries to connect to the server and send the move command to your mail server. If it goes through, iPhone then re-asks for the now-shorter message list and your message disappears on the phone. But if iPhone can’t reach the mail server, it just undoes your command and the messages pop back into your inbox. It’s just annoying.

One more. Let’s say I get an e-mail with a 6MB attachment actually meant for a designer at my company. With BlackBerry, I can hit forward, tap out a message that says “hey, here are the files — please start on this tomorrow” and hit send. The BlackBerry simply sends my note to the NOC with a command to forward the entire message on.

On the iPhone, I’d have to download the 6MB attachment, tap out my note, then hit send and retransmit the entire 6MB message. That would take 10 minutes or so, and about 192 times more bandwidth. And you’re surprised the AT&T network is getting congested?

Apple has repeatedly mocked the BlackBerry NOC, calling it a “single point of failure” (meaning of course, that if the NOC goes down, BlackBerries don’t work).

That’s true, and it has happened, once or twice a year. But I’d rather have the BlackBerry experience 363 days out of the year than have the incredibly slow iPhone experience for 365.

iPhone is still incredibly cool, but it would be far better if Apple would be a little less stubborn and focus on architecting products to cause less customer frustration.

From → Technology

blog comments powered by Disqus