Developers are starting to distribute binaries that will run on Intel-based hardware as well as PowerPC Macs. This will add about 30% to the size of the executables. To recover the disk space, you can remove the unneeded code using the command-line program ditto.

For example, suppose Foo.app is a fat application bundle installed on a PowerPC Mac. While logged in as an admin user, you would open a Terminal window and type something like:

Now you have a new application called Foo-ppc.app. Test it. If it works, you can delete the original and rename the stripped version. To strip PPC code from binaries on an Intel Mac, you would change --arch ppc to --arch i386 in the above command.

In case it's not obvious, keep in mind that this operation is not reversible. Once you strip the code for a particular architecture from a multi-architecture executable, it will no longer run on that architecture. So keep a backup copy.

No, 30% is probably a very pessimistic guess - the additional size depends on the way the program was written and can be as low as only a few kB for several MB apps.

Also, you should probably keep in mind that this might break application updates - don't come screaming back claiming "update xxx broke my system/application" after you have been doing this - developers tend to assume (probably rightfully so!) that the user does not screw with the binary application/package!

Only for the actual binaries
Authored by: llahsram on Aug 17, '05 12:44:08PM

Just to clarify: the only files that see an increase in size are the binaries inside the app bundle. Many of the files in a given app are images, .nib interface files, sounds, configuration, etc., and those won't increase.

The Safari bundle on my machine, for example, is 20 MB. But the actual binary in Safari.app/Contents/MacOS is only 1MB. If this were a Universal binary, this might go up to as much as 2MB -- but that's only a 5% increase (worst case) in the total application size.

Unlikely, the actual code bit is usually quite small. Even in the executable file, text, constants, symbols, etc are big; not to mention the images, help, text, video and other bloat that apps usually have.

This is great for the one time one code model of a system that is not scalable. In other words once your strip the binary it will no longer be universal and hence no longer scalable you will be lock into that architecture and if you upgrade you better hope they have the same chipset.

It kinda the opposite of what Apple it attempting to do with universal binaries. So keep that in mind and make backups. (Then again with the price of hard drive space these days a (guessing) 30% increase isn't too bad.)

Of course use wisely, but what is not very scalable is bin bloat as one must destribute installations across hundreds or thousands of computers - our images are often approaching 12 GB as is and adding i386 bloat could significantly expand images, and slow down distribution.

I find it hard to believe that anyone would be so strapped for disk space that they would find this solution necessary. For example, Photoshop CS2, which is a seriously large .app at 84.1MB, would be around 100MB if the 30% size increase prediction holds true. If someone had such limited disk space that they actually needed to strip out that extra 25MB, they've got bigger problems - like the fact that Photoshop probably wouldn't even start up on such a small drive. Ultimately, one could go through an average user's application folder with this program and recover maybe 200 to 500 MB. Yet even if you recovered up to 1G, that's hardly worth either the time or the risk of rendering the application useless and forcing a reinstall.

But that's different for a couple of reasons. Firstly, size; while many language bundles are small, some apps have lots of 'em making up well over half of their size; whereas for a double-binary, 50% is the absolute most you'd ever save, and it'd usually be much, much less.

And secondly, I'm unlikely to ever want to run any of my apps in Albanian! But it's actually rather likely that I'll want to move to x86 eventually.

Of course, it's up to every Mac user whether they want to thin their binaries, but unless you're certain you'll be sticking to a PPC Mac even when they're extinct, I'd think carefully about trading a small bit of disk space now against major headaches when you come to switch.

My Applications folder is 8 GB, a 30% increase would be 2.4 GB. Still it probably would not be worth the effort, maybe doing it for just a handful of the biggest apps might make sense.

However, for all those people worried about the eventual switch to MacIntels, it would probably be wise if not even right out necessary to do a new install on the MacIntels anyway.

I very much doubt that cloning will work (for that OS 10.4.6 would have to be a fat binary). Reinstalling the OS and then copying the Applications folder is something that might work, but I would not recommend it even now (cloning plus Archive and Install seems like a better solution).

You wouldn't saved anywhere near 2.4 GB on a 8GB application folder. It would be 30% of the executable size, not the entire .app directory. In most applications the executable size in 1/2 to 1/10 the size or less of the entire .app directory. You would probably save closer to 600MB rather then 2.4GB.

If you have games (Warcraft, Diablo ect) or applications like iDVD that have a huge amount of data in the .app package you might only reduce the size on those by a couple percent. iDVD takes 1.5GB, but the executable is only 3.5 MB. You might save 1.5 MB there, and maybe a little more on the frameworks, but those are small. That's about a 1% reduction in size.

So, if I understand well, to make some free room you have to erase a portion of universal binaries program and keep a normal copy. That's sounds nice except that you increase the room by 70%, not decreasing by 30%.
:-(

While to can still use the --rsrc argument with Ditto, there is no need to do so with Tiger as it is now the default setting (unless you have the enviromental variable DITTONORSRC set). There is also a --norsrc switch as well.

The difference is lip -thin ppc will remove i386 and ppc64 if present (i.e. also killing any G5-optimised version) while lipo -remove i386 will leave ppc and ppc64, and any other architectures that are present.

Note that the space savings are only from the executable files, not the entire application bundle. For apps like Keynote or iDVD this frequently isn't noticeable since so much of the size is due to platform-independent resources (graphics, localizations, etc.).

here's another implication - you may also trim down the spotlight index by trimming out the code not needed...

And when you are running on i386 you may equally need to trim out the PPC code, eh?

I do hope not too many updaters will trip on missing code <sigh> but I suppose it could be worked around by fresh install, fresh patches, then trim and then copy out via ARD or similar.... might actually be worth trustworthy in anycase....