Why Writing an E-Reader App Is Mostly a Text-Layout Problem

Building "an app" for an e-reader is easy. Building a *reader* is not, and the gap between the two is almost entirely text layout. A usable reader has to do pagination and reflow at arbitrary font sizes and margins, font shaping and hyphenation, and it has to decide a refresh policy — when to issue a fast partial e-ink update and when to pay for a full flash — because getting that wrong shows up as ghosting on every page turn. On top of that sit the features readers assume rather than request: progress tracking, dictionary lookup, highlights and annotations. Two costs are routinely underestimated. First, networking: the system stacks on these devices are old, so anything fetching content over HTTPS generally has to bundle its own TLS library and CA certificate store in order to negotiate with a modern CDN-fronted site. Second, power: the devices suspend aggressively, and any long-running operation has to cooperate with suspend and wake scheduling rather than assume it keeps running. KOReader represents more than a decade of exactly that list. That makes most new reader projects a rewrite-versus-extend decision, and rewrite rarely wins. The productive move is to pick a target where the incumbent is not already strong. A background sync daemon — wake on an RTC timer, fetch new chapters, write EPUB files into the reader's library, sleep — has no GUI and therefore no layout code at all, and can begin life as a shell script. It composes with the existing reader rather than replacing it: the daemon fetches, KOReader on Kindle: KUAL, kindlepw2, and kindlehf renders. That division skips the entire layout problem while still addressing the real complaint in Why Web Serials Break the Stock E-Reader Library Model, and it is the concrete Tier 1 project in Replacing an E-Reader's Userland vs Writing an OS: Three Tiers.