No. UPX won't work on iOS for various reasons, but it is also generally speaking a poor choice to use on macOS. There are several issues here:
* It usually does not reduce the size of the file in transit, as most files are compressed for distribution, and even if they are not most http servers will use transparent gzip compression
* It does not actually reduce the size of files at rest since APFS (and HFS+ before it) support transparent decompression. The layer this is handled at is sufficiently low level most people do not even realize it is happening (stat(2) returns the uncompressed size, you need to look at extended attributes to see the real on disk size). Admittedly this does not handle binaries that are drag installed on macOS. You can find out more details here: https://github.com/RJVB/afsctool
* UPX slows down app launch because you know have to decompress the entire executable before you launch it, which means you need need to read the entire compressed executable from disk before you launch it
* UPX greatly increases the memory overhead of running an application. Because you decompressed it in memory all the executable pages are dirty memory that need to be kept in memory or written to swap. That means you immediately loaded everything into memory instead of just the pages you needed. Normally a binaries pages are brought in from disk as necessary, and because of that they are unmodified clean memory. The built in compression support compresses smaller blocks of the binary and thus can still bring them in individually (technically this reduces the compression, but the trade off of being able to keep page demand loading working is more than worth it).
* UPX makes the system perform worse under memory pressure. The fact that it generates decompresses the pages in userspace means that from the kernels perspective they are dirty. If the kernel needs to evict them due to memory pressure it needs to swap them out. Uncompressed files (or those compressed with the builtin filesystem compression) are clean memory, which means that under memory pressure the kernel can just through them out and then reload them from the file later, no need to write out the pages.
In the past there were legitimate reasons for tools like UPX, and there may still be on other operating systems, but it simply does not make sense on Darwin platforms.
* It usually does not reduce the size of the file in transit, as most files are compressed for distribution, and even if they are not most http servers will use transparent gzip compression
* It does not actually reduce the size of files at rest since APFS (and HFS+ before it) support transparent decompression. The layer this is handled at is sufficiently low level most people do not even realize it is happening (stat(2) returns the uncompressed size, you need to look at extended attributes to see the real on disk size). Admittedly this does not handle binaries that are drag installed on macOS. You can find out more details here: https://github.com/RJVB/afsctool
* UPX slows down app launch because you know have to decompress the entire executable before you launch it, which means you need need to read the entire compressed executable from disk before you launch it
* UPX greatly increases the memory overhead of running an application. Because you decompressed it in memory all the executable pages are dirty memory that need to be kept in memory or written to swap. That means you immediately loaded everything into memory instead of just the pages you needed. Normally a binaries pages are brought in from disk as necessary, and because of that they are unmodified clean memory. The built in compression support compresses smaller blocks of the binary and thus can still bring them in individually (technically this reduces the compression, but the trade off of being able to keep page demand loading working is more than worth it).
* UPX makes the system perform worse under memory pressure. The fact that it generates decompresses the pages in userspace means that from the kernels perspective they are dirty. If the kernel needs to evict them due to memory pressure it needs to swap them out. Uncompressed files (or those compressed with the builtin filesystem compression) are clean memory, which means that under memory pressure the kernel can just through them out and then reload them from the file later, no need to write out the pages.
In the past there were legitimate reasons for tools like UPX, and there may still be on other operating systems, but it simply does not make sense on Darwin platforms.