![I'm Building My Own PDF Tool to Escape Adobe Tax — Here's How It's Going [Devlog #1]](https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F3z3w4d4h0jp2i85311le.png)
A few days ago I published a post about building a PDF tool in Rust because I got tired of paying for Adobe.
It got more attention than I expected, so I figured: why not document the actual build process as I go?
This is devlog #1.
Why Rust + Tauri + PDFKit? (The hybrid approach)
The first real problem when building a PDF app: which PDF engine do you use?
I went through a few options before landing on a "hybrid" architecture.
Pure lopdf (Rust)
My first instinct was to handle everything in Rust with lopdf. Clean, fast, no Apple dependencies.
Reality: macOS PDF rendering is surprisingly deep. lopdf is great for manipulation, but high-quality rendering alone is rough.
macOS PDFKit (Swift)
Apple's native PDF engine — excellent rendering quality, it's what Preview uses.
The catch: bridging it cleanly from Tauri's Rust backend takes work.
The solution: clear separation of concerns
PDFKit → page rendering, redaction
lopdf → Bates numbering, metadata manipulation
Swift → Apple Vision API (OCR), Core Image filters
Rust → encryption, batch logic, all business logic
Each layer has one clear job. Much cleaner than trying to force one engine to do everything.
What I'm building right now
Currently working on the Sanctuary Automator — a workflow engine that chains operations like OCR → compress → save into a single click.
Still rough in the dev build, but the pipeline architecture is coming together.
Next devlog
Calling Apple Vision API from Tauri for offline OCR — bridging Swift into Rust/Tauri isn't well documented. I'll walk through how I got it working.
Hiyoko PDF Vault → https://hiyokoko.gumroad.com/l/HiyokoPDFVault
X → @hiyoyok
