Packaging a Julia application into a native installer has traditionally meant wrestling with platform-specific tooling on each target system. I am pleased to announce AppBundler v1.0 changes that. Turn any Julia application into a Snap (Linux), MSIX (Windows), or DMG (macOS) installer without leaving the Julia ecosystem, using cross-compiled utilities from Yggdrasil instead.
For those following along from earlier announcements, this release marks the first stable version with a substantial API redesign.
Getting started
If you can launch your application with julia --project=. -m MyApp, it’s ready to bundle. Install AppBundler as an app with ]app add AppBundler, make sure ~/.julia/bin is in your PATH, then build:
appbundler build . --build-dir=build --selfsign
This creates a platform-local bundle in the build directory.
This makes it easy to distribute your Julia app to non-technical users via a self-contained installer, avoid setting up packaging tools on every platform, and maintain a simple CI workflow for cross-platform bundling (e.g. Jumbo CI).
Compilation options
| Mode | Best for | Trade-off |
|---|---|---|
| None | Fastest builds, cross-platform bundling | Compilation on the user’s machine |
| Pkgimages | Fast builds, fast startup | Loading overhead, larger binaries |
| Sysimage | Fastest startup | Longer build time |
| JuliaC | Smallest binaries, fastest startup | Requires explicit asset declarations |
Sysimage and pkgimage strategies can be combined for applications that load some packages on demand. In all cases, non-Julia assets referenced with pkgdir(@__MODULE__) remain accessible.
Configuration
The resulting bundle can be configured via command line, LocalPreferences.toml, or by overriding configuration file templates within the project’s meta directory. All major LocalPreferences.toml use cases have been manually tested across all three platforms.
See Jumbo, PeaceFounderClient, BonitoBook, and KomaMRI for real-world use cases, and start experimenting with the listed examples. For detailed configuration and deployment options, see the documentation.
What’s next
With v1.0 shipped, the project enters maintenance mode. A second phase of NLNET funding is lined up, which, if approved, would support further development. Near-term plans include trimming indirect dependencies to speed up installation. If funding comes through, priorities include making code signing robust for Apple notarization, integrating MSIX code signing with a hardware token, and adding Flatpak support. Bundling non-Julia projects (Rust, Go) via cross-compilation is another interesting direction. If any of this aligns with your needs, I’m open to consulting and collaboration — feel free to reach out.