High Tide, a Libadwaita TIDAL client for Linux and what the flatpak route costs you

A native GTK4 client, not a web wrapper

High Tide is a Linux client for the TIDAL streaming service, and the first thing to establish is that it is unofficial. The README carries a prominent note stating that the project is not affiliated in any way with TIDAL and that this is a third-party unofficial client. That disclaimer is not decoration, and it shapes what you should expect from the project and from its release process.

The interface side is what separates it from the alternatives. The project topics list gtk4 and libadwaita, and the description calls it a Libadwaita client. Libadwaita is the GNOME design library that produces the adaptive, rounded, gesture-friendly look of modern GNOME applications, and building a client in it means the app behaves like the rest of your desktop rather than like a web page in a wrapper window.

The implementation is Python. The repository is a meson project, with a src directory, a po directory for translations, a data directory holding the icon and screenshots, build-aux, and a flake.nix with a flake.lock, which means the project can also be built through Nix. The top level also carries high-tide.doap, the standard file for listing an application in the software catalogue of the desktop, which tells you the maintainers are thinking about distribution beyond one flatpak repository.

The style of the project is visible in the small print. The linting is configured through ruff in pyproject.toml, with a line length of 88, a target version of py311, double quotes and space indentation:

[tool.ruff]
line-length = 88
target-version = "py311"

[tool.ruff.format]
quote-style = "double"
indent-style = "space"
line-ending = "auto"
preview = true
docstring-code-format = true

A py311 target with ruff formatting enforced is a fairly modern baseline for a Python desktop application.

Three install routes, and the locales problem in the middle one

Installation is offered in three ways, and the middle one comes with a documented catch.

The first is Flathub, listed in the README as the primary route with a badge linking to the Flathub listing for io.github.nokse22.high-tide. That is the route with the runtime and locales included, and it is the one most users should take.

The second is a build artifact from the project's GitHub Actions page. The instruction is to open the Actions page, click the latest working build and download the Artifact for your architecture, then extract the .flatpak file from the downloaded .zip and install it by clicking it or with the `flatpak install high-tide.flatpak` command.

The warning that follows is the part worth reading twice. Locales are not available when installing from a .flatpak file, because flatpak locales are stored in another runtime for optimisations, and .flatpak files only export the app without runtimes. The documented remedy is blunt: if you want or need locales, build from source.

That is a real limitation, not a rounding error. A German or Japanese user who installs a sideloaded artifact gets an English interface, and the fix requires a compiler toolchain rather than a download. The Flathub route does not have the problem because the full runtime set comes with it.

The third route is building from source as a binary, and it is the shortest instruction in the README. You need the repository and meson:

git clone https://github.com/Nokse22/high-tide.git
meson builddir
meson compile -C builddir
meson install -C builddir

There is also a graphical route, opening the project in GNOME Builder and clicking Run Project, which tells you the project is set up for the standard GNOME development workflow rather than only for command line builds.

Uninstalling needs the process killed first

The removal instructions are included in the README, which is a small sign of a project that thinks about its users' desktops rather than only about its own growth.

The first step is to terminate the running application. The README notes that Run in background is an option and that pressing ^Q should usually be enough, and otherwise you can run killall high-tide to be sure everything is stopped.

Then the package is removed with flatpak, and the command differs depending on how it was installed:

# When installed system-wide (default)
flatpak uninstall --delete-data io.github.nokse22.high-tide

# When installed for the current user (-u flag at installation)
flatpak uninstall --delete-data -u io.github.nokse22.high-tide

The --delete-data flag is what removes the leftover directories, described in the README as cache, configs and similar junk, so that nothing of yours is left behind.

The order matters and is easy to get wrong. Uninstalling while the application is still running leaves the process holding its data directories, and the removal does not cleanly take the data with it. The killall step is not a formality, it is part of the removal procedure.

A related detail for anyone running from a source build rather than flatpak: the meson install step puts a binary on the system, and the flatpak uninstall commands do not touch it. The README does not document how to remove a source install, which is a small gap in the instructions.

The release history and the state of the code

The repository is not archived, and the last push was on 2026-08-21. Recent tags are v1.3.1 on 2026-04-14, v1.4.0 on 2026-05-16 and v1.5.0 on 2026-06-24, so the last release is a few months old and the branch has moved since.

The version pattern is worth reading. A patch release, then two minor releases inside about two months, is the shape of a project adding features at a steady rate rather than maintaining a stable one. For a client of a third-party service, that is a reasonable trade: the service's own API and features change, so a client that never moved would be broken by an external decision.

The project also has a .envrc file, which is the convention for direnv and lets a developer load the development environment automatically when entering the directory. Combined with flake.nix, that means there are two supported ways to get a working development setup, one declarative and one shell based.

Contributing is documented in a CONTRIBUTING.md file, and the README adds that you can also contact the maintainers on Matrix at a dedicated room. A project that maintains a chat channel alongside a contribution guide is doing the work of onboarding contributors, which is a good sign for anyone considering a pull request.

Where an unofficial TIDAL client is the wrong choice

The first limitation is structural and unavoidable. This is an unofficial client for a commercial streaming service, and the project says so plainly. Any change to the service's authentication, API or playback rules can break the client without warning, and no third-party project can commit to a maintenance schedule for someone else's backend. A user who wants a guaranteed, supported TIDAL experience has to use the official applications, and the honest framing is that High Tide is for people who prefer a native Linux interface and accept the risk that comes with it.

The second limitation is the one the README itself flags. Sideloaded .flatpak files give you an application without its runtimes, which means no locales, and the documented workaround is to build from source. If you install a translated version from Flathub, that problem does not exist, so the practical rule is simple: Flathub for users, artifacts and source builds for people who already have a toolchain.

The third is scope. The project is a client, not a service. It does not manage your subscription, and the README says nothing about account handling, device limits or what happens to your session when the service changes. It is also not a general media player: it plays TIDAL, and for local files you would use something else entirely.

The alternative worth naming is the browser. TIDAL's own web player runs in any browser on any desktop, needs no installation, and is always in sync with the service. The difference in approach is real rather than a matter of taste: the browser player is guaranteed current and comes with the service's full feature set, while High Tide trades that guarantee for a native window, desktop integration, and a Linux-native look that no browser can reproduce. If your priority is the interface, High Tide wins. If your priority is not being surprised by a broken client after a service-side change, the browser is the safer bet.

Editorial conclusion

High Tide fits a Linux user who wants a native GTK4 and Libadwaita interface to TIDAL rather than a browser or an Electron wrapper, and who is comfortable with flatpak or a meson build. It is the wrong choice if you need translations in a sideloaded flatpak, since the documentation states that locales are unavailable from a .flatpak file, and it is not an official client, with the project stating it is not affiliated with TIDAL in any way. Before installing, decide between the Flathub route and building from source, and read the CONTRIBUTING file if you plan to send a patch.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Nokse22/high-tide on GitHub
4. README
5. Releases