Over here at Airsource, we're not exactly retro, but we do care about computing resources, especially bandwidth. We like small sleek applications that perform well, not applications that use excess bandwidth, and run twenty times slower than necessary. With that in mind, I picked a relatively simple iPhone application that displays a currency exchange rate and a graph of recent historical movement, and measured its bandwidth usage. The results were amazing.

It started by uploading 16KB of data, and downloading 136KB. To be fair this is the ad-ware version, which includes an advert image - but that's only about 30KB. That still leaves 106 KB of data to render a graph. In addition, every time it downloads a tick update, it sends 8KB and downloads 34KB of data.

Airsource recently wrote an application that encoded graph data for share price movements in an SMS. That's 140 bytes of data. By that metric, Bandwidth Hog should be providing that is 775 times more accurate. It isn't. Presumably it is downloading an image of the graph instead of fetching the price data and then rendering the graph in code.

Why is this bad? After all, the iPhone contract includes an unlimited bandwidth contract. Well, here are a few reasons:

• There are plenty of users out there who have unlocked their iPhones, and are on non-standard contracts, some of them with limited bandwidth. Don't you want them to buy your app as well?
• Even unlimited bandwidth is not free. It costs the operator something, and that, in turn, costs you something. If iPhone apps prove to use too much bandwidth, then the cost of the iPhone contract will go up.
• Design for users in New Hampshire. This is the Airsource version of Joel Spolsky's aphorism "Design for Extremes". When I was up in New Hampshire recently, I noticed that most of the roads, at least in the White Mountains area, run through valleys - and valleys are usually not in the line of sight to a cell base station, because something's in the way, often a very large lump of granite. Consequently the signal strength was often very low. Sometimes you got a decent signal - but if you were driving at 50mph, it disappeared pretty quickly. All this leads us the point that the less data your app needs to download, the faster it will work, and the more likely it is to work in low signal conditions.
• Upstream bandwidth is definitely not free. Every ISP I have ever known has charged something for bandwidth used by servers. Sending less data reduces your hosting costs. This may not matter to you if you have only have ten users - but it certainly will if you get to a million users.

The only conceivable reason for sending an image instead of the data is that it's cheaper in development time. That is, on the surface of it, a valid business reason; but it is not a good way to endear you to your customers, especially if they wind up paying lots to use an apparently simple application.

And finally... what on earth is this application doing uploading 16KB of data every time I run it? If it uploaded my position, a unique ID, usage statistics for the application and maybe a couple of other things, then that might cover 1KB. But 16KB? and a further 8KB every tick??? I'll be back when I've run a packet sniffer...