Application binary size aka the return of the fat binaries

[TillOliver]

"Optimised for M1". And a quick check of the app bundle size on Mac confirmed what we've feared: "the return of the fat binaries". Each binary (Photo, Publisher and Designer) is now at least 2.7 GB (!) in size each - from a previous 1.7 GB, if I remember correctly. Which is already way too much, but oh well.

And a quick checks confirms that, e.g.

lipo -info /Applications/Affinity\ Photo.app/Contents/MacOS/Affinity\ Photo
Architectures in the fat file: /Applications/Affinity Photo.app/Contents/MacOS/Affinity Photo are: x86_64 arm64

Now this is of course only the "main" binary, and each provided framework now comes for two architectures.

According to

  https://eclecticlight.co/2020/07/30/instant-weight-loss-how-to-strip-universal-apps/ 

it should be possible to strip away the unnecessary architecture (arm64 in my case), to slim down the binary size to approximately 1.7 GB in this case (give or take additional space for new features, although I don't think there are any new features except the new binary for ARM aka "Apple Silicon"), without breaking the code signature. However I am not going to do that right now, unless someone has already done this and possibly has an automated way to strip away the ARM64 architecture for all binaries and libraries within a given app bundle on Mac?

But let's face it: 1.7 GB is already way too much: it's not like those apps come with tons of graphic resources (like textures, brushes, or even video tutorials etc.) which would justify that enormous disk space being used.

 

[v_kyr]

Yes that's how things are actually for Big Sur complient universal architecture apps (as mentioned previously here too). - However, I wonder that Apple didn't supplied any end user GUI tool for striping out unneeded architectures beside lipo, or does cleverly only installs the architecture relevant portions on any system. - But maybe here it's due to the fact to also support to execute iPad related software too then on either system architecture. Aka to execute shared apps.

BTW, some third party tools claim that they can deal with the removal of universal binaries ...

• How to Remove Universal Binaries on a Mac?

... but I never tried or used that one so far!

[ronnyb]

On 11/15/2020 at 11:08 AM, TillOliver said:

"Optimised for M1". And a quick check of the app bundle size on Mac confirmed what we've feared: "the return of the fat binaries". Each binary (Photo, Publisher and Designer) is now at least 2.7 GB (!) in size each - from a previous 1.7 GB, if I remember correctly. Which is already way too much, but oh well.

And a quick checks confirms that, e.g.

lipo -info /Applications/Affinity\ Photo.app/Contents/MacOS/Affinity\ Photo
Architectures in the fat file: /Applications/Affinity Photo.app/Contents/MacOS/Affinity Photo are: x86_64 arm64

Now this is of course only the "main" binary, and each provided framework now comes for two architectures.

According to

  https://eclecticlight.co/2020/07/30/instant-weight-loss-how-to-strip-universal-apps/ 

it should be possible to strip away the unnecessary architecture (arm64 in my case), to slim down the binary size to approximately 1.7 GB in this case (give or take additional space for new features, although I don't think there are any new features except the new binary for ARM aka "Apple Silicon"), without breaking the code signature. However I am not going to do that right now, unless someone has already done this and possibly has an automated way to strip away the ARM64 architecture for all binaries and libraries within a given app bundle on Mac?

But let's face it: 1.7 GB is already way too much: it's not like those apps come with tons of graphic resources (like textures, brushes, or even video tutorials etc.) which would justify that enormous disk space being used.

 

I tried this process on the beta and it didn't work. It seems most of the bulk is in the Resources direcxtory, not in the Affinity Designer/Photo/Publisher binaries

Perhaps the Devs can add this as a preference setting for the automatic updates?

[v_kyr]

4 hours ago, ronnyb said:

...It seems most of the bulk is in the Resources direcxtory, not in the Affinity Designer/Photo/Publisher binaries

Well the shared libs are too build as universal architecture not just the executable binaries.

• Apps on the ultimate diet: beyond stripping Universals

[v_kyr]

I just found again one of my good old NeXT OpenStep tools (a graphical front-end tool for Lipo) on one of my backup disks that I once ported to MacOS El Capitan. At that time I had already thought about making it available here for the community, but as so often never found the time to do so and to support it further then.