Building your application for release
Building locally
Run arc build and a package will built for your operating system. Build with each operating system you wish you release binaries for.
Once built, navigate to project_name/release/. A zipped copy of the bundle and the unpacked concents are placed here. Navigate into the unpacked folder and launch the executable.
- Windows: launch the executable at
/hello-blink/release/win-unpacked/hello-blink.exe - Linux: launch the executable from the command line
./hello-blink/release/linux-unpacked/hello-blink.- Some systems may require execution permissions:
chmod +x hello-blink
- Some systems may require execution permissions:
- macOS: launch the
.appgenerated in/hello-blink/release/todo
Windows and macOS applications should be code-signed for production releases, as unsigned applications present warning modals by default.
If you are planning on supporting more than one operating system, (or you don't own a Mac to build for OSX), we strongly recommend the use of a multi-OS continuous integration service such as Travis.ci, AppVeyor, CircleCI, or GitHub Actions.
Building on a CI server
We recommend using a CI server to automate the building of applicable versions per operating system.
arc will automatically check the environment variables for a CI token. You can pass it directly into the command with arc build --token <token>.
For a more complete integration example, we've published a blog post demonstrating cross-platform builds with Github Actions.
Package Formats and Installers
Some of the target systems don't use installers, or follow a containerised model. If you aren't familiar with packaging applications for these systems, we recommend the following package formats:
- macOS - DMG / .app
- Windows - NSIS / AppX / Squirrel.Windows
- Linux - AppImage / Snap / Tarball
Windows
The build process creates an executable alongside it's dependancies. We don't currently create installers by default, as installer preference varies by user.
We suggest looking into Wix Toolset for creating a standard Windows installer experience.
macOS
On OSX, the output artifact is a .dmg container which follows the typical macOS install experience.
When the user downloads the image file, it will automatically (depending on browser and preferences) mount as a disk image and display the application icon alongside a shortcut to the user's applications directory.
The user then 'drags' it over to 'install'.
We don't currently offer .pkg style 'installers' as these aren't normally expected for macOS software. Contact us for assistance if needed.
Linux
Distributing your application as a .AppImage or as a Snap package is a good way to support users on a wide skew of platforms with minimal effort.
You can also provide the generic tarball and allow various distro's to package it 'natively', or export directly for a specific distro. The full list of possible build targets is: AppImage, snap, deb, rpm, freebsd, pacman, p5p, apk, 7z, zip, tar.xz, tar.lz, tar.gz, tar.bz2, dir.
The template default is AppImage, and this file is what you directly distribute to end-users (don't zip or 7z it!).