HD Space taken up

[inspiredmac]

Yesterday I downloaded and installed updates for Designer, Photo and Publisher.  Before beginning, I had 766 Gigs of HD space available. After installing the updates, HD space had dropped to 459 Gigs of space. Would the updates have anything to do with this dramatic 7-Gig decline in HD space?

 

 

[firstdefence]

You mean 759GB.

Which Operating System are you using? 

Affinity apps are roughly 2.4-2.5GB unpacked and installed so 7GB is close to the figure you are seeing. On Mac's an installer will ask to replace and app or keep both.

 

[telemax]

Windows shows that AP and AD apps take up 1.05 and 1.02 GB.

[LondonSquirrel]

Universal (2) binaries on MacOS are twice the size of the single architecture binaries, and they're a good way to waste disk space. Take the largest file in the APub installation: liblibpersona.dylib. It is 1GB in size. It supports two architectures: x86_64 and Apple's own arm64. Roughly half the size of this file is devoted to each platform. Congratulations! If you have an Intel chip you've just given 500MB of space disk space away to arm64, and vice versa. 

So that is why later versions of Affinity on MacOS are roughly twice the size of earlier versions, and roughly twice the size of Windows.

[xxx@xxx:12:56:20:/Applications/Affinity Publisher 1.10.app/Contents/Frameworks] (517) % lipo  -detailed_info liblibpersona.dylib
Fat header in: liblibpersona.dylib
fat_magic 0xcafebabe
nfat_arch 2
architecture x86_64
    cputype CPU_TYPE_X86_64
    cpusubtype CPU_SUBTYPE_X86_64_ALL
    capabilities 0x0
    offset 16384
    size 557917936
    align 2^14 (16384)
architecture arm64
    cputype CPU_TYPE_ARM64
    cpusubtype CPU_SUBTYPE_ARM64_ALL
    capabilities 0x0
    offset 557940736
    size 503671568
    align 2^14 (16384)

 

[Guest]

And they each ship with exact copies of the SAME frameworks, roughly 2GBs each in:
Affinity {Designer|Photo|Publisher}.app/Contents/Frameworks/liblibaffinity.dylib, liblibrenderer.dylib, liblibrastertools.dylib, etc…

I miss the days of shared frameworks, and where each and every app didn't include MBs/GBs of redundant libraries and frameworks (I'm also looking at you Electron apps). With SSDs today often being fixed to the motherboard (and hence not upgradable), and being rather expensive when buying from the manufacturer (ahem, Apple - your only option) many folks often opt for smaller SSDs to save a little cash. Developers requiring GBs of precious SSD space to install multiple copies of the same frameworks and libraries feels rather presumptuous (and obnoxious) today. The App Store and the sandboxing requirement definitely didn't help.

[R C-R]

3 hours ago, Bryan Rieger said:

I miss the days of shared frameworks...

I do not miss how if a shared framework became damaged, or was removed by an 'app cleaner' that was not aware multiple apps shared it, then every app that shared it started acting weird. I also remember having a few problems because updating some versions of certain apps installed an updated shared framework that did not work correctly with some of the other apps it was shared with.

That said, I do wish the Affinity installers only installed what is needed for the hardware instead of for both architectures. 

[BofG]

56 minutes ago, R C-R said:

That said, I do wish the Affinity installers only installed what is needed for the hardware instead of for both architectures.

I can understand the single "delivery package" but it seems bonkers to me that it then installs both versions. Do all universal apps do that or is this maybe an error?

[Guest]

3 hours ago, R C-R said:

I do not miss how if a shared framework became damaged, or was removed by an 'app cleaner' that was not aware multiple apps shared it, then every app that shared it started acting weird. I also remember having a few problems because updating some versions of certain apps installed an updated shared framework that did not work correctly with some of the other apps it was shared with.

Yeah, Windows DLL hell was, ‘special’. NeXT and macOS did have a nice way of dealing with them via /Library/Frameworks, but it’s largely fallen out of fashion/use.

Just delivering the lib versions for the required architecture would be most welcome.

[LondonSquirrel]

4 hours ago, R C-R said:

That said, I do wish the Affinity installers only installed what is needed for the hardware instead of for both architectures. 

Indeed. I have all three Affinity apps installed and I suffer about 3GB of wasted disk space as a result. Not so much a problem on my iMac, but on my laptop it's significant. It is wasteful.

[LondonSquirrel]

4 hours ago, BofG said:

Do all universal apps do that or is this maybe an error?

That is the way universal binaries work. I don't have many apps installed on this machine, but Firefox is a universal binary. Once again, about 50% is given to each architecture:

[xxx@xxx:23:31:47:/Applications/Firefox.app/Contents/MacOS] (624) % file XUL 
XUL: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]
XUL (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
XUL (for architecture arm64):	Mach-O 64-bit dynamically linked shared library arm64

[xxx@xxx:23:31:49:/Applications/Firefox.app/Contents/MacOS] (625) % lipo -detailed_info XUL 
Fat header in: XUL
fat_magic 0xcafebabe
nfat_arch 2
architecture x86_64
    cputype CPU_TYPE_X86_64
    cpusubtype CPU_SUBTYPE_X86_64_ALL
    capabilities 0x0
    offset 4096
    size 139995792
    align 2^12 (4096)
architecture arm64
    cputype CPU_TYPE_ARM64
    cpusubtype CPU_SUBTYPE_ARM64_ALL
    capabilities 0x0
    offset 140001280
    size 136944144
    align 2^14 (16384)