Olib: a Flutter ebook reader built with AI assistance and no backend of its own

A frontend with no backend, stated plainly by the project itself

The repository description says it in four clauses: an open-source ebook reader built entirely with AI assistance, a third-party client, frontend interface only, all data from external sources. The README repeats it as a disclaimer, warning that Olib is an independent client, is not an official client, is not affiliated with any official service, and that all book data comes from external sources.

That is an unusual amount of upfront hedging, and it is load-bearing. There is no API in this repository, no catalogue, no download service and no account system. What exists is a Flutter app that talks to servers you choose, which the feature table describes as multi-domain, meaning you can pick between multiple server lines. Offline reading comes from downloading books into local storage.

The feature list is short enough to state fully: search by title, author, ISBN or keywords; offline reading; dark mode; 16 or more languages including English, Chinese, Japanese and Korean; multi-account switching; multi-domain server selection; and no ads, subscriptions or hidden costs. That last claim is about the client, not about the upstream services, which is a distinction worth holding on to when you read the legal notice later.

Flutter, Riverpod and Hive in a conventional lib layout

The technology choices are unremarkable in the best way. The tech stack lists Flutter for the framework, Riverpod for state management, Hive for local storage and the `http` package for network calls, with localization covering 16 or more languages. The GitHub language for the repository is Dart, which matches.

The directory layout follows from that:

flutter pub get
flutter run

and the `lib/` tree is split into `l10n/` for localization files, `models/` for data models, `providers/` for Riverpod state, `routes/` for navigation, `screens/` for UI, `services/` for API and storage, `theme/` for theme configuration and `widgets/` for reusable components. Nothing surprising lives in there, which means a reader can navigate it without prior knowledge of the project.

The repository root is broader than the app itself. Alongside `android/` there are `ios/`, `linux/`, `macos/`, `web/` and `windows/`, so the Flutter scaffolding covers all six desktop and mobile platforms even though the installation instructions only describe an Android device or emulator. There is also a `CLAUDE.md`, an `installer.iss` for a Windows installer, a `scripts/` directory, and four README translations: `README_ZH.md`, `README_JA.md`, `README_KO.md` and the English original.

One inconsistency worth naming: the repository's license field reads `NOASSERTION` rather than a specific identifier, while the README states the project is under the MIT License and links a `LICENSE` file, and the tree does contain one. The README claim and the file are consistent with each other, so the odd value is in the metadata rather than in the licensing.

Three releases, and a tidy-up that says something about the project

The release history is short and tells a clear story. `v1.2.0` on 2026-05-27 added paginated mixed recommendations on the home page plus a way to skip login, integrated WeChat Reading with a unified bookshelf, and introduced a `DisplayBook` model to unify how books are shown. `v1.2.1` on 2026-05-29 is a single line: it removed certain sensitive book-site terms from the UI and comments.

That one-line release is the most informative entry in the history. It says the project had been naming a particular book site in its interface and decided not to, which is a choice about exposure rather than about code. It also implies the service layer is aware of specific upstream providers rather than talking to a single abstract API.

`v1.3.0` on 2026-07-17 is the substantial one. It adds wireless book transfer, where scanning a QR code on the desktop lets you pull a book from the computer to the phone or send one back, with book lists syncing both ways, and it requires the newer desktop companion on both devices sharing a Wi-Fi network. The same release replaced QR code login with a unified account system, so existing users have to scan once again, and it stopped blaming a user's credentials when a login failed because the server line was blocked, and stopped a QR page from popping back two screens, and made the bookshelf filter bar scroll horizontally on narrow screens.

The last push recorded for the repository is 2026-07-17, the same day as `v1.3.0`, so the code and the newest release line up. The default branch is `main`, there are 24 open issues, and the repository is not archived.

A project that states its own provenance four times over

The README devotes real space to the fact that it was built with AI assistance, listing architecture design, code implementation, UI and UX design and documentation as all AI-produced. There is an `AI Built` badge and the acknowledgment section repeats it. This is unusual to see stated so prominently and repeatedly.

The practical question is what that changes for a reader. It changes what you should expect from a bug report and from the architecture. An AI-assisted codebase of this size, about which the repository tells you nothing about testing, gives you no signal about regression coverage. There is no test suite in the tree, no CI configuration beyond a `.github/` directory, and no changelog beyond the release notes.

The second thing it changes is the documentation shape. The README is short, which fits a project whose feature surface is genuinely small, and the four translations mean the audience is clearly international. But the parts a reader would want, an API contract, a data format, a server configuration screen description, are not in it.

The legal notice is the section to read most carefully. It restates that this is an independent third-party client and not an official application, that all book data comes from external sources and the project provides frontend only, that users are responsible for ensuring compliance with applicable laws, and that by using the software you acknowledge those terms. Whether the app remains functional depends on upstream services it does not control, and the project is explicit that it is not affiliated with any of them.

What a reader can and cannot learn from the repository

Setting expectations matters here, because a repository like this invites the question of whether it is a good base for your own client. Some things are genuinely visible. The build path is `flutter pub get` and `flutter run`, and for a distributable Android artifact the README gives `flutter build apk --release`. The state management, storage and networking libraries are named. The feature list is complete enough to understand the app. The release notes describe three rounds of real fixes.

Other things are not. The README's screenshot section is a placeholder. There is no description of how server lines are configured or added, no documentation of the API the client expects, no account model beyond the mention of a unified login, and no statement about which platforms are actually supported beyond the Android quick start, even though six platform directories exist. The download link in the README points at the project homepage rather than to a release asset.

There is also a licensing file question that is easy to miss. A `LICENSE` file is present in the tree and the README says MIT, which is what you want. But the repository metadata carries no recognised license identifier, so if you are checking licence status programmatically rather than by reading, the metadata will not confirm what the file says.

For a contributor, the README's own list is the honest starting point: fork the project, create a feature branch with `git checkout -b feature/AmazingFeature`, commit, push, and open a pull request. The presence of `CLAUDE.md` and `analysis_options.yaml` tells you the project is set up for both an AI coding workflow and Dart linting, which is consistent with its stated provenance.

Editorial conclusion

Olib is a well-organised client shell rather than a library, and reading it that way tells you what to expect. The `lib/` directory is divided the way a Flutter app usually is, with `l10n/`, `models/`, `providers/`, `routes/`, `screens/`, `services/`, `theme/` and `widgets/`, and the whole thing depends on whatever server the user points it at. The most useful thing the repository tells you is not in the code but in the legal notice: Olib is independent, not affiliated with any official service, and users are responsible for their own compliance. That disclaimer, plus the v1.2.1 change that stripped certain book-site terms out of the UI and comments, sets the frame for how far this project will go. Start at `lib/services/` to see what API it expects, then read the v1.3.0 notes on the desktop companion before deciding whether the cross-device book transfer matters to you.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. shiyi-0x7f/olib-mobile on GitHub