Most "PDF tools" apps on the Play Store are just wrappers around a cloud API. Upload the file, hit a server, download the result. It's the fastest way to ship — and honestly, the laziest.
When I set out to build PDFMergify, I made one non-negotiable decision early on: every operation had to run entirely on-device. No file upload, no backend, no API key, no server cost. That single constraint shaped almost every technical decision that followed, so I wanted to write up what building an offline-first PDF tool on Android actually looks like.
The stack
Kotlin + Jetpack Compose for UI
PDFBox-Android (a port of Apache PDFBox) for the core merge/split/compress/reorder logic
No Firebase, no backend, no network permissions beyond what's needed for ads
That last point mattered a lot. Once you commit to zero uploads, you also remove an entire category of security and compliance concerns — no server to secure, no data retention policy to write, nothing to leak.
Why offline-first is harder than it sounds
Cloud-based PDF APIs make the hard problems disappear — page rendering, compression algorithms, memory management — because a beefy server handles it. On-device, you don't get that luxury.
A few real constraints I hit:
Memory pressure on large PDFs. Rendering and manipulating a 100+ page PDF entirely in-memory on a mid-range Android phone will crash your app fast. I had to move to streaming page-by-page operations instead of loading the whole document object graph at once, which meant reworking the merge and split logic around PDFBox's incremental APIs rather than the naive "load everything, mutate, save" approach.
Compression without quality APIs. Server-side PDF compressors often lean on proprietary optimization libraries. On-device, I had to build a compression pipeline around image downsampling within embedded PDF images and font subsetting, tuned to balance file size against readability — without a cloud GPU to lean on.
UI responsiveness during heavy I/O. PDF operations are blocking and CPU-heavy. Everything runs on Kotlin coroutines with Dispatchers.IO, with progress state hoisted into Compose so the UI never freezes mid-merge, even on a 200-page file.
The Play Store compliance angle
There's also a non-technical reason offline-first made sense: Play Store policy risk. Apps that transmit user files to opaque backends draw more scrutiny under Google's data-safety and permissions review, especially post-2024 policy tightening. By keeping 100% of processing local:
The Data Safety form is genuinely simple — "no data collected, no data shared" — because it's true, not because it's spun that way.
There's no backend to go down, get rate-limited, or rack up hosting costs as usage scales.
Users in regions with unreliable connectivity (a huge chunk of the Android install base) can use every feature with zero signal.
What shipped
The final feature set stayed intentionally narrow — merge, split, delete pages, reorder, and compress — rather than trying to be a full PDF editor with annotations, forms, and e-signatures. Scope discipline mattered more than feature count; a tool that does five things reliably offline beats one that does twenty things through a flaky API.
If you're building Android tools and considering whether to reach for a cloud API by default, it's worth asking first whether the operation can be done on-device. It's more work upfront, but you get a simpler privacy story, lower operating cost, and an app that works exactly the same on a flagship or a budget phone with no signal.
PDFMergify is live on the Play Store if you want to see the result: Merge & Split PDF
Happy to go deeper on any part of this — the PDFBox integration, the compression pipeline, or Compose state management for long-running file ops — drop a comment.
