React Native PDF textbook reader: fast opening and automatic cleanup

Problem

Students on this learning platform read whole textbooks inside a React Native app. A textbook is a large PDF. Many students read on phones that already have little free space.

The first version of the library worked, but it had several problems:

• Each screen handled downloads and thumbnails separately. Nothing showed progress, and nothing tracked how much space the books used.
• PDFs were saved in the documents folder. The phone backs up that folder and never cleans it. So every book a student opened stayed on the phone.
• While the PDF engine started, the reader showed a grey skeleton for several seconds. A student could easily think the book had failed to load.
• The PDF renderer was slow. The faster renderer I wanted to use crashed on iOS without changes.
• Tapping a book twice quickly started two downloads and added duplicate thumbnails. It could also crash when the book was opened again.
• The page sidebar stopped at page 15. Students could not jump further into the book.

Solution

I led the mobile team of three developers on this app. I built the library and the reader.

One pipeline for every screen. I built a single library store that every screen uses to open a book. A book moves through clear phases: fetching details, downloading, generating thumbnails, then ready or error. Each step shows progress. Screens read the store through one hook. So each screen no longer manages its own loading state.

Protection against a quick double tap. If a book is already loading, a second load is ignored. New thumbnails are de-duplicated by page number. A file copy clears its target first, so reopening a book no longer crashes.

Something to read immediately. The first page appears as soon as the reader opens, with a "Preparing reader" label. When the full PDF view has loaded, it replaces the preview. Sidebar thumbnails load in batches as the student scrolls. Thumbnail generation stops at the last real page, so students can reach every page of the book.

A stable renderer on both platforms. I moved the reader to a JSI-based PDF renderer and patched it. On iOS it sent events when nothing was listening, and this crashed the app. It also handled single-page mode wrongly. The patch is stored in the repository, so every build includes it.

Storage that manages itself. Book files are now stored in the app's cache folder. The phone does not back up this folder, and it can clear it when it needs space. In the background, books not opened for 30 days are removed. The total size is kept under 500 MB.

Before, changing the thumbnail quality regenerated every cached book at once and froze the screen. Now it marks the books as stale (out of date). Each book is regenerated the next time it is opened.

The trade-offs. The phone may delete a book from the cache folder. Then the student must wait for a new download. I accepted this. A slower reopen sometimes is better than an app that fills the phone without the student knowing. Quality changes follow the same idea. One book takes longer to open the next time. The whole library does not regenerate while the student waits.

Impact

• Students see the first page immediately, instead of a grey screen.
• Opening the same book twice is safe: one download, no duplicate thumbnails, no crash.
• The reader renders faster. The new renderer is stable on iOS as well as Android.
• Every page of a book can be reached from the sidebar.
• The app controls its own storage use, and the student does not need to do anything.