Why I Built PDF Max’s Viewer with HTML Canvas
How a shared HTML canvas viewer helps me build PDF Max across platforms, keep scrolling smooth, and spend less time maintaining the same features twice.
Direct answer
Why does PDF Max use an HTML canvas PDF viewer inside a native app?
PDF Max uses a shared HTML canvas viewer so I can build features like zooming, text selection, and annotations once across platforms. The native app handles files, system features, and PDF rendering. The viewer keeps pages visible as you move, then adds sharper detail when it is ready.
I chose HTML canvas for PDF Max’s viewer because maintaining two separate viewers was taking too much of my time. I wanted to improve how people read and edit documents without building every interaction twice.
The idea grew while I was working at Xero. I spent a lot of time in Figma and Miro, often with huge files and boards. They showed me how responsive a browser-based canvas could feel, even with a lot on screen.
One viewer to build and maintain
The original PDF Max had separate native viewers for iOS and Android. Each had its own gestures, text selection, annotations, caches, and bugs. I was the developer for both, so every shared feature meant work in two places.
For the rebuild, I put that document interaction into one shared viewer. It uses HTML canvas, a drawing surface in a web view, to display pages and handle the experience around them. The native app still manages files, windows, menus, sharing, and other system features.
The split is straightforward:
- Native code renders the PDF into small images called tiles.
- The shared viewer arranges those tiles and handles zooming, selection, and annotations.
That means I can improve the viewer once and bring those changes to each platform through its native app.
Keep the page moving, then sharpen it
The biggest lesson was that a page needs to stay visible while you scroll or pinch. A sharp page that briefly disappears feels worse than a slightly soft one that follows your fingers.
PDF Max keeps the page images it already has and moves them immediately during a gesture. While you move, it requests sharper tiles for the area you can see. Once those tiles are ready, it swaps them in together, avoiding a patchwork of sharp and blurry squares.
There’s more work behind that simple idea. Old requests need to be cancelled when you change zoom levels. Images need to be released to keep memory use under control. Touch gestures need different handling from mouse or trackpad scrolling.
Testing also showed that drawing the PDF was often quick. Moving the images into the viewer and putting them on screen could take much longer. Improving that whole path mattered more than making the PDF renderer faster on its own.
What this made possible
The clearest payoff was getting a working Android build in four weeks. The viewer’s layout, zooming, selection, and annotation behavior were already shared, so I could focus on Android’s native app and rendering connection.
AI tools helped with platform code and repetitive work, but having the shared viewer made the biggest difference. Four weeks got me a build that opened and edited real documents; store setup, billing, and wider device testing came afterward. PDF Max is now available on Google Play.
The trade-offs are real
This approach adds complexity. The native app and web view have to coordinate rendering, memory, and requests that may finish after the reader has moved on.
Accessibility also takes extra work. Canvas doesn’t automatically give screen readers a structured document. PDF Max has a separate Reflow reading experience with structured text and read-aloud support, but full accessibility across canvas editing remains ongoing work.
For me, the trade-off is worthwhile. I spend less time keeping two viewers in sync and more time improving PDF Max. That was the reason for choosing this architecture, and it’s still the reason I’m using it.