Is there any practical purpose for APE? Like who is shipping single executables that need to run on N OSes?

I use an APE executable as an agent for communicating with remote hosts in the Logfile Navigator (https://lnav.org). While lnav itself is not built as an APE, the agent built into itself is. That agent is transferred to the remote when the user wants to read logs on that host. This way, there is no extra step to determine the type of OS or building in multiple versions of the executable. Here's a short blog post on the subject:

https://lnav.org/2021/05/03/tailing-remote-files.html

My biggest problem with APE: not portable enough, in the sense that when people adopt APE, they lock themselves into less portability than they might have supported otherwise. I live in an ARM world and because of APE you only offer Intel x64 binaries. All new Macs are ARM64, Raspberry Pi models are a mix of ARM32 and ARM64 (mine is ARM64), and I use exclusively Graviton instances in AWS. Running x64 binaries with QEMU/Rosetta emulation on an ARM system is a cute trick but not something I want to do for a piece of infrastructure. Raspberry Pis are barely fast enough to run native binaries. Consider offering APE for x64 but then still producing ARM binaries the old fashioned way. APE is pushing the idea that x64 is a good bytecode in a world that is moving from x64 to ARM. I'd like to see the project accept that ARM exists and produce an ARM version of APE, maybe with some jart flourish--can we make a cross-platform and cross-architecture fat binary?

> Consider offering APE for x64 but then still producing ARM binaries the old fashioned way.

The recent version of cosmopolitan generates ARM binaries for Linux and MacOS (https://github.com/jart/cosmopolitan#arm; mode aarch64). There is also blink that provides the x86-64 emulation layer for (APE and other) binaries on a variety of platforms (https://github.com/jart/blink).