Building a Unified Viewer for Office, Images, and CAD Files in a Single Codebase
When a product team promises full file format support, what they’re really committing to is a never-ending inbox of “can we open this too?” I’ve been on that receiving end—juggling CAD, DOCX, TIFF, and half a dozen other oddball extensions. So I designed my viewer pipeline to stop making me choose. Instead of rebuilding the plane every time a client needs a new format, I built something more like a socket wrench: a host that can swap in new parser heads without touching the interface layer.
The goal wasn’t just technical elegance. It was deployment sanity. By modularizing our input stack and GPU rendering flow, I could tune memory budgets, sandbox third-party parsers, and roll out features incrementally. This is how we moved from monolithic file viewers to something agile, scalable, and crash-resilient. Let me walk you through how we did it—and how you can too.
Building the Interface Layer
Every format has quirks, but 90% of the work is the same: parse, rasterize, display. So I defined a three-point interface: load(), rasterizeToTexture(), and getViewportMetadata(). Each parser—be it for DOCX, PDF, or DWG—plugs into this contract.
This gave frontend devs a clean API. More importantly, it isolated the rendering and memory logic. For instance, TIFF’s multi-page structure and CAD’s massive canvas size both required special GPU handling, but those quirks were buried behind the texture generation logic, never leaking into UI code.
Format Support as Configuration, Not Code
We use Kotlin and Swift for mobile. Our viewer host pulls in a list of supported formats from a config file at compile time. Want to add DWG support for a single client? Add a parser module, flip the feature flag, and you’re done.
We also log usage metrics per format—useful both for debugging and for cost modeling. If your third-party CAD parser charges per document load, you’ll want to know exactly how often it’s invoked. Our logging gave leadership clear ROI charts, which made paying for high-end format support a far easier sell.
PDF remains one of the most universally requested formats, so we ensured its support was both robust and resilient—offering PDF reader capabilities out of the box without compromising performance or stability.
To align with how broader players like Dropbox are unifying document and image searches, we leaned into modularity early, drawing inspiration from their push toward universal search across file formats.
Texture Atlases for Blueprint-Class Files
CAD files bring their own headaches. One blueprint had a 24000x24000px canvas—and yes, it crashed our early builds. Instead of paging on the CPU, we moved to GPU texture atlases. Each tile is its own buffer, loaded lazily and discarded on zoom.
Performance Gains
This gave us two wins: no more memory spikes and massive speed gains when panning. Texture reuse also allowed thumbnail caching with zero redraw penalty. These techniques weren’t novel—but integrating them seamlessly with DOCX and image rendering was.
And with architects like Gehry famously ditching paper, the demand for real-time rendering of cloud-based digital blueprints isn’t slowing down.
Preventing QA Nightmares with Budget Alerts
Mobile doesn’t forgive. If you blow the memory budget, the app doesn’t slow down—it dies. I built a memory profiler into our build that raises alerts when parser output exceeds soft limits. For instance, if a file allocates more than 30MB of texture memory, it’s flagged and downsampled.
Stability and Logging
We also wrote a rollback queue: if memory exceeds the cap, the oldest tiles are freed first. This ensured our app passed soak tests without silent crashes. The profiler also tagged logs with the offending format, so we could flag problematic clients before QA even saw the build.
As GPU hardware faces new memory integrity vulnerabilities, building preemptive safeguards into our tile budget system became more than just a stability strategy—it became a security imperative.
Gating Features with Flags
Feature flags are more than toggles—they’re trust builders. When I ship DWG support, I gate it behind a flag, turn it on only for pilot clients, and collect logs before a full rollout. This lets us catch regressions, crashes, or even UI quirks in isolation.
Executive Trust and Format Deprecation
It also helped with internal politics. I could show execs real usage data before committing to support a new format org-wide. One format—PSD—showed so little usage in logs that we deprecated it entirely without backlash. Feature flags saved us months of unnecessary support.
And if you’re wondering whether this approach holds up in larger orgs, look no further than recent feature flag platform acquisitions that emphasize experiment-driven rollouts as a core investment.
Helping Teams Decide: Build vs Buy
Eventually, every team hits this question: do we build our own parser or license one? I built a decision tree to answer that, based on format complexity, legal risk, maintenance burden, and usage data.
Decision Tools and Prioritization
If a format is trivial (like TXT) and used often, build it. If it’s niche (like STEP) and used once a year, buy. For gray areas, I include crash rate charts and parser stability scores from our profiler. This helps teams make calm, data-backed calls instead of gut guesses.
I’ll also share our format prioritization checklist: it includes business value, client demand, crash history, parser cost, and file sample diversity. That way, we don’t just support the loudest client—we support the smartest roadmap.
Conclusion: One Viewer, Infinite Inputs
When you design for modularity, adding support isn’t a rewrite—it’s a toggle. Our viewer went from “good enough for PDF” to a powerhouse that handles blueprints, spreadsheets, and image stacks—all without bloating our codebase or burning our devs out.
The key wasn’t magic. It was discipline: clean contracts, strict memory budgets, and a culture of testable, reversible rollouts. That’s what turned our viewer into a true universal tool. Not because it opened everything, but because it only needed to open what mattered—when it mattered.
