Thinning universal binaries with ditto

Software

In November of 2006 I uploaded a post called A Closer Look At Apple’s Universal Binaries where I tried to describe what UB's are and how to use the lipo command in the Terminal to remove unnecessary code. Since then I've learned a bit more, and have found a slightly easier way to do it.

Previous post in a nutshell: If you've used Mac computers at all since 2005 you're probably aware of Universal binaries, the fancy name Apple gave to applications that have native code for PowerPC and Intel processors. While they really simplify distribution, they store code on your machine you don't actually need.

Fortunately in Tiger Apple bundled the ditto (and lipo) utility which you can use to create a thin version of a universal binary that only contains code for your processor.

TAKE NOTE! Some older applications that are only compiled for PowerPC CPUs require shared libraries or resources from other applications, some of which may have been updated as Universal. Therefore if you start deleting PowerPC code from them, you may start braking things. If you're not sure, always keep the original universal binary just in case you need to restore it!

ditto --arch i386 FooBar.app ThinFooBar.app
ditto --arch ppc FooBar.app ThinFooBar.app

The first line thins down FooBar.app to include only i386 code, the second preserves only PowerPC code.

Shakugan no Shana
The use of an unnecessarily long sword to spit universal binaries is not recommended… unless you're a flame haze… I'm sorry, but I can't stand dry weblog posts that don't have pictures. The thought of weblog posts without pictures keep me awake at night, as I'm sure it does for you too.

Given my current obsession with tables, below is a selection of my favourite Mac open source applications I thinned down on my MacBook Pro to compare the difference between their universal and thin binaries:

Application Version Fat universal Thin i386 % original % saved ↓
VLC VLC 0.8.6c 75.2 MiB 43.1 MiB 57.31 42.69
Camino 1.5.1int 53.7 MiB 34.2 MiB 63.69 36.31
Inkscape Inkscape 0.45.1 84.1 MiB 56.4 MiB 67.06 32.94
iTerm iTerm 0.9.5.x 4.1 MiB 3.2 MiB 78.05 21.95
Gimpshop Gimpshop 2.2.11 191.0 MiB 149.3 MiB 78.17 21.83
Smultron Smultron 3.1 10.1 MiB 9.4 MiB 93.06 6.94

And here's a similar table looking at bundled Apple applications:

Application Version Fat universal Thin i386 % original % saved ↓
Safari Safari 3.0b3 6.5 MiB 5.1 MiB 78.46 21.54
iTunes iTunes 7.4.1 113.0 MiB 98.8 MiB 87.43 12.57
Terminal Terminal 1.5 5.0 MiB 4.6 MiB 92.00 8.00
TextEdit 1.4 2.2 MiB 2.1 MiB 95.45 4.55

Some pretty interesting results, the most noticeable of which I would think is that none of the applications even approached a 50% reduction in file size by removing half their compiled instructions. This is due to applications having shared resources such as images, text files and whatnot that are used by both the PPC and Intel code.

In this case, we can see that VLC, Camino and Safari had a sizable amount of specialised code, whereas the bulk of the TextEdit and Smultron applications consisted of shared resources. We can infer just by looking at these results that rendering video and webpages require more processor specific instructions compared to, say, a text editor.

Plus it gave me the chance to show some Mac icons. I use KDE on FreeBSD and NetBSD and have used all the flavours of Windows at some point, and the Mac is still the prettiest ;).

Author bio and support

Me!

Ruben Schade is a technical writer and infrastructure architect in Sydney, Australia who refers to himself in the third person. Hi!

The site is powered by Hugo, FreeBSD, and OpenZFS on OrionVM, everyone’s favourite bespoke cloud infrastructure provider.

If you found this post helpful or entertaining, you can shout me a coffee or send a comment. Thanks ☺️.