Readest is trying to replace several reading apps at once
Readest is a modern rewrite of Foliate that expands the idea far beyond a Linux desktop reader. Its stated target spans macOS, Windows, Linux, Android, iOS, and the web, with Next.js 16 and Tauri v2 underneath. The practical pitch is simple: keep books, progress, annotations, and reading tools in one interface even when the device changes. That is a more useful ambition than another bare EPUB viewer.
The format coverage is a genuine strength rather than a single checkbox. The README lists EPUB, PDF, MOBI, KF8 or AZW3, FB2, CBZ, TXT, and Markdown, then adds audiobook playback and EPUB 3 Media Overlays. Readers can switch between scrolling and pages, search inside a book or across a shelf, customize typography and colors, and use keyboard or screen-reader navigation. Those features make Readest plausible as a daily library.
The reading tools go well beyond display
Annotations, bookmarks, notes, and full-text search cover the expected study workflow. Dictionary and Wikipedia lookup, plus imported Yomitan ZIP or RDICT dictionaries, make it more interesting for language learners. Translation through DeepL and Yandex can operate on a sentence or a whole book. Parallel Read opens 2 documents together in split screen, a specific and uncommon feature that could help with translations, editions, technical references, or source commentary.
Audio receives similarly serious attention. Readest offers text-to-speech, audiobook management, and read-along narration with timed highlighting for EPUB 3 Media Overlays. It can also pair a reflowable EPUB locally with DRM-free MP3, M4A, or M4B narration. Visual aids include a reading ruler, paragraph focus, and speed-reading modes. The combination is broad enough to serve accessibility needs, language practice, and ordinary convenience, although each extra subsystem also enlarges the surface contributors must test.
What happened when we ran it
On our box, dependency installation succeeded in 48 seconds. The pnpm workspace pulled in 1,652 packages and occupied 1,809 MB on disk, while the checkout itself contained 8,759 files, roughly 1,071,434 source lines, and used 233.2 MB. This is not a compact reader library. It is a large monorepo.
There was no repository-level build script or target, so we skipped the build rather than pretending a component-specific command represented the whole product. Tests ran for 357 seconds and failed with exit code 1. Vitest reported 10,184 passed, 46 failed, and 25 skipped out of 10,255 tests. The failures covered 38 test files, while 826 files passed and 4 were skipped. That is a lot of working coverage, but a red suite is still a red suite.
The log names failures in PDF range concurrency, EPUB undeclared-cover handling, server-rendered library search, and a Yomitan importer contract case. It does not establish why those tests failed, so blaming missing Debian packages or application defects would be guesswork. We can say the fresh unprivileged Node 22 container did not reproduce a clean test result. The repository also contains 12 CI workflow files and a Dockerfile.
Contributor setup is heavier than user setup
For an ordinary reader, the README points toward app stores, the project website, and GitHub releases. That route avoids the 1,809 MB dependency tree we measured and is the sensible first trial. For contributors, the story is less direct: a monorepo with no root build target requires understanding which workspace owns the application or platform being changed. The README excerpt sells the product effectively, but it does not make the complete build-and-test path feel equally obvious.
The architecture also means platform breadth can become platform burden. File associations, local dictionaries, media playback, text-to-speech, purchases, databases, server rendering, and sync cross browser, native shell, and mobile boundaries. The 46 failing tests in our run touch several of those seams. A team adopting the code should first identify its intended deployment, run that workspace's specific checks, and verify file access, audio, sync, and accessibility on actual target devices.
Activity is strong, but the issue queue deserves attention
Readest had 23,903 GitHub stars, 107 open issues, a v0.12.6 release dated August 28, 2026, and a last push on August 30, 2026. Taken together, those signals describe an actively developed and widely noticed project, not an abandoned repository with an old badge. The issue total is meaningful but not alarming for an application that supports 6 platform families and many file, network, audio, and accessibility paths.
Still, popularity is not the same as stability. A v0.12.6 version number communicates ongoing pre-1.0 development, and our 38 failing test files show why adopters should validate the exact features they depend on. The roadmap also labels AI-powered summarization and advanced reading statistics as being built, while handwriting annotations remain planned. Do not choose Readest today because of those future items; choose it for the already listed reading, sync, lookup, annotation, and narration capabilities.
It fits as a full reading product, not a drop-in component
In a real stack, Readest belongs at the user-facing reading layer. OPDS and Calibre integration can connect it to an existing catalog, while KOReader sync can bridge progress, notes, and bookmarks to compatible devices. The AGPL-3.0 license matters if an organization modifies and deploys it, so legal and engineering owners should review source-sharing obligations before treating the code as a proprietary foundation. This is a product to operate and maintain, not a tiny rendering package to hide inside another app.
The clearest decision is therefore based on scope. If you want a polished, cross-platform personal reader, start with the packaged v0.12.6 release and test your own formats, sync path, and accessibility needs. If you mainly organize and convert books, Calibre is the more natural center. If e-ink customization dominates, KOReader is the sharper choice; if you want to contribute to Readest itself, budget for a large TypeScript workspace and begin by reproducing or isolating the 46 failures we saw.