The tool is (aptly) named iPhone Icon Tester and is hosted on GitHub.

The code should be self-explanatory, but I’m happy to help if you run into trouble; just shoot me an email.

Apple has made it just as simple on the iPhone:

I participated with my homepage, AbrahamVegh.com.

View the source for all of the sweet little details — everything is neatly laid out there for your dissection pleasure, but please be sure to read and respect the notes at the beginning of the file.

Previous versions:

• Version 1: http://abrahamvegh.com/v1
• Version 1.5 http://abrahamvegh.com/v1.5

For this blog, SiteSprint 3 will be its moment to shine.

Ciao for now.

Guess what? All those people who originally “widely reviled” the “feature”? They were right!

This is how enabling the mode can completely destroy your existing workflow:

The most important fact to realize is that single-application mode is tied exclusively to the Dock. This means that if you click an application’s icon in the Dock, it immediately hides all the other applications, including the Finder.

Read that again to grasp the full effect (emphasis mine). If you click an icon to switch applications (assuming you use the mouse for such mundane tasks), every application, including the Finder, will have their “Hide” (Command+H) function triggered. What does that mean for you and I? Well, let’s see:

Single-application mode in Mac OS X

In this screenshot, you can clearly see the behavior in effect. I’m using a 2D Dock and a small hack to make hidden applications less opaque so they’re immediately identifiable. When I clicked the Firefox icon, all of my applications hid themselves. That would be great, but for the fact that if I try to hide Firefox too, guess what happens? Nothing.

And nothing is a problem. For starters, it leaves me scratching my head, wondering why I can’t hide this application. Then, once it dawns on me that OS X for some unknown reason restricts you from hiding all of your open applications at the same time, it leaves me scratching my head again. During normal use of OS X, you’d almost never notice this little bug. That’s because I can think of exactly nobody who would try to press Command+H while Finder is focused. But with single-application mode, it becomes readily apparent, and worse, impedes your workflow until you can figure out why that doesn’t work.

But wait, we’re not finished yet! Directly below the paragraph I quoted before are these two gems:

However, if you switch applications through any other method, including clicking another visible application’s window and the Command-Tab application switcher, Mac OS X’s normal multi-application approach remains in effect, and nothing will be hidden. You can thus combine methods of switching between applications. Click Mail in the Dock, then use Command-Tab to switch to Safari, and you’ll end up with both Mail and Safari on screen, and nothing else. If you later want to hide Safari again, click Mail’s Dock icon (or just Option-click on Mail’s window).

So, let me get this straight: This will sometimes work, sometimes confuse me, but always require me to think about how the windows and applications I’m using are arranged, so that I can be more productive? Thanks, but no thanks.

In short my friends, you don’t need Mac OS X’s single-application mode.

I was also happy to find that on top of all the other enhancements in 3.1, Safari, the web browser on the iPhone, learned one small new trick.

You can now close all of the “tabs”:

One of the easiest additions for Apple to make to the iPod touch would be a built-in microphone. The ability to add an external one has always been available, with the 3.0 software update making it all the more simple with the addition of the Voice Memos app, but it would be a smart move for Apple if they added the hardware to the touch, making it an ever more complete “iPhone without the phone.” It would enable countless VoIP applications like Skype for the huge market of iPod touch owners, along with the innumerable other uses provided by app developers.

Since early this year we’ve been seeing reports of iPod touch cases with a cut-out for a camera. I think those rumors are true, and we will definitely be seeing a camera (hopefully a video-enabled one) on the next iteration of the device. Apple could very well just not do it at all, but it makes sense as a logical progression of the product. Also, adding a video camera would obviously require the addition of a built-in microphone.

Something else I expect in the next iPod touch is speedier hardware. It’s also a logical addition: the current model was a subtle (and by most approximations, successful) bid by Apple for a piece of the casual mobile gaming market. The current revision boasted some amazing specs for a non-phone mobile device when it was released last year, but now that it has been superseded in that respect by the iPhone 3GS, I expect Apple to improve it to either match or exceed the capabilities of the 3GS. That would come in the form of more RAM, and/or a faster processor; hopefully, both.

Finally, one feature that I am hoping for, but not holding out for: the addition of an A-GPS chip (or even a full-fledged GPS chip, although they’re unlikely to do that for battery-related reasons). Together with the better hardware and camera, this would cement the iPod touch as a the only full-featured

I apologize for only talking about the iPod touch, but that’s the only device in Apple’s current iPod lineup I think has more than a five-year future ahead of it. That said, I would be very surprised if any of the other iPod models receive a camera, and that would definitely cause me to rethink my opinion of their longevity.

All said and done, I think everyone is waiting and watching with baited breath for Apple’s next move. They are a market leader, an innovator, and fanboi or not, they deserve respect for what they have accomplished, and what they are bound to accomplish in the future.

Oh, and one more thing: I strongly believe that Steve Jobs will be making his triumphant return to the public eye at this event.

Normally when I am being hired to code something, the client doesn’t know a thing about how the code works. So when they call to complain about a bug, my first reaction is usually, “what did you do to it?” (not that my code is perfect, but I stress-test the hell out of code before delivery)

Naturally, since I was paid to deliver the code and it was now broken, I promised to deliver a fix immediately. My first step was to load up the production version of the code as it would be presented to the end-user, and test it.

It failed.

My next step was to enable Firebug so I could monitor what was going on behind the scenes. As soon as Firebug was active, the problem seemed to disappear. The code seemed to be working perfectly. I refreshed, cleared my cache, and the code still continued to work just fine.

I called the client back, and explained to him that it must have been a fluke of the server or something else, and not to worry about it. Several minutes later, the he called me back again, claiming it was still broken. I immediately loaded up the page again, with Firebug now disabled, and once again it inexplicably failed.

Are you seeing the pattern here?

Seeing as there was something fishy going on, I decided to review the code thoroughly, all thirty-odd lines of it. I moved some things around, fixed what was a quick hack to originally get the job done faster, and tested.

Nothing.

This particular code (the part giving me the trouble) was a piece of jQuery-flavored JavaScript, performing a bit of AJAX magic. I racked my brains and the code, trying to figure out what the problem could be. Then it dawned on me.

I’d forgotten one of the most basic tenets of writing code: Error checking.

As I expressed immediately after discovering my problem, this is a very easy but stupid mistake to make. I’d forgotten to remove the debugging code for sending a message to the Firebug console while developing. This made it work just fine in the development environment, and equally fine while trying to figure out the problem, but it never occurred to me to check the Firefox error console.

Lesson learned: Write code, check, double-check, repeat.

End of line.

It is rather startling to see the ease with which the blogger media and the iPhone community have accepted these claims as absolute truths. The iPhone 3GS is far more powerful than the 3G — without a doubt. But the benchmark we need to be looking at is the comparison between the iPod touch and the 3GS.

A brief history: The original iPhone shipped with a CPU capable of 620 MHz, underclocked to 412. It also shipped with a relatively low-powered GPU, the PowerVR MBX Lite 3D. After the original iPhone came the iPod touch, shipping with the same processing hardware. Apple then upped the ante last fall, with the release of the second-generation iPod touch. It contains a 620 MHz CPU, clocked down to 533, which is still a noticeable increase over the iPhone/3G. Also of note is that until the arrival of the 3GS, every device model contained a paltry 128MB of DRAM — the 3GS ups that to 256.

Now, you’re probably wondering why I skipped right over the iPhone 3G. It’s fairly simple:

With regard to hardware performance, there were no changes made between the original iPhone and the iPhone 3G.

Now there were definitely some hardware changes and software optimizations made for the 3G. I won’t deny that. iPhone OS 2.0 was released, with a laundry list of improvements and new features. Addition of A-GPS hardware and the 3G telephony chipset were certainly changes, and were (for the most part) improvements. But in terms of hardware performance, nothing was done.

So what am I talking about then? The second-generation iPod touch.

It contained the only performance upgrade since the original iPhone, and it was lauded as such when it was released. Since it was the current leading model in terms of performance, it is what we should be comparing the new flagship model to, and it is what we should be defining the new standard against.

Understandably, I am very much in doubt of these dramatic claims of performance increases since the “last generation” of devices.

A more accurate benchmark in “new” performance increase would be a comparison between the iPhone 3GS and the second-generation iPod touch. Fortunately, Daniel Pasco over at Black Pixel was kind enough to do just that, and his results support my arguments:

the iPhone 3G S ran about twice as fast as the 2g Touch in every test

Interestingly enough, according to his post, he is running his tests using the same code base which Casasanta tested on the iPhone 3G — development builds of Tap Tap Tap’s upcoming Plasma application, so we can say with certainty that comparing the two tests are “fair” (although that is not really what we’re aiming for either way).

In addition, Pasco ran some CPU benchmarks to see how much of the performance increase came from the CPU:

In these tests the 3G S comes out about 20% faster than the 2g Touch. Given that the clock speed of the 3G S is only about 12% faster, there is definitely some extra oomph coming from the upgraded processor architecture, but I think it’s pretty clear that the PowerVR SGX’s contribution to our performance increase is substantial.

In conclusion, while the iPhone 3GS is clearly once again redefining the standard for capability on a mobile device, it is only marginally so, and certainly not as dramatic as everyone would have you believe.