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 
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. 
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.
2 Likes
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.
2 Likes
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”.
2 Likes
There is no App Thinning from Apps downloaded from the App Store. See my post https://talk.macpowerusers.com/t/big-sur-break-thread/20181/33?u=tomalmy
2 Likes
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.
2 Likes
It’s not only possible; it’s almost certainly the case.
1 Like
So I ran a test and ‘thinned’ a copy of ‘Pages.app’
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.
4 Likes
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 Pages.app/Contents/MacOS/Pages. 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.
2 Likes
That’s because Pages.app/Contents/MacOS/Pages 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/Pages.app/” with whatever app that you are looking at to use this with other apps.
find "/Applications/Pages.app" -type f -print0 \
| xargs -0 file \
| fgrep 'Mach-O universal binary with 2 architectures:'
The first line says ‘Look in “/Applications/Pages.app” 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.”
2 Likes
It’ll be interesting to see what happens when you try to apply an update to the app. Could you follow up here with that info, please?
1 Like
I did one better – I asked an expert, Howard Oakley,¹ who has written extensively about app signatures and related issues.
I posed this question:
If one ‘thins’ a fat binary, that will break the signature of the app, which we can bypass by removing the quarantine flag. However, I assume (but don’t know for sure) that may prevent the Mac App Store and/or Sparkle from updating the app properly. Do you know?
and he replied:
https://twitter.com/howardnoakley/status/1330286138196680705
¹ Howard’s site https://eclecticlight.co and more specifically https://eclecticlight.co/category/macs/ is, IMO, required reading for anyone wanting power-user level information about Macs.
1 Like
That’s my concern with Rosetta: If it is the notional 20s on first launch of an updated app that’s going to get old very fast.
Ah! DLLs. Of course! Putting these in the app bundle eliminates the Window’s problem of DLL Hell, but now I wonder how much wasted space there is from having identical DLLs in multiple app bundles? Luckily disk space is cheap, at least until you run out. Also it is interesting that while almost all the x86_64 DLLs are shared, most all those for arm64 are not. Assuming the shared libraries actually are shared, this could mean a RAM usage hit for Apple Silicon Macs.
Apologies for the late response, I’ve been away from my Mac…
If I am interpreting this correctly:
% ls -l /Applications/Pages.app/Contents/Frameworks
total 0
drwxr-xr-x 15 root wheel 480 Nov 4 10:54 ./
drwxr-xr-x 12 root wheel 384 Nov 18 09:53 ../
drwxr-xr-x 5 root wheel 160 Nov 18 09:53 EquationKit.framework/
drwxr-xr-x 5 root wheel 160 Nov 18 09:53 TSAccessibility.framework/
drwxr-xr-x 5 root wheel 160 Nov 18 09:53 TSApplication.framework/
drwxr-xr-x 5 root wheel 160 Nov 18 09:53 TSCalculationEngine.framework/
drwxr-xr-x 5 root wheel 160 Nov 18 09:53 TSCharts.framework/
drwxr-xr-x 5 root wheel 160 Nov 18 09:53 TSCoreSOS.framework/
drwxr-xr-x 5 root wheel 160 Nov 18 09:53 TSDrawables.framework/
drwxr-xr-x 5 root wheel 160 Nov 18 09:53 TSKit.framework/
drwxr-xr-x 5 root wheel 160 Nov 18 09:53 TSPersistence.framework/
drwxr-xr-x 5 root wheel 160 Nov 18 09:53 TSStyles.framework/
drwxr-xr-x 5 root wheel 160 Nov 18 09:53 TSTables.framework/
drwxr-xr-x 5 root wheel 160 Nov 18 09:53 TSText.framework/
drwxr-xr-x 5 root wheel 160 Nov 18 09:53 TSUtility.framework/
then the frameworks are all links, thus there is no duplication of DLL’s.
1 Like
In Unix parlance, the lowercase D at the start of drwxr-xr-x indicates that something is a directory, not a link.
If it was a link, the first character would be a lowercase L.