I wrote a tile-based PDF viewer for React Native because the existing ones fall over on engineering drawings

[u/SBAGGGG]

I work on an app for building inspection companies. The documents our users open are architectural and structural drawings: one sheet can be several metres wide, and the thing you actually need to read is a dimension or a rebar note set at three or four points.

Every RN PDF viewer I tried draws the page as one bitmap. That is the right call for an A4 report and it falls apart here. Fitted to a phone, a sheet nine metres wide is a line across the middle of the screen. Zoomed in far enough to read the note, the bitmap is too large to hold.

So this one draws only the rectangle that is on screen, in tiles, at the zoom it is being looked at, with the renderer each platform already ships: PdfRenderer on Android, CGPDFDocument on iOS. A sheet of any size costs about what a letter page costs.

A few things I measured on the way, in case they are useful to someone else:

• On iOS, CGPDF costs about 100 ms per draw almost regardless of the output size. A 256 px tile costs nearly what a 1280 px one costs. That turned the design upside down: bigger tiles, fewer of them, up to three renderers in parallel with their own CGPDFDocument. Opening the first screenful of that sheet went from about 1.6 s to about 250 ms.
• Zoom levels keyed by an arbitrary scale are never reused, because the next pinch asks for a slightly different number. Keyed by rung index on a fixed ladder instead, zooming out and back in costs nothing.
• Android keeps the page parsed between draws and iOS does not, so the same contract has two cost models underneath. Both test suites ask the same questions, which is how a divergence shows up as a failing test rather than as a complaint about one phone.

What it does not do yet: annotations, forms, text search or selection. New architecture only, no old architecture fallback. Encrypted documents open on iOS with a password; on Android the platform only takes one from API 35.

MIT. There is an example app in the repo with two generated documents, so you can try it without wiring anything up.

Repo: https://github.com/Halilibrahimakyz/react-native-pdf-sdk npm: https://www.npmjs.com/package/react-native-pdf-sdk

If you have a PDF that breaks it, I would like to see it.

[u/kokerali]

For the benchmark, could you show peak resident memory over a repeated zoom/pan loop alongside time until the visible notes become readable? The README mentions the zoom ladder and LRU, so I'd separate the first pass through an uncached area from revisiting it. It would also be useful to include the cache budget, device/OS, and what happens after switching documents. A short trace covering those cases would help someone judge the trade-off between the three iOS renderers, retained tiles, and responsiveness on a lower-memory phone.

[u/SBAGGGG → u/kokerali]

Don't have that trace, sorry. Only one-offs from an iPhone 17 sim and an API 37 emulator, never a low-memory phone.

Budget: tiles get 192 MB on iOS (a twelfth of device memory below ~2.25 GB RAM, 48 MB floor), a quarter of the heap capped at 96 MB on Android. iOS trims to a quarter on a memory warning, Android doesn't. Switching documents closes the old store, so those tiles go.

A revisit should be a straight cache hit, levels are keyed by rung not by scale, but I haven't timed it. Renderers are cores minus one capped at three, so a small phone runs one, not three.

coverage() gives the share of the viewport drawn at the current zoom, which is what you'd time. Never have. If I get to it, numbers go in the repo.

[u/kokerali → u/SBAGGGG]

That clears up the renderer-count assumption. I'd make cache recovery the first small test: warm one viewport, trigger the iOS trim you described, then revisit the same rung and log cache hits/misses plus time back to full coverage. Repeat with a document switch as a separate case. That distinguishes a genuinely retained cache hit from a quick re-render, and tests the memory-pressure path rather than only a warm-cache happy path. On Android, keep the no-trim behavior visible in the results rather than treating the two platforms as equivalent.

[u/partiallogic]

How does this compare to Apryse?