Breeze: a Flutter manga reader that loads sources as plugins

What Breeze solves, and for whom

Reading manga across several sources usually means keeping several apps or several browser tabs open, each with its own reader, its own history and its own download folder. Breeze takes the opposite route: one reader, and each source arrives as a plugin. The repository description lists 哔咔, 禁漫, ehentai, nhentai, 再漫画, 拷贝漫画, NoyAcg, komiic, 包子漫画 and 绅士漫画 as the sources it currently supports.

The audience is narrow and specific. It is for readers who already know which sources they use, want a single library and reading history across them, and are willing to install an unsigned application on iOS or macOS. It is not aimed at people who want a source-agnostic catalogue with editorial metadata, and it is not aimed at developers looking for a stable extension contract, which the README addresses directly.

One structural detail matters more than the feature list. Breeze is a Flutter application with a Rust component, and the repository layout reflects that: lib/ holds the Dart application, rust/ holds the native side, and packages/ holds the plugin-facing code. The plugin documentation lives outside the repository at deretame.github.io/plugin-dev-docs, and the plugin list lives in a separate repository, deretame/Breeze-plugin-list.

How the plugin and Rust layers fit together

The mechanism visible in the repository is a Flutter shell around two native concerns. The first is plugin loading: sources are not compiled into the application, they are distributed separately, which is why the plugin list is its own repository and why the development guide is published as a separate documentation site. The second is image processing. The README credits the Aidoku project for the approach and model handling used in the iOS and macOS image upscaling implementation, and the repository contains an aidoku-upscale-cli/ directory alongside rust/ and flutter_rust_bridge.yaml.

That flutter_rust_bridge.yaml file is the part worth understanding before you try to build. It indicates the Dart and Rust sides communicate through generated bindings rather than a hand-written FFI layer. The README's toolchain section confirms the consequences: Rust is installed through rustup with cross-compilation targets such as aarch64-linux-android, and LLVM or Clang must be present because libraries such as rustqjs parse C headers. LIBCLANG_PATH exists so bindgen can generate FFI bindings. A build that skips LLVM will fail at binding generation, not at the Dart layer, which is a confusing place to land if you are new to the project.

Data flow at runtime is conventional for this class of app: the plugin fetches source content, the reader renders it, and the upscaling path runs through Rust on the platforms where it is implemented. The README does not describe the plugin transport format or the request path in detail, so anything beyond that would be speculation.

Installing Breeze on Android, Windows, Linux and macOS

Installation is per-platform and mostly means downloading an artifact from the Releases page. On Android the README points to app-arm64-v8a-release.apk and notes that in mainland China the app may not install because it is not reviewed, suggesting GBox, 出境易 or GSpace as workarounds for the system installer. On Windows the artifact is windows-installer.exe and running it completes the install.

Linux ships two formats. The DEB path is the one the README recommends for Debian, Ubuntu and derivatives, and apt resolves the system dependencies:

sudo apt install ./breeze_*.deb

After that, Breeze appears in the application menu, and the terminal command is:

breeze

Removal is `sudo apt remove breeze`. The README states plainly that the DEB package is not guaranteed to work on every Debian or Ubuntu derivative, and that you should switch to Flatpak if installation or startup misbehaves. The Flatpak path needs the runtime first, since the project is built against GNOME 50:

flatpak install flathub org.gnome.Platform//50
flatpak install --user breeze.flatpak
flatpak run io.github.windy.breeze

Note the application ID: io.github.windy.breeze, not a name matching the repository. On macOS the README recommends Homebrew over the DMG:

brew tap deretame/breeze
brew install --cask breeze

Upgrades use `brew upgrade breeze`, and `brew uninstall --zap breeze` removes the app together with its database, cache and configuration files. If you install from the DMG instead, the app is unsigned, so a first launch blocked by Gatekeeper is cleared with:

xattr -cr /Applications/Breeze.app

iOS sideloading is the real barrier

Breeze is not on the App Store, so the iOS and iPadOS route is sideloading a signed-by-you build. The README points to Breeze-iOS.ipa on the Releases page and lists AltStore as the recommended tool, with Sideloadly and TrollStore as alternatives. AltStore's own documentation and third-party tutorials are linked from the README rather than reproduced in it.

This is not a small caveat. Sideloaded applications expire and need re-signing, which is why AltStore's selling point is automatic renewal from a computer on the same local network. TrollStore avoids expiry entirely, but only on iOS versions inside its supported vulnerability range, which the README links out to rather than enumerating. If you are on a current iOS version outside that range, your practical choice is a seven-day or yearly signing cycle depending on your tooling.

The same friction shows up on macOS in a milder form. An unsigned application is a Gatekeeper prompt, and the README's xattr command is the documented answer. On Windows and Linux the install is ordinary. So the platform you are on determines whether Breeze is a two-minute install or an ongoing maintenance task.

Building from source is a different project

The README separates installation from development, and the development section is substantially longer. You need Flutter SDK verified through `flutter doctor`, a Rust toolchain installed through rustup with cross-compilation targets, and LLVM or Clang. Three environment variables are called out as required: JAVA_HOME for Android and for Windows and Linux builds, ANDROID_NDK_HOME for Rust cross-compilation to Android, and LIBCLANG_PATH for bindgen. The README also notes that javac and clang must be on PATH.

Dependency initialization is a single command at the repository root:

flutter pub get

Platform notes are terse. Android needs local.properties pointing at the correct SDK path. Windows and Linux need Visual Studio with C++ or a GCC toolchain so Rust can compile natively. The repository also carries .fvmrc and .puro.json, which suggests the project pins its Flutter version through one of those managers, though the README does not name which one it expects you to use.

If your goal is only to read manga, none of this applies. If your goal is to modify the reader or the native layer, budget time for the toolchain before you touch the code, because the binding generation step depends on environment variables that fail silently if unset.

The plugin API is beta, and the README says so

The most useful limitation is stated by the project itself. The README notes that plugin functionality is still in beta, that it may change significantly, and that building plugins on it is not recommended, with learning use as the suggested purpose. That is an unusually direct warning, and it should decide the question for anyone planning a plugin as a product.

There is a second constraint in the same paragraph: the plugin documentation is hosted on a separate site, deretame.github.io/plugin-dev-docs, and the plugin list is a separate repository. Nothing in the README describes a versioning or compatibility contract between the application and the plugins it loads. A plugin that works against v3.0.31 has no documented guarantee against v3.0.32.

A third limitation is legal rather than technical. The project ships a long disclaimer stating that it is provided as is, with no warranty of fitness, stability or security, and that users must assess whether their use complies with the laws of their jurisdiction. The sources the plugins target are third-party services with their own terms. Breeze does not resolve that question, and the disclaimer makes clear it does not intend to.

Finally, there is no homepage field on the repository, so the documentation site and the plugin list are the places to look, not a product site.

Where Breeze differs from Aidoku and Tachiyomi-style readers

The obvious comparison is Aidoku, and the README makes the relationship concrete rather than vague: Breeze references Aidoku's approach and model handling for iOS and macOS image upscaling. Beyond that shared technique, the two differ in what they are built on. Aidoku is a native Swift application for Apple platforms. Breeze is Flutter, and its platform list covers Android, iOS, Windows, Linux and macOS, with the repository topics naming android, ios, linux, macos and windows explicitly. If you only use Apple devices, the native approach is the more direct one; if you want the same reader on a Windows desktop and an Android phone, Flutter is the reason Breeze exists in that shape.

The second comparison is the Tachiyomi lineage of Android readers, which are Android-only by construction. That difference cuts both ways. A Flutter application with a Rust image pipeline carries more build complexity, which the README's toolchain requirements make visible, and the DEB compatibility caveat on Linux is a symptom of that. The payoff is a single codebase across five platforms and a plugin format that is not tied to Android's extension model.

A fair summary: Breeze trades build and packaging simplicity for platform reach, and it is honest about the beta state of the extension surface that reach depends on.

Licence and maintenance signals

Breeze is licensed under MPL-2.0, a file-level copyleft licence. In practice that means modifications to MPL-covered files must be made available under the same licence when distributed, while larger works that combine MPL files with other code can be licensed differently. This is a general description of the licence, not legal advice; if you plan to redistribute a modified Breeze, read the LICENSE file in the repository and get your own counsel.

On maintenance, the evidence is recent activity rather than a promise. The last push to the default branch was on 2026-09-24, and the most recent release, v3.0.31, was published on 2026-09-13, with v3.0.30 and v3.0.29 before it in early September. The repository is not archived. That pattern suggests a project that is being worked on now, and the README's own beta warning about plugins is the caveat that matters more than the release cadence.

Upgrade cost differs sharply by platform. Homebrew users run `brew upgrade breeze` and get the new version; Flatpak and DEB users re-download the artifact; iOS users re-sign. The README does not document a migration path for the app's internal database, and `brew uninstall --zap breeze` explicitly clears that database, cache and configuration, so treat a full uninstall as destructive unless you have exported what you need.

Editorial conclusion

Adopt Breeze if you want one reader that aggregates several comic sources, and you are comfortable installing an unsigned build: the iOS IPA needs sideloading, the macOS DMG needs a Gatekeeper bypass, and the Android APK may not install from the system installer in mainland China. Do not adopt it if you need a stable plugin API to build against, because the README states plugin support is in beta and not recommended for plugin development. Before installing, check the Releases page for the artifact matching your platform, and verify that the Flatpak runtime org.gnome.Platform//50 is available on your system.

Frequently asked questions

Official sources

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