Paul Lynch's Pages

I’ve just finished the first stage of one app port to iOS 4. I have to say that it has been a very rocky road, with the first announcement and beta some months back, followed by the very late announcement of iPhone 4 at WWDC. Let’s look at the timings and implications… and I’m going to use the expression “paradigm shift”, for which my apologies…

The first announcement and beta was, and I forget, probably in January/February 2010. From the developer standpoint, or at least this developer’s standpoint, it wasn’t big, and can be summarised in one word: multi-tasking. There was some mention of high resolution, but a quick reading made that seem like something for external displays, not new iPhone devices.

Then the second part, high resolution displays aka Retina, was announced at WWDC on 7 June – just two weeks ago. With the SDK available to us at the end of WWDC (ordinary mortals who can’t afford to go to WWDC and endure the queues), and the surprise announcement of iOS 4 available 21 June (today), and add to that Apple’s typical delay on accepting updated app submissions (2 days minimum at good times, we’ll see what it is now): that adds up to really short notice. Just for me, I’ll add to that the issues of getting a zillion icons redrawn at what is effectively no notice, and it leads to a world of pain.

Multi-tasking support splits into two: every app gets for free, with no code rewrites, “fast app switching”. This is great news, as it means the old kludgy idiom of saving state on termination and reloading on launch (which very few developers bothered to do, even within Apple) isn’t really required any more. But the second part, background running, is doubled up with trying to figure out Apple’s implementation of blocks, which is so simple and transparent in, say, Ruby. In a way this is a good thing, as it keeps Flash developers from stealing my CPU cycles. But it’s still a pain.

OK, so on to the real implications, which are quite interesting. Let’s skip over multi-tasking support quickly, as we’ve know about it for ages. First point, and it’s a big one: iPhoneOS is a multi-tasking, Unix derived, OS. OF COURSE it supports multi-tasking, always has, and a lot of the meaningful multi-tasking has been done for you and works (Mail, Safari, etc). This is a clever trick that lets your old apps work, by forcing most of the developers to get used to resource hungry apps being shut down forcibly. That’s good for users. So the second point is an easy one: we get multi-tasking without Flash, and without resource hogs. Back to the main issue.

MacOS X, and the operating system that it derived from, NeXTSTEP, was resolution independent. Developers were used to drawing independently of the screen, using points, not pixels. iPhoneOS made the crude assumption of pixels, which locked us all to the screen dimensions, and have made universal iPhone/iPad apps a trial to support. Part of the reason was a desire to minimise resource requirements, which was laudable. Plus part was the poor resolution of old displays (72 dpi? I haven’t checked). At that resolution, you see pixels, and you are obliged to develop icons that use anti-aliased pixels, or are highly aware of pixel boundaries. Look at the famed famfam icon set, which is 16 by 16, and succeeds brilliantly, even when doubled up; it works because the designer is aware of pixel edges, and works within those restrictions.

This all means that we are forced to abandon bitmaps for icons and application images, and it’s about time! Unfortunately, most available icons out there on the Internet haven’t made this shift, and good programmers don’t make good graphic artists (and vice versa, to state the obvious corollary, which isn’t apparent to everyone). Some will head for Adobe Illustrator, and it’s a good tool if you can afford it; I’ve switched to svg (and am using Inkscape for now). This is a massive paradigm shift (sorry), and it’s going to make big waves.

So what about photographic images? These aren’t really a problem, as they come in extremely high resolution already. The important point here is that photos will be sampled down for display on screens, whereas icons have to be sampled up (to increase their resolution), and so won’t require so much adjustment for anti-aliasing, once we get away from the extremely low resolution screens that we have been using.

This is a massive change for developers, and is causing a lot of pain as we adjust our workflows and, in most cases, completely redevelop most of our stock image libraries. Very little of which effort will be visible, unless you start to examine an iPhone 4 very, very carefully indeed. The resolution change, when well implemented, will seem imperceptible – but in reality will have a massive effect, getting us away from blocky, pixel based images.