FAT binaries are wasted disk space ...

[v_kyr]

I recently cleaned my oldest MacOS system of unnecessary and unused clutter i.e. removed old installer file residues and referenced caches, Xcode tmp files etc. The whole thing has set me back ~80 GB of disk space. Then I looked at some other unnecessary space wasters, and the whole FAT binary apps caught my eye.

I then asked myself why I need arm-based (arm64) architecture code on an Intel-based (x86_64) MacOS, so why multi-architecture FAT binaries here at all? - Well the answer is I don't need any FAT binaries on this Intel based box at all because it's just an unnecessary waste of disk space.

To give people an idea of what I mean with unnecessary wasted space here, I show you how much ADe V1 as a multiarchitecture FAT binary (including x86_64 + arm64 code) will occupy on my disk ...

... and that I can get back ~1 GB of disk space when I thin/strip it to just contain the one needed, x86_64 in my case, architecture here ...

Now the same applies to APh V1 (2.65 GB as a fat binary) and Apub V1 (2.6 GB as a fat binary), which when striped to contain just one architecture will also give back at least ~1 GB each.

Suppose I would also have all three version 2 apps too installed, then stripping all Affinity v1 + v2 apps to just the one architecture I need here, would give back ~6 GB of disk space here. If I would have additional Beta versions installed and then strip those too I would reclaim additional disk space.

Of course it's not just the Affinity apps which, as multiarchitecture FAT binaries, occupy unnecessary disk space here, the same applies to all other bigger third party multiarchitecture fat binary apps here too!

I'm sure I will get back another ~50-60 GB of disk space when stripping all installed fat binary apps on my old system, which BTW has only a small build-in disk and thus every free GB counts here!

 

[MikeTO]

This transition period won't last forever. I think it was 4 years from announcing the switch to Intel to dropping support for PPC in macOS, after which developers quickly stopped making fat binaries. If it's a similar timeframe for Apple silicon, we have another two years to go.

Apple, Adobe, Microsoft, and Google all use fat binaries, too, because they're easier for developers and users. But yes, they take up twice the space.

[lacerto]

5 hours ago, MikeTO said:

we have another two years to go.

So people who are running Intel macs (purchased e.g. as late as in 2021) would now have only about two years left until they lose support for running their computers and Intel based apps using most recent OS versions? Is there an official deadline? Wouldn't it most probably also mean that Intel based versions would not even be updated as they would need to be made separately available, and possibly also separately distributed as I would not be surprised if Apple Store requires Silicon support anyway?

There is also another consideration for those running M-based Silicon macs, as there are still many apps and especially add-ins and plug-ins that are Intel-only, and for which there is a risk that M-based version will never be developed. Stopping Intel-based support then means that those depending on these components need to repurchase them (unless provided for free by their manufacturers) or just cannot upgrade their OS versions because they could no longer run their apps using Rosetta. 

It would be more appropriate to drop M-binaries than ever drop Intel-binaries, but neither thing is likely to happen (that is, getting Intel-only or always fat binaries). There is also a consideration of being able to run specific version of software sold based on perpetual license and limited download availability so that M-binary would be automatically available also when the user upgrades their computer to a Silicon based mac. 

But I guess there is nothing new here. Selling devices is Apple's business -- including selling overpriced storage space. As for desktops, you need to keep on purchasing again not only at the crucial points where the processor architecture changes (Motorola => RISC => Intel 32 => Intel 64 => Apple Silicon) but a couple of times in between, too, because of limited OS and repair/service life-cycles.

[firstdefence]

I recently sold a 2011 iMac that could officially  go no higher than OS X High Sierra, also a lot of app updates could not be applied but I think I had my monies worth out of the machine and it still looked and ran well, so for a 12 year old computer it wasn't doing bad. I used to use an app called XSlimmer but that is now discontinued. I think stripping out ARM stuff is a bit more complicated than just removing unnecessary files.

[v_kyr]

6 hours ago, MikeTO said:

This transition period won't last forever. I think it was 4 years from announcing the switch to Intel to dropping support for PPC in macOS, after which developers quickly stopped making fat binaries. If it's a similar timeframe for Apple silicon, we have another two years to go.

Apple, Adobe, Microsoft, and Google all use fat binaries, too, because they're easier for developers and users. But yes, they take up twice the space.

Well, FAT binaries aren't a bad thing per se, but it's bad that Apple doesn't offer them to be stripped during app installments. - As a former times NeXT employee and thus used to NeXTstep/OpenStep I'm pretty used to FAT binaries and those times we had usually up to 4 architecture (motorola, x86, SPARC, and PA-RISC) FAT binary apps.

But and that is a big BUT, there was always the possibility during PKG installation, or afterwards, to easily strip out automatically the by your platform unneeded architectures from apps in order to save disk space. That's something I'm missing from Apple here right out of the box.

[v_kyr]

1 hour ago, firstdefence said:

I used to use an app called XSlimmer but that is now discontinued. I think stripping out ARM stuff is a bit more complicated than just removing unnecessary files.

NO, it's easy too if you know how to do and deal with it. The main tool therefor is "lipo" and that's what most other utility stripping GUI apps call internally here then. There are actually some by people created MacOS apps like that "XSlimmer" and I have for my personal purposes too written my own auxilliary progs which can do so.

[firstdefence]

5 minutes ago, v_kyr said:

NO, it's easy too if you know how to do and deal with it. The main tool therefor is "lipo" and that's what most other utility stripping GUI apps call internally here then. There are actually some by people created MacOS apps like that "XSlimmer" and I have for my personal purposes too written my own auxilliary progs which can do so.

Thanks for the knowledge, I tried programming once but my brain is way too scrammbled lol but I go back every now and then to have another go, I'm either a super optimist or delusional lol!

[lacerto]

33 minutes ago, v_kyr said:

But and that is a big BUT, there was always the possibility during PKG installation, or afterwards, to easily strip out automatically the by your platform unneeded architectures from apps in order to save disk space.

I think that there is a chance that separate deliveries are if not prevented then discouraged in order to promote that latest and greatest, especially if the method of distribution is Apple Store? Just a guess. There are these kinds of restrictions also for delivery via Microsoft Store (I am not sure but I think that if separate 32 and 64-bit packages are wanted to be delivered, it must happen off the MS store...).

[v_kyr]

34 minutes ago, firstdefence said:

Thanks for the knowledge, I tried programming once but my brain is way too scrammbled lol but I go back every now and then to have another go, I'm either a super optimist or delusional lol!

Of course you don't have to program yourself, you can also use and tryout some ready made solution here. - Let's give you just one such example app which is meant for such purposes ...

• Armless
• LIPO

... though you will need to have lipo installed which is usally part of the Apple Xcode CLI developer tools. - But there is an alternative GO based lipo, just don't know if that runs everywhere.

NOTE however, that I didn't tried out that referenced app and lipo, since they won't run either way under my old MacOS El Capitan, as they are compiled against newer MacOS versions, so with much newer Xcode & Swift versions than I have here.

[v_kyr]

15 minutes ago, lacerto said:

I think that there is a chance that separate deliveries are if not prevented then discouraged in order to promote that latest and greatest, especially if the method of distribution is Apple Store?

Especially the MAS/Apple Store should IMO be usually able to handle that, determining what a users system, compatibility wise, really only needs here. In the same manner as the MAS would tell you, that a certain app isn't compatible (compiled) for your older in use MacOS system here and that you thus can't install it. - In the same manner it could strip out unnecessary and by your system not supported architectures out of FAT binary apps. As said above, during good old NeXT times we had those capabilities via the NeXTstep app installers (~23 years ago), which has all be overtaken by Apple and reused for/in MacOS.

[lacerto]

18 hours ago, v_kyr said:

Especially the MAS/Apple Store should IMO be usually able to handle that,

But does it in practice? I meant promotion much in the sense that including Silicon distribution might be a kind of a requirement to be able to deliver via App Store in the first place [and a means to get the developer get their app support as soon as possible the new architecture] -- and then the fat binaries (Universal apps) would basically be a pragmatic requirement for also ease of use? 

[v_kyr]

1 hour ago, lacerto said:

But does it in practice? I meant promotion much in the sense that including Silicon distribution might be a kind of a requirement to be able to deliver via App Store in the first place ...

For sure it goes (or will go) that way, I recall having recently also somewhere read something like that, in some Apple to developer addressed/related announcements. - But since not all software is distributed via MAS only, it makes sense to basically offer architecture stripping on the system level too here. Meaning to add right out of the box the capabilities to easily strip unneaded architectures from any software distribution (...either during an OS based dmg/pkg installation process and/or afterwards via some more end user friendly OS supplied toolings).

Especially here in the context, that cheaper Mac entry level hardware often is sold only (does just come along with) a nowadays as to be seen tiny 256 GB SSD and since FAT binaries do occupy much more disk space than usually needed, for running a platform architecture based app!

[loukash]

1 hour ago, v_kyr said:

Armless

Hey, that works!
It requires Xcode to actually build it. And if you haven't used Xcode in years and totally forgot how it even works, you also need to find the compiled app first, buried somewhere, er, don't know where…  
Binaries shown with a yellow dot require to be logged in as root to strip them.

[v_kyr]

20 minutes ago, loukash said:

Hey, that works!
It requires Xcode to actually build it.

Yes since there is no ready to use binary supplied by the project and as you also need lipo (it depends on it) too here, which comes along with the Xcode CLI tools installment.

23 minutes ago, loukash said:

...you also need to find the compiled app first, buried somewhere, er, don't know where…

Look into ...

• -->   ~/Library/Developer/Xcode/DerivedData/{app name}/Build/Products/Deployment/

... there you should find the by the Xcode project build app! - You may also want to strip the build app binary itself, in case you've build it with debugging code settings!

 

 

[loukash]

4 minutes ago, v_kyr said:

Look into …

Thanks, but of course I found it very quickly before even posting here because findanyfile.app is my friend…  

[v_kyr]

Further check processed app sizes before & after lipoing them. You can also dig into the app folders and perform in a terminal some ...

• >  file binary-file
• >  file libname.dylib
• ... etc.

... in order to see if all (binary & libs) have really been stripped/thinned for architectures the right way. - The file command will tell you, or alternatively lipo -info ...!

[thomaso]

2 hours ago, v_kyr said:

Let's give you just one such example app which is meant for such purposes ...

• Armless
• LIPO

... though you will need to have lipo installed which is usally part of the Apple Xcode CLI developer tools.

Doesn't XCode itself occupy quite a bit of disk space? (From an installation about 15 years ago I have ~ 10 GB in mind.)

Another tool may be Monolingual (no XCode required). Years ago I used it to strip localisation / language content (a few GB) but it also offers to strip architecture files.

Unfortunately it does neither offer options to select or exclude certain apps from being stripped (as imho a former version did) nor a confirmation window for possibly affected apps – which both has been very useful years ago because Adobe apps did not run any more after they got stripped even just the localisation contents. – Or does its current version affect only system / macOS files, leaving apps untouched … as the description could imply: "Monolingual is a program for removing unnecessary language resources from macOS"  … and my memory fails? (whereas I still have an image of the UI in mind with checkboxes to exclude Adobe apps)

By the way, here is a related forums thread from 2020:

That mentions CleanMyMac as a possible tool – which, in my eyes, maybe risky in macOS because of its various features that may conflict with macOS's own security handling.

[loukash]

8 minutes ago, thomaso said:

Doesn't XCode itself occupy quite a bit of disk space?

Sure it does. Hence it doesn't even live on my Catalina partition, but in a separate folder elsewhere on my large El Capitan partition…

11 minutes ago, thomaso said:

Another tool may be Monolingual

Ah, I'm a longtime Monolingual user, but I haven't looked up if it's even aware of arm64 binaries. Obviously it is! 
Thanks for the heads-up.

12 minutes ago, thomaso said:

Years ago I used it to strip localisation / language content (a few GB)

Yep, I'm periodically using it for that, saving a few 100 MB here and there.

[loukash]

18 minutes ago, thomaso said:

options to select or exclude certain apps from being stripped

You would have to exclude them individually by adding them to the Preferences list and uncheck all their options.
Also, usually Monolingual will ignore anything it doesn't have permissions to it.

[v_kyr]

 

30 minutes ago, thomaso said:

Doesn't XCode itself occupy quite a bit of disk space? (From an installation about 15 years ago I have ~ 10 GB in mind.)

Yes Xcode needs a huge amount of disk space itself, but that's the way of cookie crumbles if you want to develop for the Apple platforms.

31 minutes ago, thomaso said:

Another tool may be Monolingual (no XCode required). Years ago I used it to strip localisation / language content (a few GB) but it also offers to strip architecture files.

Use that with caution here, it's not very foolprove for architecture extractions/thinning and it doesn't strip/thin libraries at all, so it will only strip a binary at best. - Thus is IMO more useful to get rid of unneeded/unneccesary language packages in apps (aka those languages you either ways don't deal with).

31 minutes ago, thomaso said:

That mentions CleanMyMac as a possible tool – which, in my eyes, maybe risky in macOS because of its various features that may conflict with macOS's own security handling.

Depends on how CleanMyMac operates here (...don't know I never tested that app, but other similar apps instead).

[v_kyr]

46 minutes ago, thomaso said:

By the way, here is a related forums thread from 2020:

Ah yes, that shows my custom AFlipo tool which does the nearly the same as what Armless does, though in a different usage manner. My AFlipo tool operates only on single dragged on apps instead and it's actual version handles also i386 architectures, since El Capitan can still deal with those. - AFlipo is a takeover (adaption) from my old NeXT times, since it was written originally for NeXTstep/OpenStep.

But in the meantime I personally use instead some Python scripting (custom Python3 progs) to do such stripping/thinning architecture tasks, since I like to have overall better output of what certain processing stages are doing and which dirs and files they are actually handling. So to say all the background processing tasks most MacOS apps are hiding and don't show you here when recursively processing all the folders & files inside some given app to thin.

For example, when processing/traversing some given FAT architecture app recursively, you have to check all the files inside, aka what are executable mach-o binaries or libs and if they are FAT architecture based executable etc., since you only want to call lipo (let it operate) on those files, everything else doesn't have to be touched.

[thomaso]

13 minutes ago, loukash said:

You would have to exclude them individually by adding them to the Preferences list and uncheck all their options.
Also, usually Monolingual will ignore anything it doesn't have permissions to it.

Its UI appears unclear to me: By default "Applications" and "Library" are set & selected. Unchecked entries may EITHER mean they are simply ignored (–> the "Applications" setting rules / unchecked entries aren't 'seen' by the app) OR it may mean they get literally excluded, (–> regardless from the "Application" checkbox). – How does one know?

Compare: Time Machine has a clear, unambigous list for exclusions …

… while Affinity uses an unclear checkbox interface: The setting below implies I get warned if any opened or placed resource has any different than the current document profile … but I never get such a warning (different to ID as far I remember).

[loukash]

1 minute ago, thomaso said:

they get literally excluded

This.
But yeah, it's not the most intuitive UI design I've ever seen…

[thomaso]

5 minutes ago, loukash said:

This.

What makes you think so?  (… does the app list all affected files in a report after its run?)

[loukash]

27 minutes ago, thomaso said:

What makes you think so?

Experience.
Been there done that literally hundreds of times, including this, excluding that, simply as needed.
Stripping languages only, that is. Never architectures because I kept those checkboxes always disabled.

Oh, and possibly I was also reading a ReadMe many years ago. You know, as in: If everything else fails, RTFM…