Universal binaries: They’re a Good Thing

The authors at NodePoint.com claim they “provide Macintosh support services to high-profile clients”. On their website, they write mostly about newly released software, with the occasional instructional material, and even more occasional opinion piece. One of their recent opinion pieces complains about Apple’s “universal binary” applications, where one double-clickable application can run on both PowerPC- and Intel-based Macs

For starters, the Universal binary is larger than a single-architecture binary, so it takes longer to download and takes up more space on a CD or DVD disc, as well as more space on your hard drive. Most of that extra file size is never going to be used, so it makes no sense to include it. Even if it were on a CD or DVD disc, most End User License Agreements limit you to installing it on one system, so you only need the version for your machine.


It would be easier for users if developers created two separate binaries for Mac OS X: one for PowerPC- and another for Intel-based Macs. Downloads would be smaller, and thus faster, and users would not be forced to use up finite disk space with code that is wholly incompatible with their system.

While it’s true that a universal binary is, by definition, larger than a single-architecture binary, claiming that the longer download, additional space on a DVD or a limitation of a EULA are reasons not make universal binaries, is ridiculous.

First of all, most users don’t care what their processor is. They buy a computer to accomplish a particular task, and whether it contains a PowerPC, an Intel or an AMD chip doesn’t generally enter into the equation. And when those users buy a new computer, they expect their existing software to Just Workâ„¢. This is, of course, especially true of Macintosh users, who have come to expect that things Just Work.â„¢

Moving from a 12″ PowerBook to a 13″ MacBook, both running Mac OS X 10.4.8, should mean a user should be able to copy her files over to the new machine, double-click an application, and have it run, preferably as fast as the system allows.

Universal binaries allow this to happen: when I made just such a move (to a “BlackBook” to be exact), I merely copied the files and applications I needed over to my new machine, and, since the vast majority of them were universal binaries, they ran “natively” on the Intel chip.

This is what users expect. They don’t want to think “which processor am I running?” before downloading or updating to a new application. Forcing that decision onto the user is stupid, and it’s not necessary.

Secondly, the “lost” drive space is relatively minor in comparison to the size of files that are required. Much of an application is in its various resources (like icons, sounds, templates, etc.) and these resources generally don’t change between hardware architectures. Having multiple versions of the application can actually increase the size of an application. The author gives the following example:

Let’s take a look at Final Cut Pro 5.1 for an example: It’s a Universal binary, which takes up 73.7MB when installed. Removing the excess Intel-based code using Trim the Fat, takes out 16.89MB.

Let’s do the math here: a universal binary takes up about 74 MB. A single architecture binary (say, for PowerPC) would then, by the author’s reckoning, be about 57 MB. An Intel-based version would therefore also be about 57 MB. That means the developer would have to put up two files taking up 114 MB instead of one file taking up 74 MB. That’s more than 50% more space being taken up on the developers’ side! And, of course, the user will first have to download 57 MB for use on her PowerPC-based Mac, and then, when she upgrades, download another 57 MB to use on her Intel-based Mac!

Plus, on a CD or DVD, that would also mean wasted space, unless there is an expectation that developers will be selling one box for PowerPC-base Macs and another box for Intel-based Macs. Talk about wasteful!

How in the world does dumping universal binaries make sense?

Thirdly, while an EULA may prevent you from using an application on two computers at the same time, most developers have no problem with you migrating their application from one computer to another, assuming you don’t use it on both computers. No EULA I’ve seen stops you from doing this migration, and some EULAs actually give explicit permission to use the application on multiple machines (e.g. home and work) as long as they aren’t being used simultaneously.

And finally, the topper on this entire thing: Apple specifically encourages developers to release universal binaries! Way back in January 2006, Apple said

Providing support for both architectures in your application is essential, because the Mac OS X platform will support both architectures for years to come. And the time to start making the move to universal binaries is now.

Apple’s reasons for this is clearly stated: “the Mac OS X platform will support both architectures for years to come”. Don’t make users think about processors when buying software, just Make It Work.â„¢

The author’s arguments appear to be based on a complete lack of understanding of the technical, business and marketing issues involved, and the arguments for eliminating universal binaries don’t hold an ounce of water.