Pixiv Viewer Kai mixes a Vue frontend with Capacitor and Tauri shells

One Vue codebase, two different shell technologies

Pixiv Viewer Kai is described as yet another third party Pixiv application for browsing illustrations, animated images, comics and novels, and it is the app version of the pixiv-viewer project. The unusual part of its architecture is that it ships two native shells from one frontend. Capacitor handles the mobile targets, Android and iOS, while Tauri handles the desktop targets on Windows, macOS and Linux. The package.json scripts make the split explicit, with separate build commands that set a VUE_APP_PLATFORM value before running the web build and then syncing into the native project.

    "dev:web": "cross-env VUE_APP_PLATFORM=android vue-cli-service serve --port 8080",
    "dev:tauri": "cross-env VUE_APP_PLATFORM=tauri tauri dev",
    "build:and": "cross-env BROWSERSLIST_ENV=capacitor VUE_APP_PLATFORM=android pnpm run build:web && npx cap sync android",
    "build:win": "cross-env BROWSERSLIST_ENV=tauri VUE_APP_PLATFORM=tauri tauri build --target x86_64-pc-windows-msvc",
    "build:mac": "cross-env BROWSERSLIST_ENV=tauri VUE_APP_PLATFORM=tauri tauri build --target universal-apple-darwin"

The frontend itself is Vue with Stylus styling, built by vue-cli-service, and the whole thing is a pnpm workspace with pnpm-lock.yaml and pnpm-workspace.yaml in the tree. The preinstall hook runs npx -y only-allow pnpm, so npm installs are refused outright. That workspace layout, with a packages/ directory alongside src/, is what lets one component set serve a phone layout and a desktop layout. The repository was last pushed to on 2026-10-12 and is not archived, so the shell code and the proxy layer are worked on together.

Login options are RefreshToken, OAuth and Cookie

The project describes itself as a no login required Pixiv client, yet it also supports three login methods: RefreshToken, OAuth and Cookie. That combination is worth understanding precisely, because it shapes both what you can reach and what you are trusting. Reading without an account is possible, which is the appeal for people who only want to browse popular work. Logging in with your own credentials is what unlocks the parts of the service tied to an account, such as things tied to your own follows or bookmarks. The Cookie option is the bluntest of the three, since a session cookie is a bearer credential for the whole session. The environment file shows where the login flow is aimed: it has a separate default for the AppAPI proxy that includes the OAuth token endpoint and the app API ranking endpoint as examples of what gets rewritten. Anyone running this on a shared machine should think about where those credentials sit in local storage before enabling the Cookie path.

Image and API proxies are configured through VUE_APP variables

The .env.example file is the most informative part of the repository, and it is where the identity proxy design becomes clear. The defaults point at a hosted instance rather than at pixiv's own hosts.

VUE_APP_DEF_HIBIAPI_MAIN=https://api.pxve.cc
VUE_APP_DEF_PXIMG_MAIN=i.pixiv.re
VUE_APP_DEF_APP_API_PROXY=proxy.example.com
VUE_APP_COMMON_PROXY=https://proxy.example.com/
VUE_APP_COMMON_IMAGE_PROXY=https://proxy.example.com/

Three layers of proxying sit side by side. The first is the Pixiv account API instance, whose interface format is compatible with HibiAPI, so a self hosted PxveAPI instance removes the need for HibiAPI. The second is the image host for pximg addresses, which can also be pointed at a PxveAPI instance path. The third is the AppAPI proxy, which rewrites requests to the Pixiv OAuth token endpoint and the app API endpoints, so authentication and API traffic can travel through a proxy you control. A common proxy and a separate common image proxy cover everything else. The file also holds preset lists of image hosts and AppAPI proxies that the user can pick from in settings, plus analytics identifiers for Google Analytics, Microsoft Clarity and Umami, each left unset by default.

Direct connection mode has its own release history

The project advertises direct connection without a proxy, which is the mode where the app talks to pixiv endpoints without a rewrite layer in the middle. The release list shows that mode being worked on separately. Version 1.33.0, tagged on 2026-04-12, is titled in Chinese with a note about fixing direct connection mode, while v1.37.5 on 2026-09-24 and v1.37.6 on 2026-10-01 carry plain version names. That gap in the tagged release list between April and September is worth noting, since it means the published history is not a complete record of what changed. Direct connection is also the mode most exposed to upstream changes, because nothing in the chain translates a changed endpoint or a changed response field for you. The identity proxy layer exists precisely to absorb that, and choosing to skip it moves that work onto you.

Release artifacts cover five platforms with signed and unsigned variants

Distribution runs through GitHub Releases, and the download table shows one release carrying many artifacts. Android is a universal APK, iOS is an unsigned IPA, Windows comes as both an x64 setup executable and an x64 MSI, macOS offers DMG and app bundles for both Apple Silicon and Intel, and Linux ships as deb, rpm, AppImage and an Arch Linux pkg archive. The variety of Linux formats is the tell that this project takes desktop Linux seriously, and having an AppImage means you can try it without a package manager. The unsigned iOS build is the obvious catch: an unsigned IPA needs a signing step of your own before it will install on a device, which is normal for a project without an App Store presence. Note also that the repository contains android/, ios/ and src-tauri/ directories side by side, so both native shells are maintained in the same tree rather than in separate forks.

Licence and version bookkeeping

Two governance details are easy to miss and both matter for adoption. The first is the licence. The repository is licensed under AGPL-3.0, and package.json records it as AGPL-3.0-only, which is the strict reading with no additional permission granted by the author. The network copyleft obligation of the AGPL reaches software that interacts with the application over a network, so a server-side deployment or a modification you distribute internally deserves a careful read of the licence terms rather than an assumption. That is not legal advice, it is a flag for whoever handles compliance. The second is versioning. package.json declares version 1.37.6, matching the latest tagged release, and the scripts include a bump script and a separate check-version script, so version drift between the manifest and the release is something the project actively guards against. A THIRD_PARTY_NOTICES file and a LICENSE file at the top of the tree round out a fairly complete compliance posture for a project of this size.

Where this client is the wrong tool

There are clear cases for reaching for something else. If your requirement is a stable, supported API integration with pixiv for a commercial product, this client is the wrong foundation. Its architecture is built around rewriting endpoints through proxies, and the defaults point at third party infrastructure that nobody guarantees, so your availability is a property of someone else's server. If you need a desktop client with a single window and no login handling, the identity proxy configuration is complexity you do not need. On the development side, the build scripts assume pnpm, a Node toolchain, Rust for the Tauri side and the native Android and iOS toolchains, and the Vue CLI build pipeline rather than Vite is an older choice that will need attention when upgrading the frontend toolchain. The repository also carries an AGENTS.md and a docs/ directory, which suggests documentation exists beyond the README, but the README itself stays focused on the download table and leaves the deeper configuration to the environment file.

Editorial conclusion

Pixiv Viewer Kai suits readers who want a Pixiv client they can configure, self host a compatible API for, or run on a desktop as well as a phone, and it suits people who will read its proxy configuration carefully before relying on it. It does not suit anyone who needs a stable official API path, since the default endpoints point at third party instances that the project does not control, and it does not suit organisations that cannot accept AGPL-3.0 obligations. Before adopting it, read .env.example for every VUE_APP variable, confirm the login method you need among RefreshToken, OAuth and Cookie, and check the v1.37.6 release assets for your platform.

Frequently asked questions

Official sources

1. asadahimeka/pixiv-viewer-app on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases