# iStore: an OpenWrt app store assembled from standard LuCI pieces

> A script-driven software center for OpenWrt that leans on LuCI rather than replacing it, built for firmware vendors who want their users installing add-ons themselves.

**linkease/istore** — 一个 Openwrt 标准的软件中心，纯脚本实现，只依赖Openwrt标准组件。支持其它固件开发者集成到自己的固件里面。更方便入门用户搜索安装插件。The iStore is a app store for OpenWRT

- Repository: https://github.com/linkease/istore
- Stars: 2,253 · Forks: 442
- Language: Shell
- License: MIT
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/linkease-istore

## What iStore is, and what it is not

iStore is presented as a standard OpenWrt software center, and it is part of the iStoreOS firmware put out by the Yiwu Cloud team. The four design goals it lists are ordinary and concrete: make plugins easy to install, give every plugin a tutorial so a beginner can follow it, adapt to all OpenWrt themes including mobile, and build only on OpenWrt's standard interfaces.

That last goal is the interesting one. iStore is not a new package manager or a replacement for opkg. It is a catalog and an installer sitting on top of what OpenWrt already ships, which is why it describes itself as a pure script implementation depending only on standard OpenWrt components. The repository is reported as Shell, carries an MIT license, and had its last push on 2026-09-25.

What it is not is versioned. There are no GitHub releases at all, so there is no tag to pin a firmware build against and no changelog to read. The feed points at the `main` branch, and that branch is the release. For a vendor baking iStore into an image, that means the image contents are decided the moment the image is compiled, and a plugin upgrade later has nothing to do with the firmware.

## Installing onto official OpenWrt builds

The README restricts installation to two architectures, x86_64 and arm64, and gives one block for both. It is worth reading the block carefully rather than skimming it, because the file it downloads does not come from this repository:

```bash
apk update || opkg update || exit 1
cd /tmp
wget https://github.com/linkease/openwrt-app-actions/raw/main/applications/luci-app-systools/root/usr/share/systools/istore-reinstall.run
chmod 755 istore-reinstall.run
./istore-reinstall.run
```

The `apk update || opkg update` pair is there because OpenWrt has been migrating from opkg to apk, so a script that only knew one of them would break on half the installed base. The installer itself lives in a second repository, `linkease/openwrt-app-actions`, under a path that names `luci-app-systools`. So a vendor adopting iStore is taking a dependency on two repositories, and the second one is fetched as an executable over the network with `chmod 755` immediately after. If you care about what runs on a device, fetch that `.run` file and read it before letting it execute on hardware you cannot easily reflash.

The tree is small and tells you what the project considers its own work: `LICENSE`, `README.md`, a separate `README.en.md`, and directories for `luci/`, `preview/` and `translations/`. The presence of an English README alongside the primary one is worth noting for anyone who assumed the project is Chinese-only, and the `translations/` directory suggests the interface is not locked to a single locale.

## Baking iStore into your own firmware

The vendor path is the feed path. Three commands appended to `feeds.conf.default` are enough to pull iStore into an OpenWrt build tree:

```bash
echo >> feeds.conf.default
echo 'src-git istore https://github.com/linkease/istore;main' >> feeds.conf.default
./scripts/feeds update istore
./scripts/feeds install -d y -p istore luci-app-store
```

The `src-git` line is an ordinary OpenWrt feed definition pointing at the `main` branch, which is why the project can claim plugins can be updated independently of the firmware. The install target is `luci-app-store`, a LuCI application, and the `-d y` flag says to install dependencies without stopping.

The pitch to firmware vendors is stated in the README and it is a real operational argument rather than a slogan: build a minimal image, let users add what they actually need, share the plugin tutorials centrally, and update one plugin version without rebuilding the whole image. The README is explicit about the scope of the official package repository, though. It supports `x86_64` and `arm64` only, and firmware based on OpenWrt for those two architectures can integrate iStore directly. On any other target the feed definition still parses, but there is no stated package source behind it.

## luci-compat and the limit of theme independence

One dependency appears twice in the README and it deserves attention. Firmware at version 19.07 or newer needs `luci-compat` selected, whether iStore is being installed on top of an official image or compiled into a vendor build. The README does not explain what `luci-compat` is, so here are the two facts side by side.

The first is the project's own stated goal: iStore adapts to all OpenWrt themes, and mobile. The second is that on 19.07 and later the LuCI compatibility layer has to be enabled first. Both are true at once, and the useful reading is that the goal applies to current themes while the compatibility flag exists for older layouts. `luci-compat` is the shim that lets the older Lua and JavaScript page construction styles keep working after LuCI reorganized how its interfaces are declared.

The actionable part is what to check when an iStore page renders badly. If your theme predates the LuCI reorganization, select `luci-compat` under the LuCI menu in `make menuconfig` and rebuild. If your theme is current and you still enabled the shim, you have an extra package you did not need. The README states the requirement plainly and leaves the diagnosis to you.

## The dependency failures the README admits to

Most project READMEs sell. This one lists two defects it calls irredeemable, and they are the most useful paragraphs in the document.

The first is that OpenWrt has a very large number of versions, so plugin dependencies differ by platform. The consequence is blunt: a device can install iStore successfully and still be unable to install a plugin from inside it. The second is that firmware vendors integrating iStore have to solve the plugin dependency problem themselves, and stock OpenWrt usually does not have it.

Read together, these say iStore is a distribution channel, not a package dependency resolver. It does not walk the dependency graph, reconcile versions across architectures, or tell you why a plugin refused to install. What it adds is a browsable catalog with per-plugin documentation and an installer entry point. Anything beyond that stays with the image builder.

That changes how you should evaluate a plugin before offering it. The check that matters is whether the plugin's dependencies exist on your specific target, and the README gives you the reason to check rather than the means. On x86_64 and arm64 the official repository covers you. On anything else, expect to supply the packages yourself before the catalog is of any use to your users.

## Reading the repository layout as a vendor

The tree is the fastest way to understand the division of labor. `luci/` holds the web interface, which is where the actual product surface lives. `preview/` holds a single screenshot image. `translations/` holds locale data. `README.md` and `README.en.md` are the two documentation entry points, and `LICENSE` is the MIT text.

Two observations follow from that layout. First, the interface you ship to users is in `luci/`, so if you are retheming, that directory is the only place your changes belong; the shell side of the project is largely the feed and installer plumbing described in the previous sections. Second, the absence of any application or service directory means there is no daemon to configure. iStore does not run on the device in the way a heavier application would. It is files, a feed definition and an installer.

For a firmware vendor, that is a feature. There is nothing to supervise after the image is built, and no runtime configuration to drift. The cost is the dependency gap described above, and the fact that the `main` branch is the only release channel. Pin what you need at compile time, and treat anything after flashing as the user's problem rather than yours.

## Conclusion

iStore earns its place when you build OpenWrt firmware and want users adding packages after flashing, since the feed model lets a plugin version move independently of the image. It is not a dependency solver, and the README says so plainly: on an unusual platform the store installs and the plugin inside it may not. Read `luci/` to see the interface you are shipping, resolve plugin dependencies for your own target architectures, and expect the only versioned moving part to be the `main` branch.

## FAQ

### Does iStore replace opkg or apk on OpenWrt?

No. iStore describes itself as a pure script implementation depending only on standard OpenWrt components, so it presents a catalog and an installer on top of the package manager the firmware already has rather than replacing it.

### Which OpenWrt architectures can install iStore?

The README limits installation to x86_64 and arm64, and states that the official iStore package repository supports those two architectures. On other targets the feed definition still parses but there is no stated package source behind it.

### Why does my firmware need luci-compat before installing iStore?

The README requires luci-compat on OpenWrt 19.07 and newer, both for the installer route and for firmware you compile yourself. It is the compatibility layer that keeps older LuCI page layouts working, so it matters most on themes that predate the LuCI reorganization.

### Can I pin iStore to a specific version in my firmware build?

There are no GitHub releases in this repository, so there is no tag to pin against. The feed definition points at the main branch, which means the contents of your image are fixed at compile time and later plugin updates are independent of the firmware.

### Is it safe to run the iStore install script on a device?

The installer is fetched as an executable over the network from a second repository, linkease/openwrt-app-actions, and made executable immediately with chmod 755. Adopters who need to audit what runs on a device should download that file first and read it before executing it.

## Sources

- [Issues](https://github.com/linkease/istore/issues)
- [License: MIT](https://github.com/linkease/istore/blob/main/LICENSE)
- [linkease/istore on GitHub](https://github.com/linkease/istore)
- [README](https://github.com/linkease/istore/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/linkease-istore