Optimizing Keka for smaller size on disk

[MaxPower85]

Here are more optimized versions of icons from Keka's beta.

Compressed file.tar.gz

Also... I recommend that you use ditto --hfsCompression on Keka.app to copy it to DMG when you are packaging it for the DMG that you are putting on the website (you don't have to do it for the AppStore version... all AppStore apps get compressed with HFS+ compression once installed), instead of just using a compressed DMG (you can still use the compressed DMG, but have the files inside use HFS+ compression, so the app would be compressed with HFS+ compression when the user moves it to the Applications folder)... that would save a few MBs on disk too.

With these optimized icons and HFS+ compression, Keka.app takes just 19MB on disk (instead of 53.5MB)... and there's still room to save more space... since the icon for gz and gzip is the same and the icon for lz and lzip is the same, when the icon appears twice for similar formats, just symlink it.

[gingerbeardman]

I thought that when a HFS+ compressed file/app is copied the compression is undone? Is this not the case when copying from a DMG?

[MaxPower85]

@gingerbeardman
It depends from how someone copied it... if you just drag&drop it to another HFS+ or APFS partition (or a DMG), it stays compressed... if you copy it to your clipboard then you paste it from the clipboard, then it loses the compression.

[gingerbeardman]

That’s great info. I’m currently working on an app that manages HFS+ compression for users. Let me know if you want to test it. (sorry to derail thread)

[aonez]

Here are more optimized versions of icons from Keka's beta.

@MaxPower85 can you tell me what changes you've made to them so I can replicate it? Great work!

[aonez]

since the icon for gz and gzip is the same and the icon for lz and lzip is the same, when the icon appears twice for similar formats, just symlink it.

@MaxPower85 they should be already symlinks... It seems that in the build process Xcode follows the symlink and copies the original.

[aonez]

I'm making some tests with the HFS+ compression for the dmg. Actually compressing the app results in a slightly bigger dmg, but the app itself seems to be smaller. I'm getting mixed results when checking the app size. Only du -sh Keka.app reports that it is smaller.

By the way @MaxPower85 I did try the drag & drop and the copy/paste and booth respected the compression.

[gingerbeardman]

Same here. Duplicate or copying to another volume resulted in decompression.

“Get Info” shows you true “on disk” size.

[aonez]

“Get Info” shows you true size.

Im getting "53.5 MB on disk" even if du -shreports it is 44MB. Working on 10.11.6 El Capitan... will try now on 10.13.

[gingerbeardman]

It can take a short while to update the true size.

also mdls Keka.app

shows

_kMDItemDisplayNameWithExtensions  = "Keka.app"
…
kMDItemLogicalSize                 = 53484070
kMDItemPhysicalSize                = 44675072
…
kMDItemVersion                     = “1.1.0-beta.7"

[MaxPower85]

@aonez
About optimizing icons... I just used some free icns optimizing app from AppStore that makes an optimized version on drag&drop... but how it optimizes was not very configurable and it didn't support dragging&dropping multiple items at the same time.

So I did some more searching now to find a better way...
Take a look at this: https://github.com/avl7771/createicns

It allows you to extract PNGs from an .icns file, so you can optimize them with a PNG optimizer of your choice and configure the optimizations how you want... and then you can use createicns to make an .icns file from those PNGs and it keeps the optimizations when it creates the .icns file (the iconutil that comes with macOS doesn't keep the optimizations when it creates an .icns file). With a simple bash script you could run it on multiple items.

About HFS+ compression... I see now that copy & paste from Finder also seems to respect the compression... I guess when I tested copying it before that maybe the size on disk didn't update right away or something like that.

@gingerbeardman
About an app to manage HFS+ compression... see if you can find some way for users to avoid unnecessary writes to disk if you are making an app for that... so not just something that would monitor a folder for the user copying uncompressed files to it... maybe some Finder extension to copy a file using ditto --hfsCompression would be good... although the best way would be if there was a way to compress new files before they are written to the disk, but I'm not sure if that can be done without having the whole uncompressed file in RAM first (like if you mounted a RAM disk as a directory, so files written to it would go to RAM and then automatically copied with ditto --hfsCompression by some app that monitors that directory to some other directory on disk), which obviously wouldn't be very practical for very large files.

[aonez]

@MaxPower85 I already use an script to create the icons so I'm testing createicns right away, because I've already tried to do some reduction in the PNG intermediate files but the ICNS where anyway big. Thanks!

[aonez]

@MaxPower85 did the test with amazing results. Did not got as fas as your tests, I've got 533KB instead of your 435KB, using ImageOptim. The colours of the original design are well kept with createicns.

Here a test, containing your version, the original version and the version I've got with optimizations:
Test.zip