# Hover builds Flutter desktop apps in Go with a go/ sidecar

> Hover is a Go build tool that compiles a Flutter desktop app into a native binary, with hot reload, packaging formats and cross-compilation through Docker. It suits Flutter developers who want a desktop target, and its README calls it alpha software that can break at any time.

**go-flutter-desktop/hover** — Hover helps developers to release Flutter applications on desktop.

- Repository: https://github.com/go-flutter-desktop/hover
- Website: https://hover.build/
- Stars: 1,003 · Forks: 79
- Language: Go
- License: BSD-3-Clause
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/go-flutter-desktop-hover

## The go/ directory is the whole idea: a Go binary that hosts the Dart VM

Hover is a simple build tool to create Flutter desktop applications, and the way it works is visible in what it generates.

The first thing hover init does inside an existing Flutter project is create a directory called go and add boilerplate files such as Go code and a default logo. That go/ directory is not a build artefact directory. It is the application. The Flutter side is the user interface, and the Go side is the process that hosts it, and the desktop binary is a Go program that starts the Dart VM and wires the two together.

That arrangement is why the README describes hover run as attaching Flutter for hot reload support, and why the hot reload is manual. You press r in the terminal, and the Dart code reloads inside the running Go process, which is the same loop a Flutter developer is used to on a device or in a browser, but with the host being a native binary rather than the Flutter tooling.

Two conventions fall out of the layout. The default entrypoint is the file lib/main_desktop.dart, and you can point elsewhere with the --target flag. And the window icon comes from go/assets/logo.png, which you can replace when you initialise the project.

Plugins are added the same way, by editing go/cmd/options.go, which is a generated file that you take ownership of. This is a real trade of the model: the project gets a working desktop target quickly, and in exchange you maintain a Go file that a code generator has written for you.

## Install needs Go, a C compiler, and the GLFW development headers

Hover uses Go to build a Flutter application to desktop, and hover itself is written in Go, so the first requirement is a Go toolchain. The README says to run go version and make sure the Go version is 1.13 or higher.

The install is a go install, and the README gives three variants depending on your shell:

```bash
GO111MODULE=on go install github.com/go-flutter-desktop/hover@latest
```

```
set GO111MODULE=on
go install github.com/go-flutter-desktop/hover@latest
```

```powershell
$env:GO111MODULE="on"; go get -u -a github.com/go-flutter-desktop/hover@latest
```

The PowerShell variant uses go get rather than go install, which is the older idiom and matches the era of the instructions. You then need the hover binary on your PATH, with the defaults being $GOPATH/bin or $HOME/go/bin, and running the same command again updates to a newer version.

The build dependencies are the part people underestimate. You need a C compiler, with the recommended list linked from the Go wiki's install from source page. On macOS you need Xcode or the Command Line Tools for Xcode, installed with xcode-select --install, for the required headers and libraries. On Ubuntu and Debian-like distributions you need the libgl1-mesa-dev and xorg-dev packages. On CentOS and Fedora-like distributions the list is longer, with libX11-devel, libXcursor-devel, libXrandr-devel, libXinerama-devel, mesa-libGL-devel and libXi-devel.

Those are the GLFW dependencies, and the README links the GLFW documentation for the full details. The size of that dependency list is the practical cost of a tool that puts a native window on the screen, and it is the first thing to check before promising a build works on a new machine.

## Packaging formats and flavors are configured as files you edit

Two extension points sit on top of the build, and both of them are file-based configuration that you own.

Packaging is initialised per format. The README's example is the AppImage format for Linux:

```bash
hover init-packaging linux-appimage
```

That creates a configuration directory at go/packaging/linux-appimage/, which you then update to your needs. After that, the same build command produces a packaged artefact:

```bash
hover build linux-appimage
```

The output lands in go/build/outputs/linux-appimage/, and hover build --help lists all the available packaging formats.

Flavors work the same way and are the more interesting of the two, because they let one project produce different builds without duplicating the configuration. You pass --flavor MY_FLAVOR, and the tool reads go/hover-MY_FLAVOR.yaml. If no flavor is specified, hover always defaults to hover.yaml.

The README's usage line shows the two commands side by side:

```
hover run --flavor develop || hover build --flavor develop
// hover-develop.yaml
```

A flavor file is a copy of hover.yaml with the contents changed, so a develop flavor can point at a different Flutter target, a different logo, or different plugin options, and the same source tree produces a development build and a release build without editing anything shared. The risk of that model is the same as with go/cmd/options.go: the generated files are the ones that carry your per-build decisions, and a hover update that regenerates them can lose those edits. That is a maintenance consequence of a tool that writes into your source tree, and it is worth knowing before you adopt the flavors feature.

## Cross-compilation goes through Docker, and the Dockerfile assembles every packaging tool

Building for an operating system other than your own requires Docker, and the repository's Dockerfile is a good picture of how much machinery a packaged desktop build drags in.

The Dockerfile is a multi-stage build with a stage per packaging tool. There is a snapcraft stage based on snapcore/snapcraft. There is a flutterbuilder stage on ubuntu:groovy-20210723 that installs git, curl and unzip and clones Flutter from the beta channel with a shallow single-branch clone, then runs flutter doctor -v to verify it. There is an xarbuilder stage that clones the xar project at tag xar-1.6.1 and patches its configure.ac to work around an OpenSSL API change, referencing an issue in the xar repository, then runs autogen, configure, make and make install. There is a bomutilsbuilder stage for the bomutils project, and an appimagebuilder stage that downloads the continuous appimagetool AppImage from AppImageKit, patches a byte sequence in it to work around an issue referenced in the AppImageKit tracker, extracts it and renames the squashfs-root directory to appimagetool.

Two things stand out. The first is that each packaging format needs its own native tool built from source, patched where it no longer compiles. The second is that the Flutter SDK is pulled from the beta channel, which means the Docker build is not pinned to a Flutter version you control.

The standalone build itself is simpler:

```bash
hover build linux # or darwin or windows
```

The output goes to go/build/outputs/linux, or the windows or darwin equivalent, and the README notes that you can zip the whole directory and ship it to a different machine. The standalone build is described as a JIT mode build, and the start command is the binary inside that outputs directory.

There is also an install-with-docker-image.sh script at the repository root, alongside a docker/ directory and a renovate.json for dependency update automation.

## The README says alpha, and the release tags stopped in 2022

The most important line for any adopter is at the top of the README, in bold. Hover is brand new and under development, it should be considered alpha, anything can break, and you should back up your data before using it.

That warning has been in place for a while, and the release record supports taking it seriously. The recent releases are v0.47.2 on 2022-08-18, with a note that it fixes an issue in the go-flutter repository, v0.47.1 on 2022-07-20 and v0.47.0 on 2021-12-01. The repository is not archived and the last push was on 2026-10-10, so commits are still landing, but there have been no tagged releases since 2022.

That gap between activity and releases is a specific risk. If you install with go install...@latest, the newest tag is what you get: v0.47.2 from 2022, because no newer release exists. The Go module file shows the module path as github.com/go-flutter-desktop/hover, targeting Go 1.26.0 with a toolchain directive of go1.27.2, which is a much newer toolchain than the Go 1.13 floor the README's install section still mentions.

The dependency list is small and sensible for a build tool. cobra provides the command line, aurora colours the output, gopkg.in/yaml.v2 reads the hover.yaml and flavor files, hashicorp/go-version does version comparison, google/uuid generates identifiers, pkg/errors and otiai10/copy handle errors and file copying, JackMordaunt/icns and golang-image-ico produce the macOS and Windows icon formats, and tcnksm/go-latest checks for a newer published version so the tool can tell you that an update exists.

The licence is BSD-3-Clause, with the LICENSE file in the repository as the authoritative text, and this is a licensing statement rather than legal advice. Hover is part of the go-flutter project, and issues are tracked in the go-flutter issue tracker rather than in this repository, which is worth knowing before you file a bug.

## Conclusion

Adopt Hover if you maintain a Flutter application that needs a desktop build and you want the Go sidecar model, hot reload and packaging formats handled by one tool. Do not adopt it if you need a stable, supported build pipeline, because the README describes the project as brand new, under development and alpha, and the only tagged releases are from 2022 even though the repository is still receiving commits. Before you build, install Go 1.13 or newer plus a C compiler and the GLFW dependencies for your platform, and note that the generated go/ directory and the hover.yaml flavor file are files you now own and must maintain.

## FAQ

### How do I install Hover?

Install Go 1.13 or newer first, then run GO111MODULE=on go install github.com/go-flutter-desktop/hover@latest in your home directory, with a set and a PowerShell variant given in the README. Make sure the hover binary is on your PATH, which defaults to $GOPATH/bin or $HOME/go/bin, and rerun the same command to update.

### What does hover init do to my Flutter project?

It creates a directory called go and adds boilerplate files such as Go code and a default logo. You can pass a path argument, such as hover init github.com/my-organization/simpleApplication, and change it later, and the logo can be replaced at go/assets/logo.png since it is used as the window icon.

### How do I build a packaged AppImage with Hover?

Initialise the packaging format with hover init-packaging linux-appimage, update the configuration files in go/packaging/linux-appimage/ to your needs, and then run hover build linux-appimage. The packaging output is placed in go/build/outputs/linux-appimage/, and hover build --help lists the available formats.

### What build dependencies does Hover need on Linux?

On Ubuntu and Debian-like distributions you need the libgl1-mesa-dev and xorg-dev packages, and on CentOS and Fedora-like distributions you need libX11-devel, libXcursor-devel, libXrandr-devel, libXinerama-devel, mesa-libGL-devel and libXi-devel. These are the GLFW dependencies, and on macOS you need Xcode or the Command Line Tools for Xcode.

### Is Hover stable enough to use in a release pipeline?

The README describes Hover as brand new, under development and alpha, warns that anything can break, and asks you to back up your data. The recent tagged releases are v0.47.2 from 2022-08-18, v0.47.1 from 2022-07-20 and v0.47.0 from 2021-12-01, although the repository is not archived and the last push was on 2026-10-10.

## Sources

- [go-flutter-desktop/hover on GitHub](https://github.com/go-flutter-desktop/hover)
- [License: BSD-3-Clause](https://github.com/go-flutter-desktop/hover/blob/master/LICENSE)
- [Project website](https://hover.build/)
- [README](https://github.com/go-flutter-desktop/hover/blob/master/README.md)
- [Releases](https://github.com/go-flutter-desktop/hover/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/go-flutter-desktop-hover