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.

[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. 

[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.