The Readium Swift toolkit is a reading engine, not a reader app

A toolkit that stops short of being an app

The Readium Swift toolkit is described as a toolkit for ebooks, audiobooks and comics written in Swift, and it is the iOS half of a wider effort. The README notes that Readium Mobile is a toolkit written in Swift and Kotlin, which is the shape of the project: one specification, two implementations, so an iOS app and an Android app can present the same publication model. What the toolkit provides is the machinery under a reading app rather than the app itself. The Repository layout confirms the scope, with `Sources/` holding the libraries, a `TestApp` that demonstrates integration, a `Playground/` project, `Tests/`, `Package.swift`, `BuildTools/` and `docs/` with the user guides. The documentation points you to a getting started guide and a Test App, and the guides are organised by task, with separate pages for opening a publication, extracting content, searching, text-to-speech, accessibility, the Navigator and DRM.

The format matrix, including what is not done

The README publishes an explicit status for every format, using a small set of markers for implemented, partially implemented, planned, wanted and not planned. On the ebook side, EPUB in both reflowable and fixed-layout form is implemented, as is PDF, Readium Web Publication is partially implemented and DAISY is marked as wanted. For audiobooks, Readium Audiobook, Zipped Audiobook and standalone audio files such as MP3 and AAC are implemented, with DAISY again wanted. For comics, Readium Divina and CBZ are implemented while CBR, the Comic Book RAR format, is not planned. The second matrix is more revealing for an app developer because it breaks the features down by format rather than by format alone. Pagination, right-to-left support and search in textual content are implemented for reflowable EPUB, fixed-layout EPUB and PDF. Scrolling is implemented for reflowable EPUB and PDF but only wanted for fixed-layout. Highlighting through the Decoration API and text-to-speech are implemented for both EPUB forms and wanted for PDF, and media overlays are planned across the board. The honest reading is that reflowable EPUB is the best served path here, and PDF support is broad but not complete.

The Navigator is where the reading experience is assembled

The Navigator is the layer that renders a publication to the user, and the guides around it are the most implementation-facing part of the documentation. There is an overview of the Navigator, a page on configuring it with user preferences such as font size and colors, and a page on integrating it with SwiftUI, which the guide describes as the glue to set the Navigator up in a SwiftUI application. Then there are guides for implementing highlights, for supporting custom font families in reflowable EPUB, for detecting a tapped image and presenting a detail view for EPUB image preview, and for playing audiobooks with the `AudioNavigator` and reading the metadata of audio files. The separation between the publication model and the Navigator is the architectural point. A `Publication` is a parsed model, the Navigator is a view layer over it, and the highlights implementation is a layer that sits across both. The custom font family guide and the image preview guide are the kind of detail that only a real reading app needs, which is a good sign about the level of the documentation.

Publication models, content extraction and search

Three guides cover the reading pipeline before any rendering happens. Opening a publication parses a publication package such as EPUB or PDF, or a manifest in RWPM form, into Readium `Publication` models. Extracting the content gives you an API to pull the text of a publication out for searching or indexing, and searching uses that to find matches in the textual content and navigate to them. Text-to-speech reads a textual publication aloud using speech synthesis, and an accessibility guide covers inspecting accessibility metadata and presenting it to users, which matters because a reading app that cannot surface the metadata of an accessible EPUB is not really accessible. The separation of extraction from search is what makes the search feature work across formats, and the fact that search in textual content is marked implemented for all three main formats suggests that path is well trodden. The accessible metadata guide, by contrast, reads as a newer area, since the feature matrix does not list accessibility as a per-format row at all.

LCP DRM, OPDS catalogs and what is left to build

Two network and rights features sit alongside the rendering layer. OPDS support is marked implemented for both OPDS Catalog 1.2 and OPDS Catalog 2.0, with authentication for OPDS, OPDS Progression and Readium LCP automatic key retrieval all planned. DRM support is narrower still: Readium LCP is implemented and Adobe ACS is not planned. The guide set includes a page on supporting Readium LCP for opening and rendering LCP protected publications. For a service that hands out licences, LCP is the practical target because it has a defined licence acquisition and passphrase delivery model, whereas Adobe ACS is closed and integration-heavy. A note on the version scheme matters here, since the releases listed are 3.11.1 and 3.9.0 alongside a 4.0.0-alpha.2, and the CocoaPods pod statements in the README are all pinned to the 4.0.0-alpha.2 line. The stable 3.x and the 4.0 alpha are therefore developed in parallel, which is the maintenance reality for anyone integrating this.

Swift Package Manager, CocoaPods, or a local clone

There are three ways to depend on the toolkit, and the documentation treats Swift Package Manager as the recommended one. From Xcode you open File, then Add Packages, and use the GitHub repository for the package URL, `https://github.com/readium/swift-toolkit.git`. You are then free to add one or more of the Readium libraries, and they are designed to work independently, which matters because a PDF-only app does not need the EPUB navigator and a catalogue-only app needs neither. CocoaPods is the second route, with the pod statements added to a Podfile.

source 'https://github.com/readium/podspecs'
source 'https://cdn.cocoapods.org/'

pod 'ReadiumShared', '~> 4.0.0-alpha.2'
pod 'ReadiumStreamer', '~> 4.0.0-alpha.2'
pod 'ReadiumNavigator', '~> 4.0.0-alpha.2'
pod 'ReadiumOPDS', '~> 4.0.0-alpha.2'
pod 'ReadiumLCP', '~> 4.0.0-alpha.2'

The third option is to clone the repository or a fork and depend on the libraries locally. The Test App contains examples of how to use all three dependency managers, which is the fastest way to settle the question. The minimum requirements table is also worth reading before you start, because they move with the major version. The `develop` branch needs iOS 15.0, a Swift 6.2 compiler and Xcode 26.4, while 3.8.0 needs iOS 15.0, Swift 6.0 and Xcode 16.4, and going back, 3.0.0 needs iOS 13.4, Swift 5.10 and Xcode 15.4, while 2.5.1 and 2.5.0 sit at iOS 11.0 with Swift 5.6.1 and Xcode 13.4. Adopting the alpha means accepting a recent toolchain.

Building from source with XcodeGen and the local LCP package

The Makefile documents the development workflow, and it reveals one implementation detail worth knowing. The `playground` target generates the Playground project, the `dev` target generates both the Playground and the TestApp projects, `podspecs` generates the CocoaPods podspecs, `scripts` bundles the Navigator EPUB scripts, `test` runs the unit tests with an `only` argument to run a single test target, and `lint-format` and `format` handle formatting, with `update-locales` updating the localization files. The interesting part is the LCP handling. The liblcp package is downloaded into the Support directory, and the Makefile comment explains why: so that the Playground and the TestApp share it, because two local packages named `R2LCPClient` in the same Xcode workspace conflict. The `lcp=<url>` variable switches that path on, and the download is a curl of a `Package.swift` into `Support/R2LCPClient/`. After generation the script also fixes the folder name in the project, since a clone in a directory not called swift-toolkit would otherwise leave an undesirable name in the generated Xcode project. For a contributor this means the LCP side of the toolkit is not vendored in the repository and needs a URL to build.

Editorial conclusion

Adopt the Readium Swift toolkit if you are building an iOS reading app and want the publication parsing, resource navigation and LCP DRM handling done for you rather than from scratch. Skip it if you only render text, since this is a full publication stack, and skip it if you need DAISY or Comic Book RAR, since both are marked as not done or wanted. Before you commit, read the feature matrix against the formats you actually publish, because highlighting, text-to-speech and media overlays are supported for some formats and not others, and pin the version because the 4.0 line is still an alpha.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. readium/swift-toolkit on GitHub
4. README
5. Releases