I have attempted to research this but given the fact that applications exist to compress other files, I've found it difficult to learn about compressing applications themselves.

I presume its okay to compress applications in general – they are like any other file.

However, before compressing applications which require licenses (for example pre CC Adobe suite), I want to make sure the license will continue if I compress the application and delete the uncompressed file.

If I compress an application and delete the original will I lose my license?
(I understand this could be different for different applications; is there a generic answer?

  • These days, why even bother? I see no possible return-on-investment to compensate for the possibility of disruption, even if you successfully managed to compress everything associated with an application. (Applications are folders.) I don't recommend pursuing this. Not at all. "Bzzzt! Nothing to see here. Move along. Move along." – Mike Robinson Sep 14 at 14:37

Most macOS applications are not actually like 'any other file' - they just look like one - and are actually a folder of files called a package. Right-click on most apps, and you will see a Show Package Contents command. Click that to see the folder structure of the app.

That being said, applications will compress and expand just fine. I've compressed and expanded Adobe apps with no effect on licensing so long as they are expanded onto the same system.

Compressing an application and expanding it on a different system may break licensing if the licensing mechanism itself resides outside the app's package, or if some other licensing scheme is in effect. There is no generic licensing scheme for all circumstances.

Zipping is a lossless compression algorithm. You will not loose anything when going from Folder→ZIP File→Folder. You can even confirm this by verifying the checksum of a file before being zipped and after being unzipped.

Side Note:: If its difficult to understand how anything could be compressed without losing data here's a good way to understand it: "AAAABBCCC" can be compressed into "A4B2C3". The compressed string is 3 characters shorter then the original yet both still say "four A's, two B's and three C's". While this is not how the zip algorithm works, it is a good way to understand the concept of lossless compression.

To answer your question, while it is ok to compress a Application (which is just any old directory) the license file will most likely not transferred because most of the time it is not stored inside the application's folder. However, if the license file does reside in the application's folder than yes it will transfer. ZIPing the license file will not corrupt it.

Just an FYI: Most applications cannot be transferring by just copying the application. Most store files in ~/Library, /Library, or other directories. The application won't run properly without these directories and associated files.

We have to assume that this is not about transferring an application onto another computer.
The way this is phrased it cannot mean "zipping" an application (bundle) into an archive. While this is possible and should be safe, the application cannot be executed in that state. As this is quite nonsensical compared to the alternative of just deleting the offending application this will surely mean something else:

Transparently compressing applications with HFS filesystem compression.

Again this is perfectly possible and in fact Apple does exactly this with most applications it installs. The last part is crucial since ordinary copies will typically be uncompressed.

To confirm this practice is done by Apple since Mac OS X 10.6 Snow Leopard, you may either read File System Compression in HFS+: Space savings and performance gain? or download the tool afsctool here and run it on Safari.app as an example:

$ afsctool -v /Applications/Safari.app/
/Applications/Safari.app/:
Number of HFS+ compressed files: 333
Total number of files: 360
Total number of folders: 40
Total number of items (number of files + number of folders): 400
Folder size (uncompressed; reported size by Mac OS 10.6+ Finder): 23576574 bytes / 24.6 MB (megabytes) / 23.4 MiB (mebibytes)
Folder size (compressed - decmpfs xattr; reported size by Mac OS 10.0-10.5 Finder): 19959187 bytes / 20.2 MB (megabytes) / 19.2 MiB (mebibytes)
Folder size (compressed): 20200663 bytes / 20.4 MB (megabytes) / 19.5 MiB (mebibytes)
Compression savings: 14.3%
Approximate total folder size (files + file overhead + folder overhead): 20622212 bytes / 20.6 MB (megabytes) / 19.7 MiB (mebibytes)

Adding the parameter c then compresses all files in a given path in-place.

You will need to make sure to have a recent and complete backup! That's because this method is almost perfectly safe. Except when it isn't. For some strange reason the git binary as an example will compress in place OK – but also break in the process. There are some other apps and binaries that will break, but those are very rare. If something goes wrong, restore those few files from backup.

Adobe applications did compress without any issues, last time I checked (caveat: I moved away from those products, so double check for later versions). The licensing information is not within the App bundle anyway.

Given the unprofessionally anaemic size of entry level SSDs filesystem compression is highly recommended.

This method might be employed with onboard tools as well. The command line utility ditto offers an option for that, but it is cumbersome.

If you do not like the command line: GUI-tools for that are available as well. One example dedicated to this would be MoreSpaceFolder (AppStore); there are others.

Since it is transparent you might also transparently compress every file and folder on you system, including system files, provided it is accessed in the boot process only after zlib support is loaded. For this manipulation of system files you need SIP disabled.
This is not really recommended, as it may render your system unbootable if you compress the wrong files.

You can compress every file? It is also not recommended by Apple to compress files that are frequently rewritten. Things like Finder preferences get rewritten needlessly and constantly. Not only would this be impractical, it is also senseless to attempt: it will work, but the newly written files are then in uncompressed form again.

This is the generic answer for HFS+. For APFS I have no information.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.