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