Hiddify app: a multi-platform proxy client built on sing-box

What Hiddify app is, and the specific job it does

Hiddify app is a client. The README describes it as "a multi-platform proxy client based on Sing-box universal proxy tool-chain", and the repository layout backs that up: a Dart/Flutter application in lib/, platform folders for android, ios, linux, macos, web and windows, and a hiddify-core submodule that holds the engine. Nothing in the tree is a server component. If you are looking for the panel that issues subscriptions, this is the wrong repository.

The problem it addresses is fragmentation. A user with a Vless subscription, a Wireguard config and an SSH tunnel normally juggles three applications, each with its own routing rules and its own idea of which node is fastest. Hiddify app puts those protocols behind one interface and one profile list. The README lists Vless, Vmess, Reality, TUIC, Hysteria, Wireguard and SSH among the supported protocols, and Sing-box, V2ray, Clash and Clash meta among the accepted configuration formats.

The audience is narrower than the feature list suggests. The README says the client ships "appropriate configuration for Iran, China, Russia and other countries", which tells you the maintainers optimise for users behind restrictive networks who receive a subscription link from someone else. It is not aimed at someone who wants to hand-write routing rules for a corporate network, and it is not aimed at server operators.

How the Flutter shell talks to the sing-box core

The architecture is a thin GUI over a compiled core. Makefile defines CORE_PRODUCT_NAME=hiddify-core and CORE_NAME=hiddify-lib, and it fetches the core from a separate repository: when CHANNEL is prod the URL is https://github.com/hiddify/hiddify-core/releases/download/v$(core.version), otherwise it pulls the draft release. The core version is not pinned in the Makefile itself; it comes from dependencies.properties, which the Makefile includes at the top.

That split matters for anyone debugging. The GUI you see is Dart code in lib/, but the proxy behaviour, the protocol implementations and the routing decisions live in the core artifact downloaded at build time. A bug in how a Reality handshake is negotiated is not a bug you will find in this repository's Dart source.

Around the core, the build is standard Flutter tooling. The Makefile defines get, gen and translate targets, where get runs flutter pub get, gen runs dart run build_runner build --delete-conflicting-outputs, and translate runs dart run slang. Localisation is handled through project.inlang/ and the slang package, which is why the README exists in Farsi, Russian, Simplified Chinese, Japanese and Brazilian Portuguese alongside English. The common-prepare target chains all three, so a contributor's first build step is make common-prepare rather than a bare flutter build.

Installing Hiddify app on Windows, macOS, Linux, Android and iOS

Hiddify app is distributed as prebuilt binaries, not as a package you compile. The README's direct download table points at GitHub release assets: Hiddify-Windows-Setup-x64.exe and Hiddify-Windows-Setup-x64.Msix for Windows, Hiddify-MacOS.dmg and Hiddify-MacOS-Installer.pkg for macOS, Hiddify-Linux-x64.AppImage for Linux, Hiddify-iOS.ipa for iOS, and several Android APKs split by architecture (universal, arm64, arm7, x86_64). The README also links store listings on Google Play, the App Store and the Microsoft Store.

On Linux, the AppImage is the documented path. Download it, mark it executable and run it. The README does not spell out the chmod step, but an AppImage will not launch without it.

chmod +x Hiddify-Linux-x64.AppImage
./Hiddify-Linux-x64.AppImage

Building from source is a different route and the Makefile is explicit that it is per-platform. Running make prepare prints the available targets rather than doing any work:

make prepare
# make android-prepare
# make windows-prepare
# make linux-prepare
# make macos-prepare
# make ios-prepare

For a Linux release build the repository provides a Dockerfile, and its header comment states it is "executed via the 'linux-release-docker' command". That container is Ubuntu 22.04, installs the packages listed in linux_deps.list, clones Flutter's stable branch into /root/develop/flutter, and activates fastforge with dart pub global activate fastforge.

FROM ubuntu:22.04
ENV DEBIAN_FRONTEND=noninteractive
COPY linux_deps.list /tmp/linux_deps.list

Once the app is running, the first real use is importing a profile. The README lists subscription links and configuration files as the input, with automatic subscription update and a display of "remaining days and traffic usage" when the provider includes that metadata. You add the link or file, the app parses it as Sing-box, V2ray, Clash or Clash meta, and node selection is delay based. The README does not document a manual step for choosing a protocol; that is decided by the imported configuration.

Where Hiddify app is the wrong tool

The licence is the first thing to check and the hardest to summarise. The repository metadata reports NOASSERTION, which means GitHub's detector could not map LICENSE.md to a recognised SPDX identifier. For an individual downloading a desktop client this is mostly academic. For anyone planning to fork, rebrand or bundle the app, it is the blocking question, and the README does not answer it. Read LICENSE.md directly.

The second limitation is scope. Hiddify app is a client only. There is no server, no subscription panel and no user management in this repository, so a team wanting to issue access to colleagues needs a separate panel. The README says the client is "compatible with all proxy management panels", which is a claim about interoperability, not about Hiddify providing the panel.

The third is that the app inherits the core's release cadence. Because the core is pulled from hiddify-core at build time, a fix in the proxy engine reaches users only when a new app release is cut. Looking at the release history, that cadence is uneven: v4.1.1 arrived on 2026-03-05, v4.0.4 on 2026-02-19, and before those the previous tag was v2.5.7 on 2024-10-03. There is a gap of roughly sixteen months between v2.5.7 and v4.0.4. The last push to the default branch was on 2026-08-10, which is recent, but commit activity is not the same as shipped binaries.

Finally, the documentation in this repository is thin on failure modes. The README does not document rollback, does not explain what error a user sees when a subscription link expires, and does not describe how to export or back up profiles. If you need those guarantees, you are relying on the Telegram support group rather than on written documentation.

Hiddify app compared with a raw sing-box or Clash Meta setup

The obvious alternative is running sing-box itself, without the GUI. sing-box is a command-line tool with a JSON configuration file, and Hiddify app is built on top of it. The difference is not protocol support, since the protocols come from the core either way. The difference is who writes the configuration.

With sing-box directly, you maintain a config file by hand: inbounds, outbounds, routing rules, DNS settings. That is more work, and it is also the reason people choose it. Every routing decision is visible in a file you control, and you can diff it, version it and reproduce it on a server. Hiddify app instead takes a subscription link and derives the configuration for you, which is faster to set up and harder to audit.

Clash Meta is the other comparison the repository invites, since Clash and Clash meta are listed as accepted configuration formats. A Clash Meta user typically works with a YAML profile and a rule set, and the ecosystem around rule providers is larger. Hiddify app's advantage is the single cross-platform binary: the same interface on Android, iOS, Windows, macOS and Linux, with TUN mode and delay-based selection exposed as toggles rather than as config keys.

Pick the raw core if you need reproducible, reviewable configuration or you are automating a deployment. Pick Hiddify app if you receive a subscription link and want it working in under a minute on whichever device you are holding.

Maintenance, upgrades and what the licence leaves open

The last push to the default branch was on 2026-08-10, so the repository is not dormant. The release history is the more useful signal for upgrade planning: v4.1.1 (2026-03-05), v4.0.4 (2026-02-19), and v2.5.7 (2024-10-03). Three tags in the visible list, with a long quiet stretch in the middle. Plan upgrades around releases, not around commits.

Upgrading the app is a download-and-replace operation on every platform the README covers. There is no documented migration step between major versions, and the README does not say whether profiles survive a v2 to v4 upgrade. Back up your subscription links outside the app before you upgrade, because the documentation does not promise they will be preserved.

On licence: the metadata reports NOASSERTION and the repository carries LICENSE.md. That combination means you cannot assume a specific licence from the metadata alone. If you intend to redistribute the app, ship it inside a product, or mirror the builds, read LICENSE.md and, where the terms are unclear, get your own legal advice. Nothing here is legal advice, and the README does not clarify the terms.

The upgrade cost that is easy to miss is the core. Because the Makefile pulls hiddify-core from a release URL keyed on core.version in dependencies.properties, a source build is not reproducible unless you pin that file. Building the same commit twice without pinning can produce different proxy engines.

Editorial conclusion

Adopt Hiddify app if you already have a subscription link or config from a proxy panel and you want one GUI across desktop and mobile. Do not adopt it if you need a server, a managed service, or a client you can redistribute under a known licence. Before installing, open LICENSE.md and read the actual terms, then confirm your provider's config format matches one of Sing-box, V2ray, Clash or Clash meta, because the README does not document what happens when a profile fails to import.

Frequently asked questions

Official sources

1. hiddify/hiddify-app on GitHub
2. Issues
3. Project website
4. README
5. Releases