You know that sinking feeling when you just want to ship a simple program, but you’re drowning in Dockerfiles, container registries, and platform-specific builds? I’ve been there. And I found something that made me furious – not at the tooling, but at myself for not realizing how simple it could be.
There’s a single executable out there that runs on Windows, Mac, Linux, FreeBSD, and OpenBSD. No containers. No interpreters. No virtual machines. Just one binary, compiled once, that works everywhere natively. It’s called the Actually Portable Executable (APE), and it’s the most unassuming rebellion against the bloat we’ve normalized.
Let me be clear: The operating system is not a boundary. It’s a suggestion. And someone finally called the bluff.
How does it work? The trick is as old as hacking itself: a polyglot binary. The file starts with a tiny ELF header (for Linux), then a PE header (for Windows), then a Mach-O header (for macOS). The OS reads only the header it understands, sees its own format, and executes the code the same way a comedian reads a room – selectively. The rest of the file is shared machine code that runs on all architectures. It’s a single file that says, “I am whatever you need me to be.”
I spent a weekend debugging this. The moment I realized the OS’s protective boundaries are just a set of conventions, I felt the same electric thrill I got when I first discovered that a computer could be tricked. The most portable software isn’t built with the highest-level abstractions. It’s built with the lowest-level understanding.
We’ve been conditioned to believe cross-platform means heavy tooling. Docker, WSL, Python interpreters, .NET runtimes – all of them sit on top of the OS, pretending to bridge gaps. But the gap is an illusion. The OS itself is a thin veneer of rules. And rules, as any hacker knows, are meant to be broken.
Justine Tunney, the mind behind APE, proved that a five-year-old concept – the polyglot – could solve a problem that entire industries have tried to solve with more layers of abstraction. The irony is delicious: To achieve maximum portability, we must go to the lowest level, not the highest.
Here’s what this means for you: If you’re building command-line tools, static binaries, or even small applications, you can ship one file. One. No dependency hell. No “works on my machine.” No CI/CD pipelines to build for three platforms. Just compile once, and let the OS figure it out.
I’ve already started using APE for my own tools. The moment I saw a single .exe file run on my Mac, my Linux server, and a Windows VM without any modifications, I knew I’d been wasting years of my life on containers. Containers are not a solution. They are a symptom of our collective failure to understand the machine.
This isn’t just a technical trick. It’s a philosophical shift. We’ve been trained to think that compatibility requires sacrifice – that you must give up performance, or simplicity, or security. APE proves that you can have all three, if you’re willing to go back to the metal.
So stop virtualizing. Stop containerizing. Start understanding. The OS is a suggestion. And the best way to run everywhere is to obey nothing.
FAQ
Q: Isn't this a security nightmare? A single file that runs on everything could be a universal exploit.
A: Actually, APE binaries are more secure than typical portable apps because they are statically linked with no external dependencies. No libc, no dynamic library injection. The code is self-contained and auditable. It's a single binary, but that doesn't make it a single point of failure.
Q: Does this mean I can replace my entire Docker workflow with a single executable?
A: For simple command-line tools and standalone applications, yes. But containers provide isolation, environment reproducibility, and orchestration. APE doesn't replace Docker for server-side microservices that need sandboxing. It's a better fit for developer tools, CLI utilities, and cross-platform desktop apps where you just want to ship a file.
Q: Won't this break on every OS update? The headers could change.
A: The polyglot technique relies on stable, decades-old binary formats (ELF, PE, Mach-O). These formats are deeply backward compatible. OS vendors break userland APIs far more often than they break the loader. The binary's headers are essentially frozen – that's why this trick has worked since the 1990s.