Zitann/HarmonyOS-Haps: a curated HAP index for HarmonyOS Next, not an app store

What the HarmonyOS-Haps repository actually is

This is an index, not a package host. The README opens by describing itself as a collection of HAP installation packages for HarmonyOS Next, but the repository tree contains only .agents/, .github/, .gitignore, CONTRIBUTING.md, README.md, apps.yaml and assets/. No .hap binaries are committed. Every entry in the tables is a link to another GitHub repository's releases page, so the download happens on someone else's infrastructure under someone else's licence.

The audience is narrow and specific: people who already own a HarmonyOS Next phone, tablet or PC and want to sideload third-party builds that are not in Huawei's store. The README states plainly that all content is for learning and exchange, and asks rights holders to open an issue for removal. That framing tells you what the maintainers think the project is: a pointer list with a takedown path, not a distribution channel.

The apps.yaml file at the top level is the interesting part of the layout. A README-only list would need a human to edit prose for every new entry; a YAML file next to it suggests the table is generated or at least machine-checked. The README does not document that pipeline, so treat apps.yaml as an implementation detail you can read but should not rely on being the source of truth.

How the index is organised and how entries reach you

The README splits its catalogue into two tables. The first is headed 一次开发，多端部署, which covers applications that run across HarmonyOS form factors. The second is 鸿蒙手机/平板, for phone and tablet packages, and a third section, 鸿蒙电脑, covers PC. Each row carries a software name, a short description, a download link and an update column showing a month-day date such as 09-23.

The data flow is one-directional and manual. A contributor adds a row, the update column records when that entry was last touched, and a reader clicks through to the upstream releases page. Nothing in the repository verifies that the linked release still exists, that the HAP installs, or that the upstream project has not changed its package name. The 更新 dates are entry-maintenance dates as far as the README shows, not upstream release dates, and the README does not explain the distinction.

Coverage is genuinely broad for a single page: emulators such as HX360E for Xbox 360 titles, compatibility layers such as 万花 for Windows programs and HiSH for a Linux shell, network clients including FlClash, Tailscale and Etohos, and media or reading clients such as PiliPlus, Kazumi and MR. The repository's own topics are harmonyos and harmonyos-next, and the primary language is listed as Python, which is consistent with a tooling or validation script rather than the apps themselves.

Installing a HAP from the index with Auto-Installer

The README names 小白调试助手 (Auto-Installer) as the recommended tool for every package in the repository, and links to its releases page on the likuai2010/auto-installer repository. It also links a PDF guide in assets/guide.pdf and a Bilibili video tutorial. Those three links are the entire install documentation the repository provides.

The workflow the README implies is: fetch the installer, fetch a HAP from an upstream release page, then push it to a connected device. The installer is distributed as a GitHub release, so the first step is the same click-through you would do for any of the apps. The README gives no command line for this, so the only concrete reference the repository itself supplies is the guide PDF in assets/.

A second tool is listed: HoKit, from the yabi-zzh/HoKit repository. The README describes it as a one-stop HarmonyOS NEXT development assistant with low-latency screen mirroring, real-time performance monitoring, app parsing, one-click re-signing and file management, on Windows, macOS and Linux. Re-signing matters here, because HAPs built by third parties typically will not carry a signature your device trusts.

The apps.yaml file at the top level of the repository is where the entry data behind the README tables appears to live. The README does not document its schema, so expect to infer the field names from the entries themselves. The README also does not state whether apps.yaml or README.md is authoritative when the two disagree.

Where the index breaks down: no binaries, no versions, no rollback

The single biggest limitation is that the repository does not host what it advertises. If an upstream maintainer deletes a release, renames the repository or changes the package identifier, the row in the README becomes a dead link and nothing in this repository can restore it. The README does not document rollback, does not describe how to downgrade a HAP once installed, and does not list checksums or signatures for any entry.

Version pinning is absent. Download links point at releases pages or, in at least one case, a README file rather than a release. A reader who wants the exact build that was current when a row was added has no way to retrieve it from this repository, because the row records a date, not a tag or a commit.

The licence situation is unresolved. The repository itself declares no licence, so the index content is in a grey area for reuse, and each linked application carries its own licence that the index does not surface. Some entries describe clients for commercial services, and the README's own disclaimer acknowledges that content may need to be removed on request. Treat every row as a pointer whose legal status you have to check at the destination.

Finally, the update column is a weak signal. A date next to an entry says the row was edited, not that the upstream project is healthy. The README does not state a freshness policy, so a stale-looking date is not proof that a package is abandoned, and a recent date is not proof that it works on your device build.

HarmonyOS-Haps compared with installing apps the normal way

The obvious alternative is Huawei's own AppGallery, which distributes signed packages through the platform vendor and handles updates for you. The difference in approach is not cosmetic. AppGallery is a signing and review pipeline; this repository is a text file of hyperlinks. AppGallery can revoke a bad build; this index can only delete a row.

A second alternative is going straight to each upstream project. If you already know you want Phira or Tailscale on HarmonyOS, the upstream releases page gives you the same artifact the index points to, plus that project's own changelog, issue tracker and licence. The index adds exactly one thing: discovery. You find projects here that you would not have searched for, such as 轻启, described as a HarmonyOS page-control recognition tool that skips ad splash screens, or 栖云盾, a local DNS filtering app with AdGuard-style rules.

A third option is building from source. Several listed projects are open source, and building yourself gives you a binary you produced rather than one you downloaded. That path costs a toolchain and time, and the README does not provide build instructions for any entry. For someone who wants a working app tonight, the index plus Auto-Installer is faster; for someone who needs provenance, it is the wrong tool entirely.

Maintenance cost, licensing and what to check before you adopt

The repository was last pushed on 2026-09-23, one day before this writing, so the index itself is being updated. That says nothing about the health of the individual entries, which live in other repositories with their own commit histories. If you depend on a specific row, you are depending on a third party's release cadence that this project does not control and does not report.

Upgrade cost is low for the index and high for your device. Updating a row is a pull request against README.md or apps.yaml. Updating an installed HAP means re-downloading from upstream and reinstalling, and the README does not describe an in-place upgrade path or whether user data survives a reinstall. Plan for that gap before you put anything you care about behind one of these packages.

On licensing: the repository's licence field is unknown, meaning there is no declared licence for the index content. Each linked application has its own terms, and the README's disclaimer asks rights holders to file an issue for removal rather than asserting a grant. That is a takedown posture, not a licence. If you intend to redistribute anything you find here, check the upstream licence yourself; nothing in this repository grants you rights to the binaries.

Before adopting, verify three things: that the upstream release page still resolves, that the upstream project states which HarmonyOS Next versions it targets, and that you have a way to remove a HAP you no longer want. The README covers none of these. The assets/guide.pdf and the Bilibili tutorial are the closest thing to installation support, and they cover the installer, not the packages.

Editorial conclusion

Adopt this index if you already have a HarmonyOS Next device and want one page that lists third-party HAP builds with their upstream release links, and use Auto-Installer as the README recommends. Do not adopt it if you need signed, audited, version-pinned packages, because the repository stores no binaries, declares no licence and offers no rollback path. Before installing anything from the table, open the upstream release page and the upstream licence file yourself, and check the 更新 column date against the release you are about to sideload.

Frequently asked questions

Official sources

1. Issues
2. README
3. Zitann/HarmonyOS-Haps on GitHub