Are there current slimmers to remove ARM code from new Fat binaries?

Well, it’s been a long time since we had software to slim PowerPC/Intel Binaries.

Now, we want to slim Intel/ ARM Fat binaries.

do those exist again yet?

We do? Why is that?

Well, back then the tool to ‘thin’ the ‘fat’ binaries was the tool lipo, and that tool still exists…

…however, one thing that we didn’t have to deal with before was code signing.

I would suspect that if you ‘thin’ a ‘fat’ binary these days, you’ll invalidate the signature and the app will not run.

I’m not sure there’s a significant advantage to thinning these binaries anyway… I would expect that any disk space savings would be minimal.


I’m not sure that it’s worth breaking an ARM to get slimmer binaries…

(Sorry, sorry, I’ll see myself out)


Two things make binaries “fat”:

  • Non code assets such as images.
  • Libraries.

Both contribute to iPhone apps having some of the biggest binaries going. Neither are going to be taken away by throwing away the pin (and keeping the hand grenade). :slight_smile:

1 Like

CleanMyMac currently does it for removing PPC code. I would think such a feature will come to the app to remove Intel code at some point :slightly_smiling_face:

Practically speaking though, how much savings are we actually talking about? It feels like there’d have to be pretty substantial savings involved to worry about doing this sort of thing.

1 Like

Good point. Being strangled by my 256 Gb SSD on my work iMac, I’m taking any free space that’s offered if that’s more or less automatic, but I won’t worry too much about it :slightly_smiling_face:

1 Like

I just did a little bit of digging. Apparently in the past removing the extra stuff from the binary yielded about a 30% reduction in size. Given my Applications folder is about 20 gigabytes (not counting Xcode, which I can’t imagine thinning out at all), that would be something like 6 gigabytes.

And if I didn’t have Microsoft Office stuff installed, that 20 gigabyte number would be more like 12. :slight_smile:

I suppose 3-6 free gigabytes isn’t nothing, but I’m with you - it doesn’t feel like the sort of thing that’s worth worrying about too much.


This data, collected by @tomalmy and posted here, suggests otherwise:

One “gotcha” I haven’t seen talked about anywhere is the increase in size caused by the Universal binaries and, in the case of the OS itself, the added code to support Rosetta 2. In my measurements, Big Sur is 28% larger than Catalina. The updated, universal binary, apps have also grown. Pages up 26%. Third party app Affinity Photo up 62%. I experimented compiling “Hello World” in Xcode. Switching from Intel only to Universal it grew in size 245%! Since the App store apps are moving to universal binaries, even if you stay with Catalina expect to need more disk space.

One thing this reminds me of is how in iOS downloads can do things to only download hardware specific bits. “App Thinning”

In iOS this can be around assets/resources that are tuned to different screen sizes, but can also be for 32bit vs 64 bit variants on the compiled code.

For a game the actual compiled code might be a tiny part of the download. For other types of applications this would be a bigger impact.

@tjluoma’s comment that fiddling with the downloaded package could mean that you break code signing, and so this is a fools errand is probably true.

Sadly in a world where my storage is expensive SSD that I wish were bigger, this is a thing I would like to try.


I remember that being talked about. But I would assume this would only happen from an App Store. So it may, in fact, already happen for macOS apps installed from the Mac App Store? You’d hope that particular feature was brought “back to the Mac”.


There is no App Thinning from Apps downloaded from the App Store. See my post


Big Sur being larger than Catalina may be true, but how much of that is due to the switch to universal? I’m guessing Catalina was bigger than Mojave too.

An “app” that is only a compiled binary is not a good representation of an average app.

The first app that I compared went from 14.7MB to 16.2MB.

Another went from 140MB to 148MB.

BBEdit went from 54.8MB to 55MB.

BBEdit is a good example because it was just a point-release. If you are looking at a feature-release that is also a switch to universal then it’s not as easy to tell what the difference is caused by.

1 Like

I’m not surprised that Big Sur is bigger than Catalina, in fact I would be surprised if that was not the case.

I’m not sure what you mean here:

An “app” that is only a compiled binary is not a good representation of an average app.

And as to this:

I experimented compiling “Hello World” in Xcode. Switching from Intel only to Universal it grew in size 245%!

it’s possible that there is some fixed overhead that shows up more dramatically in a very small app.

The fact is we really don’t know (yet) what the impacts of the new “universal” apps are. I’m guessing we’ll learn more pretty soon, though.


It’s not only possible; it’s almost certainly the case.

1 Like

So I ran a test and ‘thinned’ a copy of ‘’

It went from 636.7 MB to 508 MB.

When I tried to run it, macOS did complain about it.

However, if I removed the quarantine flag, I could launch and use the modified version. Of course that’s a risky thing to do if you aren’t absolutely sure of the security of the app.

It is also possible that once the signature is broken, apps from the Mac App Store may not update properly, apps that use Sparkle may not update. I’m not sure about that, just a suspicion.

So, while I wouldn’t recommend this, it is possible.


What seems to be the case is that the code size roughly doubles, but for application bundles (my xcode example was a command line app, so no app bundle) the Resources remains the same so the total increase will be much less. For programs with lots of resources, doing such traditional things like removing the foreign languages probably saves more space.

When I attempt to look at my “hello world” program, it appears that the executable size of the two architectures are the same (!) however when I add them together is is much smaller than the size of the universal executable. So there is, for such a small program, significant overhead in just having a universal binary over two separate binaries. Apple might explain this somewhere, or they might not.

1 Like

That lost more “weight” than the entire executable Were you also thinning out the foreign language files?

I suspect that there is (among other things, of course) a fixed-size overhead to universal binaries that would seem relatively enormous for very small programs.


That’s because isn’t the only ‘fat’ binary in the app wrapper, and any ‘thinning’ program would have to take that into consideration.

Here are the terminal commands I used to identify the files that needed to be thinned. Replace “/Applications/” with whatever app that you are looking at to use this with other apps.

find "/Applications/" -type f -print0 \
| xargs -0 file \
| fgrep 'Mach-O universal binary with 2 architectures:' 

The first line says ‘Look in “/Applications/” for files (-type f i.e. not folders, links, etc) and print their path.

The second line says: “For each of those paths, run the file command on them.”

(note that -print0 and xargs -0 are both designed to work with file paths which may have spaces in them.)

The third line says “Limit the results to just lines which match the text in quotes.”