When I started building my own products, I expected sales, payments, and legal requirements to be the hardest parts. They are genuinely difficult. But an independent software product brings another large job that is almost invisible from the outside: delivering it in a form a user can download, install, and run without an obstacle course.
SaaS is simpler in at least one respect: the update happens on the server and the user opens the new version. A desktop application needs a suitable package for every supported operating system and architecture. For Cubrim, that currently means separate Linux x86_64 and ARM64 builds, Windows x86_64, macOS on Intel and Apple Silicon, and a universal macOS archive.
Building the binary is only the beginning.
Every channel has a different entrance
On one platform, a portable archive is enough. On another, users expect an installer package. Distribution through a store adds requirements around developer accounts, metadata, signing, validation, and upload formats. Apple, Google, and Microsoft document different processes, and the exact set of certificates, keys, or tokens depends on the selected channel.
This is not something you configure once and forget. Every release goes through the same loop:
- build compatible packages;
- sign them where the channel requires it;
- test installation and launch in the target environment;
- publish artifacts and checksums;
- verify the path a real user will take;
- if something fails, fix it and repeat the loop.
Agents can automate a substantial share of this work, but they do not remove target-environment verification. A Windows package needs its final installation and launch check on Windows. If the release promises support for Intel Macs and Apple Silicon, both architectures belong in the verified release path.
Cubrim made the problem concrete
On July 10, 2026, I published the first public Cubrim release. Its release page contains Linux, Windows, and macOS archives, separate macOS packages for Intel and Apple Silicon, a universal macOS archive, and checksums. The packages are about 1.7–3.6 MiB: a small program with an already substantial distribution checklist.
Cubrim already has results worth making accessible. In the corrected world benchmark it ranks first on the x-ray file, with a ratio of 0.445067 against PPMd at 0.454471, and it has several specialized wins. Its published aggregate result is more modest and more useful: fifth out of eight at 0.2524, ahead of gzip on 19 of 24 files. This is not “the best compressor for everything.” It is a working research system with strong results on specific data types and a clear map of what remains to improve.
From manual release work to a repeatable process
My immediate goal is to make Cubrim distribution simple enough that a user never needs to understand the release machinery. They choose a platform, receive the right package, and see a clear installation path. Signing, validation, publication, and checksums should stay behind the scenes.
At the same time, I want to turn the experience into a repeatable framework. Not another script that works in one repository, but a process with explicit inputs, checks, publication, and outcome verification for every channel. If agents participate in a release, they should do more than upload a file: they should prove that the intended artifact was published and the resulting link works.
A tiny archiver revealed a large distribution problem. That is exactly why it is interesting: a dependable path built for Cubrim can later serve other independent software products.
The first public Cubrim release is available on GitHub. If you ship desktop applications and have dealt with signing, installers, or multiple stores, join the Arcanada discussion on Telegram and tell me which part of the release path consumes the most time.