FlClash ships four platforms, a submodule for its engine, and no iOS build

Four platforms are listed, and iOS is not one of them

The feature list names multi-platform support and then enumerates it: Android, Windows, macOS and Linux. The source tree agrees, with a directory for each of those four and nothing for iOS. That is a real gap rather than an omission in the prose, because the tree is the ground truth and there is no ios directory to build. The rest of the feature list is short and worth reading as a summary of what the project adds rather than what it wraps. There is adaptive layout across screen sizes with multiple colour themes, a design based on Material You with an interface described as similar to Surfboard, data synchronisation over WebDAV, and support for subscription links and a dark mode. The consequence is that the interesting capability here is the packaging and the shell around a core that lives elsewhere, so anyone arriving looking for a proxy engine implementation will not find one in this repository.

The engine is a git submodule, and the only make target fetches it

The Makefile is four lines of shell assignment and two echo statements, and the echo tells you the whole build story. It points out that the submodules target updates git submodules for the ClashMeta core sources, and that the Go core and the Rust helper build automatically through a setup build hook during a flutter build, with a pointer to a commands document in the agent configuration directory. The real target is that one submodule update.

git submodule update --init --recursive

So the client is Dart and Flutter, the traffic-handling core is Go, there is additionally a Rust helper, and none of the Go or Rust code is in this repository. The consequence is immediate for anyone cloning to build: a fresh checkout cannot compile, and the failure appears as a missing package rather than as an instruction. Running make with no target does not build anything either, it prints two lines of help. A contributor who has not read those two lines will reasonably conclude the build system is broken.

Each platform has to be built on a machine running that platform

The build section is organised per platform and each entry names a prerequisite operating system, which together mean there is no single machine that produces all four artefacts. Android needs the Android SDK and the Android NDK installed, plus the NDK path exported as an environment variable. Windows requires a Windows client and, beyond that, a C compiler and Inno Setup. Linux requires a Linux client, and its dependencies are either installed by the setup script or done by hand. macOS requires a macOS client and nothing else listed. The build command is the same shape in every case, passing the platform name to a Dart setup script.

dart setup.dart linux

The consequence is a build matrix rather than a build. On top of the four hosts you need the Flutter and Go environments everywhere, and on Windows two further tools that have nothing to do with Flutter. That is a reasonable arrangement for a small project maintaining four platform artefacts, and it is also why the release cadence is driven by a script rather than by a continuous integration service you could read.

Linux needs a system library installed by hand before the tray icon works

There is one installation step in the readme that is not an installation of FlClash at all, and it comes with a warning marker. Before using the Linux build you are told to make sure a particular indicator library development package is installed.

sudo apt-get install libayatana-appindicator3-dev

The same package appears again in the build section, where the setup script is said to install dependencies automatically or you can install that one yourself. The consequence is that this is a documented prerequisite rather than a bundled dependency, and it is easy to miss, because a missing tray-icon library does not produce an error at launch so much as an interface without a system tray presence. On a desktop that means a running client you cannot reach from the panel, which reads as a bug in the application rather than as a missing system package. Install it first; it costs one command and removes an entire class of confusing report.

The Android intent actions use a package prefix that is not the project's name

Android automation is supported through three intent actions, and they are worth quoting exactly because they do not match the product. There is a start action, a stop action and a toggle action, and all three sit under a package prefix reading com.follow.clash rather than anything derived from FlClash.

com.follow.clash.action.START
com.follow.clash.action.STOP
com.follow.clash.action.TOGGLE

The consequence is for anyone wiring this into a home automation, a tasker profile or a shortcut: you hardcode a package identifier that bears no relation to the repository or the application name, and nothing in the readme flags that it is deliberate. If the identifier is ever changed upstream, every automation built on it stops working, and it will fail silently in the sense that the intent simply resolves to nothing rather than raising an error you would read. Treat the string as an external interface and pin it, and expect to have to revisit it on a major version.

Homebrew covers macOS only, so the other platforms get release archives

Distribution is split three ways and the split follows the platforms unevenly. There is a GitHub releases page and a link to a third-party application repository with a fingerprint in the URL, which is the pattern for verifying an Android build from outside the main distribution channel. Then there is Homebrew, and it is two commands and it is macOS only.

brew tap chen08209/tap
brew install --cask flclash

A cask is the right packaging for a macOS application, so this is not an oversight, but the effect is that Linux and Windows users have no package-manager route described anywhere in the readme. They get release archives, which means no automatic updates and no version pinning handled by a tool. The consequence for an evaluator is that the four platforms are not on equal footing in terms of how you obtain and update them, and the readme does not draw attention to it. The project also runs a Telegram channel, which is where a fast-moving 0.8.x train is most likely to be announced.

Releases move every few days inside a 0.8.x train that is not 1.0

The three most recent releases are v0.8.96 from 2026-08-17, v0.8.97 from 2026-09-10 and v0.8.98 from 2026-09-14, and the last push to main was on 2026-09-27. Read together that is a project shipping roughly fortnightly and then weekly, still short of a 1.0 version, with the branch ahead of the newest tag. The tree shows how that is supported: there is a changelog in Markdown and a machine-readable changelog file beside it, and a Python script whose name suggests it posts releases to the Telegram channel the readme links. The consequence is a genuine trade rather than a defect. You get fixes quickly and you get them without a stable branch to fall back to, so a version pin is close to mandatory for anyone who does not want a client changing behaviour underneath them. For a client that holds your traffic configuration and a WebDAV account, that pin is worth setting on the day you install.

Editorial conclusion

Adopt FlClash when you want a graphical client for an existing Clash-style configuration and you run one of the four platforms it ships, because subscription links, WebDAV sync and an adaptive theme are the parts it adds over a raw core. Do not adopt it on iOS, which is absent from both the feature list and the source tree, and do not expect a package manager on Linux or Windows, since the Homebrew cask covers macOS only. Two things to check before you build from source. Pull the submodules, because the ClashMeta core is not in the repository and a bare clone cannot compile. And budget for one build host per platform: Windows additionally needs a C toolchain and Inno Setup, and Android needs the SDK, the NDK and a set environment variable, so producing all four artefacts means four machines rather than one.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes