I was tired of PDF editors that took forever to download, launch slowly, and force everything through the cloud. So I built RevPDF - a native PDF editor that's ~20Mb compared to the 300MB bloat of standard industry tools.
I just wanted to edit my resume on the bus, but I found very few options to choose from on mobile. Some were laggy and buggy, many needed subscriptions, and most were cloud-based. Obviously, I didn't want my resume on a random server. I developed RevPDF to be small, roughly 20MB, while many alternatives are 100s of MBs.
Here's how I did it, and the technical trade-offs I made.
The Problem: PDF Editor Bloat
Most popular PDF editors have massive file sizes:
- Standard Industry Reader: ~150Mb
- Other Popular Reader: ~180MB
- RevPDF: ~20MB
Why are they so large? Because they're trying to do everything: cloud sync, telemetry, form builders, advanced graphics, collaboration features, update systems, and bundled runtimes.
Philosophy: Do Less, Better
I analyzed what people actually do with PDF editors daily:
- Read PDFs (obviously)
- Highlight and annotate
- Fill forms
- Merge/split documents
- Basic editing (text, images)
That's it. 95% of users don't need 3D model rendering, advanced digital signatures, or cloud collaboration.
So I built RevPDF to do these core tasks exceptionally well, and nothing else.
Technical Decisions
1. Native Code, No Electron
Decision: Flutter, C++ instead of Electron.
Why: Electron bundles an entire Chromium browser. That's ~100MB right there. Native frameworks give you access to OS-level PDF rendering.
Trade-off: More platform-specific code to maintain, but 10x smaller binaries and much faster startup.
2. Minimal Dependencies
Decision: Write custom components instead of pulling in heavy libraries.
Trade-off: More initial development time, but total control over performance and size.
3. No Cloud Infrastructure
Decision: All processing happens locally. No accounts, no sync, no telemetry.
Why: Beyond privacy benefits, this eliminated the need for networking libraries, authentication systems, and sync engines. Turns out, removing features makes software smaller and more private.
Bonus: This resonated hard with European users. A German tech blog covered it and I got 5k+ downloads.
4. Smart Asset Management
Decision: No bundled fonts, icons as vectors not PNGs, compress everything.
Details: Use Google Fonts instead of bundling custom ones (-20MB).
Performance Results
| Metric | RevPDF |
|---|---|
| Install size | ~30MB |
| Cold start time | 0.7s |
| RAM usage (idle) | 55MB |
| Time to open 50-page PDF | 0.9s |
What I Gave Up
To be clear, RevPDF doesn't do everything:
- ❌ No OCR (use external tools)
- ❌ No advanced digital signatures (basic signing only)
- ❌ No 3D PDF support
- ❌ No cloud sync
- ❌ No plugins/extensions
For 95% of users, these don't matter. For the 5% who need them, there's other tools.
What I Learned
1. Feature subtraction is harder than feature addition
Saying "no" to features is difficult. Everyone wants their use case supported. But every feature has a cost in complexity, size, and maintenance.
2. Users care about speed more than features
The most common feedback: "It's so fast!" People are shocked when software just... works instantly.
3. Privacy as a feature, not just marketing
The "no cloud requirement" wasn't originally a selling point - it was an engineering decision to keep things simple. Turns out, people really care about this.
4. Different markets want different things
US users ask about features. European users ask about privacy and data handling. Both love the speed.
The Code
RevPDF is closed-source for now.
Tech stack:
- Flutter, C++
- Cross-platform build system: CMake
Available for Windows, macOS, and Linux. Desktop is free, mobile has a small one-time purchase to remove watermarks.