Reverie: a book beyond the page
Turning a paper-shaped reading journal into connected records without discarding its freeform layer.
Try example ↗Reverie Reading adapts a digital reading journal into a native iPhone and iPad application. The original format organizes its experience through hyperlinked pages. The implementation introduces book records that can participate in multiple views while keeping a freeform handwriting layer.
The repository identifies the original product as the Reverie Ink Designs Digital Reading Journal. That lineage matters: this is a native implementation of a referenced product, not an assertion that its original artwork or journal design originated here. This draft examines the inspected data model and does not reproduce the source journal's artwork.
A book gets a stable identity
The Book model uses an app-level UUID and stores attributes such as title, author, reading status and current page. Its comments describe one record feeding the library, a four-tab spread, shelves, logs, challenges and collections. A book can therefore appear in several places without those places becoming separate copies of its identity.
@Model
final class Book {
var id: UUID = UUID()
var title: String = ""
var author: String = ""
var currentPage: Int?
// Other stored fields and relationships omitted.
}One book appears in several views
Change a shared record and inspect the library, journal and reading log.
- One Book ID
- Library · Journal · Reading log
Structure and handwriting have different responsibilities
The README describes SwiftData with CloudKit mirroring for structured records and PencilKit for the freeform ink layer. The data can connect views and support retrieval; the handwritten layer can preserve the way someone wants to arrange a page. The example below shows the shared-record relationship with synthetic data.
The storage model remembers earlier versions
Book.swift documents CloudKit constraints: defaults or optional stored properties, optional relationships, and UUID identity rather than a uniqueness constraint. It also explains why later-added composite storage stays optional. Migration history has become part of the model's shape.
Those storage constraints matter when an existing library opens in a newer version of the app. The shared-record example does not simulate CloudKit, migration or cross-device synchronization.
The browser example shows one synthetic Book ID feeding three views. It does not establish SwiftData persistence, CloudKit sync, PencilKit or device behavior.