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
  • macOS: launch the .app generated 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, 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 / PKG
  • Windows - NSIS / AppX / Squirrel.Windows
  • Linux - AppImage / Snap


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.


On OSX, the output artifact is a .app which is typically copied into the user's applications directory.

As .app's are essentially a folder of files, most people provide a .dmg image container, or inside an installer package .pkg. We don't currently provide this functionality in our default build output.

There are a range of dmg builder tools. One example is create-dmg. Or you can create a simple one by hand.

  1. Create a folder with the name of your output dmg - Fancy UI is our example name.
  2. Copy your into that folder.
  3. Create a shortcut in that folder pointing at the user's Applications directory.
  4. View options, hidden toolbars, and background images applied to this folder will be retained in the output.
  5. Open the bundled Disk Utility application.
  6. File > New Image > Image From Folder, and then click "Save".


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'.