KillerPDF 2.0: choosing the cross-platform stack

[SteveTheKiller]

I plan to load KillerPDF 1.9.x with features and get them stable there. When 2.0 development begins, I want the work to focus on porting the established application instead of designing major features and changing platforms at the same time.

The KillerPDF.Engine is already UI-free and cross-platform, but the rest of the application still depends on WPF, PDFium, PdfPig and Tesseract. PdfPig is scheduled to be removed during 1.9 as content extraction moves into KillerPDF.Engine. That leaves three major decisions for 2.0:

1. Which cross-platform UI framework should replace or supplement WPF?
2. Which PDF rendering backend should replace or supplement the current PDFium dependency?
3. How should OCR and the remaining native dependencies work across Windows, Linux, macOS and ARM64?

I have not selected the libraries yet. This discussion is for gathering real experience, identifying constraints and deciding what should be prototyped. It is not a vote, and I am not looking for a list of framework names without practical reasoning behind them.

Requirements

The 2.0 stack needs to support:

• Windows, Linux and macOS
• x64 and ARM64
• A consistent desktop interface across platforms
• High-quality and accurate PDF rendering
• Printing and print preview
• Keyboard-heavy workflows
• Accessibility and scaling
• KillerPDF's themes and custom document interface
• Offline OCR
• Reasonable download and installed sizes
• Packaging, updates and file associations on each platform
• Licensing compatible with KillerPDF and GPLv3
• Long-term maintenance without depending on abandoned binary builds

Windows support cannot become worse just to add other platforms. KillerPDF is already a working daily application, so the replacement stack has to preserve its behavior rather than merely display a PDF.

UI options

The obvious .NET candidates include Avalonia, Uno Platform and .NET MAUI. Another possibility is keeping WPF as the Windows front end while building separate interfaces for other platforms.

For each option, I would like to understand:

• How mature is its desktop support on all three operating systems?
• Does it support the windowing, keyboard, drag-and-drop, printing and accessibility behavior KillerPDF needs?
• How much of the existing XAML structure and application logic could be reused?
• What platform-specific code would still be required?
• How stable are its packaging and deployment tools?
• Would maintaining it create one shared interface or several platform-specific variations?

Rendering options

PDFium works well for KillerPDF on Windows, but the current native binaries do not provide the complete platform and architecture coverage required for 2.0.

Possible directions include obtaining or maintaining PDFium builds for every target, using MuPDF, using Poppler, or integrating another renderer behind a KillerPDF-owned abstraction.

The important questions are:

• Rendering accuracy across difficult PDFs
• Support for annotations, forms, transparency, color spaces and modern PDF features
• Threading and lifetime safety
• Native binary availability for every platform and architecture
• Licensing requirements
• Build reproducibility
• Security maintenance
• Whether KillerPDF would need to maintain its own native builds
• Performance and memory use on large documents

KillerPDF.Engine remains the document parser, writer and editor. The renderer only needs to produce accurate page pixels and support the interactive information the desktop application requires.

OCR options

Tesseract currently provides offline OCR, but 2.0 needs a dependable way to package and run it on every supported platform and architecture.

I am open to retaining Tesseract with a better native packaging strategy or evaluating another offline engine. Cloud-only OCR is not an acceptable replacement.

The comparison should include:

• Recognition quality across KillerPDF's supported languages
• Offline operation
• Native platform and ARM64 support
• Model size
• Licensing
• Layout and form recognition
• Performance
• Whether one implementation can behave consistently everywhere

How I plan to decide

Before choosing the 2.0 stack, I want to build small prototypes of the strongest options. Each prototype should open and render files from the KillerPDF corpus, exercise zooming and scrolling, display a representative application shell, and produce real packaging results on the supported platforms.

The decision will be based on evidence from those prototypes, licensing review and maintenance cost. Popularity by itself will not decide it.

If you have direct experience with any of these libraries, especially shipping a real desktop application on Linux or macOS, I would appreciate details about what worked, what broke and what you had to maintain yourself. Links to relevant projects, benchmarks, packaging examples and known limitations are welcome.