Hiwara: a cross-platform Iwara client built on Tauri and Vue

What it is, and where the compatibility claim comes from

The project describes itself in one line as a cross-platform Iwara client based on Tauri v2, and the README is written bilingually, with a Chinese version followed by an English one throughout. The English text says the app is compatible with the latest Iwara website, that it supports Windows, macOS and Linux on desktop and Android and iOS on mobile, that it is built with Tauri, Vue and TypeScript, and that plans to support HarmonyOS in the future.

The supported platform list confirms the claim in a short bulleted section: Windows, macOS, Linux, Android and iOS. The homepage field is empty and there is no separate documentation site referenced in the README, so the repository itself is the documentation.

Two things about the shape of this project are worth saying plainly at the start. The first is that it is a client for a specific third-party website rather than a general-purpose application, which means its continued usefulness depends on the site's own interfaces staying as they are. The second is that the code is not only an application. The repository contains a tauri-plugin-device/ directory and a tauri-plugin-mwebview/ directory, which are first-party Tauri plugin sources kept in the tree rather than pulled from a registry.

The primary language is Vue, the licence is MPL-2.0, the default branch is main, and the recent releases are v0.3.7, v0.3.6 and v0.3.5, each marked as a beta in its tag name. The last push was on 2026-08-26 and the project is not archived. The 0.x version with beta suffixes on every tag is the clearest signal about where this sits: it is a working application that is still changing shape.

The build chain, and what the package manifest reveals

The repository tree is that of a Tauri application with a Vue frontend. There is src/ for the frontend, src-tauri/ for the Rust side, public/, index.html at the root, vite.config.ts, tsconfig.json and tsconfig.node.json, an edit/ directory, a doc/ directory, and a .vscode/ directory.

The package manifest is more informative than the file list. The scripts section is short: dev runs vite, build runs vue-tsc --noEmit and then vite build, preview runs vite preview, and tauri exposes the Tauri CLI.

The type check is worth noting. vue-tsc --noEmit runs as part of the build rather than as a separate step, so a template type error fails the production build. For a Vue project this is the difference between knowing and not knowing that your templates compile, and it is a good default for anyone shipping an application rather than a prototype.

The dependency list describes the feature set of the application. The Vue side carries vue at 3.5.13, vue-router at 4.6.4, pinia at 3.0.4 for state, vuetify at 3.12.0 for components, vue-i18n at 9.14.4 for translation, swiper at 12.1.3 for carousels, markdown-it with its types, hammerjs for touch gestures, and sass for styling. Icons come from FontAwesome and the icon-park/vue-next set.

The Tauri side is where the interesting choices are. The plugins are @tauri-apps/plugin-dialog, plugin-http, plugin-notification, plugin-opener, plugin-process and plugin-sql. A plugin-sql dependency is a strong signal: the client keeps structured data locally rather than only in memory, which for a media client means downloaded or cached content and session state survive a restart. plugin-http handles network access, plugin-opener opens URLs in the system browser, plugin-process handles process spawning, and plugin-dialog covers native file and folder pickers.

The toolchain is Vite 6 with the Vue plugin, TypeScript at about 5.6, and vue-tsc for the template type check. The dependency versions are all modern, which is consistent with a Tauri v2 application written recently.

Getting it running, and the mobile toolchain is the hard part

The setup section is where this project is most detailed, and it is divided into four environment setups: Rust, Nodejs, Tauri, and then Android and iOS separately. The Rust, Nodejs and Tauri parts are just links to the upstream documentation, but the Android and iOS parts are spelled out in full.

For Android, the requirements are Android Studio with five SDK tools installed: Android SDK Platform, Android SDK Platform-Tools, NDK (Side by side), Android SDK Build-Tools and Android SDK Command-line Tools. Then two environment variables, JAVA_HOME and the pair ANDROID_HOME and NDK_HOME, each with per-platform commands.

The NDK_HOME line is the one to note, because it derives the path rather than hardcoding a version:

rustup target add aarch64-linux-android armv7-linux-androideabi i686-linux-android x86_64-linux-android

That rustup line adds four Android compilation targets, and the count tells you the app is built for 32-bit and 64-bit on both ARM and x86. The NDK_HOME expression in the shell snippets works the same way, selecting the newest directory under the NDK folder, which is the pattern to reuse if your NDK setup has several versions side by side.

For iOS the requirements are Xcode and Homebrew, then Cocoapods installed with brew install cocoapods, and then the iOS rustup targets:

rustup target add aarch64-apple-ios x86_64-apple-ios aarch64-apple-ios-sim

The three targets are the two device architectures and the simulator, and the simulator one is spelled aarch64-apple-ios-sim, which matters on an Apple Silicon machine where the simulator is not x86.

Once the toolchain is in place, the actual workflow is two commands. Install dependencies with npm install in the project root, then run npx tauri dev to start the program in development mode. And once a phone is connected, run npx tauri android run to run it on the mobile device.

Packaging on Windows and Android, and the target matrix

The packaging section is the longest part of the README and the part that says most about how seriously the project takes release engineering.

Windows and Android share a single script, package_app.ps1, which the README says supports both Windows and Android packaging and automatically checks Rust targets before building both. The manual Windows builds then show three explicit target triples, one per architecture:

npx tauri build --target x86_64-pc-windows-msvc    # x64
npx tauri build --target aarch64-pc-windows-msvc   # ARM64
npx tauri build --target i686-pc-windows-msvc      # x86

The three cover x64, ARM64 and x86, and the fact that all three are documented separately says the project intends to ship an ARM64 Windows build, which is a differentiator in a market where most desktop applications are x64 only.

The manual Android build covers the debug-to-device path and the release APK:

npx tauri android run

and the release APK is built with:

npm run tauri android build -- --apk --split-per-abi

The --split-per-abi flag is the notable one. It produces separate APKs per architecture rather than a single universal binary, which keeps download sizes down but means a user has to get the right variant, and it is the right choice when the same app is distributed outside the Play Store.

There is a warning attached to the Android build, that it requires the Android environment setup described earlier, which is a reasonable note given how many variables that section involves.

The script filenames at the top level show the full spread of packaging paths: package_app_windows.ps1 and package_app_android.ps1, package_app_macos.sh, package_app_linux_x64.sh, package_app_linux_arm64.sh, package_app_linux_docker.sh and package_app_wsl_docker.ps1. So there is a native script for every platform, plus two Docker-based Linux paths, one of which is specifically for running the build under WSL.

The Linux packaging story, and building offline

Linux gets the most attention, and for a good reason: it is the platform where cross-compiling and system library conflicts actually bite.

The native script path is package_app_linux_arm64.sh, described as ARM64 cross-compilation producing deb, rpm and appimage formats. And the README is honest about the catch: ARM64 cross-compilation requires ARM64 system libraries, and the x86_64 and ARM64 WebKit libraries conflict, so conflicting packages have to be removed before running. The command it gives removes libwebkit2gtk-4.1-dev, libxdo-dev and libayatana-appindicator3-dev.

That is a genuinely destructive instruction, and it is worth understanding why before running it. WebKit is what a Tauri webview is built on, and the development packages for x86_64 and ARM64 cannot both be installed on one machine because they occupy the same paths with different architectures. Removing them is the price of cross-compiling on a single host, which is why the Docker path exists.

The Docker path is marked as recommended. The script package_app_linux_docker.sh builds in an isolated environment without local system dependencies and supports multi-architecture one-click packaging. The architecture table maps three of them to their own Dockerfiles: x86_64 with docker/Dockerfile.x64 built natively, ARM64 with docker/Dockerfile.arm64 built by cross-compilation, and RISC-V 64 with docker/Dockerfile.riscv64 also cross-compiled, each writing to its own docker/release/ directory.

The script's own interface shows the flexibility:

# x64 + ARM64 all formats (default)
./package_app_linux_docker.sh

# Specify architectures and bundle formats
./package_app_linux_docker.sh --arch x64 arm64 --bundle deb rpm

# Build only x64 deb package
./package_app_linux_docker.sh --arch x64 --bundle deb

The RISC-V 64 target is the interesting one. It is a Linux architecture that is still finding its way into consumer hardware, and shipping a cross-compiled AppImage and packages for it from a project whose main purpose is a video client is a level of commitment to the platform that most client applications do not show.

The offline path is the last piece. The base image can be built locally with debootstrap from the USTC mirror, so no Docker Hub pull is needed, and the --local-base flag does it on first run while -f forces a rebuild of everything including the base image. The priority order is spelled out: use a local debian:trixie-slim if one already exists, otherwise build it with debootstrap under --local-base, and otherwise pull from Docker Hub.

For an organisation in a region where Docker Hub is slow or blocked, that fallback chain is the difference between a build script that works and one that does not.

First-party Tauri plugins, and what they do

Two directories in the repository hold plugin source rather than application code: tauri-plugin-device/ and tauri-plugin-mwebview/. Keeping them in-tree rather than depending on published crates is a deliberate choice, and it has a clear cost and benefit.

The benefit is control. A Tauri application that needs to know something about the device it runs on, or needs to adjust the webview's behaviour, can modify the plugin source and rebuild, without waiting for an upstream release or forking into a separate repository. The cost is that every update to the plugin has to be merged by hand, and the plugin's version is coupled to the application's.

The names suggest the purposes. A device plugin would report hardware and system information the app needs, which for a media client is the kind of thing needed for capability decisions such as hardware decoding or platform-specific playback paths. A mobile webview plugin is the more interesting of the two, because the webview is where the actual site interface is rendered and where the differences between iOS, Android and desktop webviews cause the most friction.

The custom mobile webview is also the piece that explains why a client application exists at all in this form. An Iwara client is mostly a user interface wrapped around the site's own pages, and the parts of that job which are awkward in a plain browser, such as a proper native window, local storage of media, downloads to a chosen folder, and notifications, are exactly what the platform layer provides.

The edit/ directory in the repository root is another signal of the same kind, since it sits alongside src/ rather than inside it, which suggests a localisable or overridable copy of site resources that can be modified without touching the application logic.

How to evaluate it, and the questions to ask first

There are three questions, and the first one is the one most people will not ask.

Is a third-party client for a video hosting site something you want in your environment? The application is compatible with the latest version of the site, but that compatibility is maintained by one small project against a site it does not control. The version is 0.3.7 with beta tags, the last push was on 2026-08-26, and the licence is MPL-2.0, which is permissive for the code and file-level copyleft for modifications. For an organisation that would rather not have a video client on managed devices, the answer may be a plain browser policy instead.

Second, what do you need to build? Desktop only is straightforward, since the Tauri prerequisites and Node are all you need for npx tauri dev on any of the three desktop platforms. Android needs the full Studio toolchain, the NDK and four rustup targets, and it is the platform where the environment setup is longest. iOS needs Xcode, Cocoapods and three rustup targets, and it also needs a Mac. None of that is unusual for Tauri, but the project documents it in detail rather than leaving you to infer it.

Third, and most practically, how do you want to produce releases? The per-platform scripts give you a native build on the platform you are targeting. The Linux Docker scripts give you an isolated build with three architectures and no local system library conflicts, at the cost of needing Docker and, for the offline path, a debootstrap environment. The RISC-V 64 target being included suggests the project cares about platforms beyond the obvious two, and a team that packages for unusual hardware gets a ready-made path.

The pragmatic summary is that this is a well-organised Tauri application whose packaging scripts are considerably more mature than its 0.x version number would suggest, with the cross-compilation and offline-build details being the part worth studying if you are building Tauri applications for multiple Linux architectures yourself.

Editorial conclusion

Adopt Hiwara if you want a native-feeling Iwara client on desktop and mobile from one Vue and Tauri codebase, and if your organisation is comfortable with an application that mirrors a third-party site and depends on that site's interfaces staying stable. Do not adopt it expecting a stable release, since the version is 0.3.7 with beta tags and the last push was on 2026-08-26, and do not run the Linux ARM64 cross-compilation script on a machine with your WebKit development packages installed, because the README requires removing the conflicting x86_64 packages first. Before you commit, set up the Android and iOS toolchains if you need mobile targets, prefer the Docker Linux packaging path over the native one to avoid the WebKit conflict, and read the MPL-2.0 licence, which keeps file-level copyleft on any modifications you distribute.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. README
4. Releases
5. shanmaomaoymmm/hiwara on GitHub