Warning this article may contain opinions of the author that you and iTWire don't necessarily agree with. Don't let them get away with it - have your say with a comment!

No. 1 Story

Construction needs cloud flexibility

Australia’s embattled construction sector could benefit from cloud based information systems that can be switched on and off in lockstep with individual projects – with the exception of those organisations based in remote areas like the Kimberleys.

read more

iTunes 10's Automator issues indicate a deeper problem

Opinion and Analysis

The compatibility problems between iTunes 10 and existing Automator actions and AppleScripts for iTunes may be symptomatic of a deeper issue at Apple.


My recent article Training the key to avoiding software security flaws presented the opinion of Rocky Heckman, senior security architect at Microsoft, that training is the best approach to reducing the incidence of common programming errors that make software vulnerable to attacks.

Over the weekend, it occurred to me that functional problems are also being caused by programmers making the same old mistakes.

This thought was triggered by complaints that iTunes 10 (released late last week) breaks Apple's own Automator support as well as many third-party AppleScripts.

The problem, it turns out is not that version 10 does anything differently to its recent predecessors, but that the programmers who created the Automator actions and AppleScripts didn't know how to test for the version number of the application they were supposed to be supporting.

Well-written scripts and actions will check the version number of the host software in case someone tries to use them with an old version that doesn't include an essential feature. For example, the Add Songs to Playlist action checks that iTunes is no older than version 4.6.

The problem is that version numbers aren't actually numbers.

That seemingly contradictory statement is explained on page 2.