一个PDF工具开发者的原生应用执念与妥协

作者打开8年前的MacBook Air跑完所有测试，然后决定做一件"反直觉"的事——把本该是网页的应用，硬做成了原生Mac程序。

这不是情怀作祟。是算完账之后的取舍，也是踩完坑之后的坦诚复盘。

隐私不是卖点，是底线

浏览器里的PDF工具，文件总要经过某个服务器。哪怕是"纯前端"方案，也有灰色地带：埋点数据、崩溃上报、从CDN加载的第三方库。

原生应用可以做到零网络请求。对于合同、病历、税务文件这类场景，"文件绝不出本机"不是营销话术，是唯一能兑现的承诺。

作者的原话很直接：「A native app with no network calls is the only architecture where 'your files never leave your machine' is actually true.」

这条红线画死了技术选型。网页应用再方便，也给不了这个确定性。

苹果生态的API护城河

macOS给原生开发者留了一整套工具：Vision框架做OCR识别，PDFKit渲染文档，Core Image处理滤镜，FSEvents监控文件变动。

这些在浏览器里要么没有，要么体验断崖式下跌。网页版的"等效方案"作者用了个词：dramatically worse。

性能差距在重负载场景会放大。500页的PDF在浏览器里处理，主线程直接卡死；用Rust写底层逻辑的原生应用，UI始终保持响应。

8年老Mac能扛住测试，靠的不是魔法，是架构选择。

分发是隐形成本

网页应用点击即部署。原生应用要过五关：代码签名、公证、打包DMG、手动更新机制。

作者目前没做代码签名——收入还没摸到苹果开发者计划的门槛。代价是用户首次启动会看到安全警告，体验打折。

跨平台更是死结。Tauri框架支持三端，但作者依赖的PDFKit、Vision、FSEvents全是macOS独占。Windows和Linux用户被战略性放弃。

触达难度也不一样。App Store有算法推荐，Gumroad没有。被用户发现需要主动营销，而这会从开发时间里抽血。

verdict：对的产品，贵的代价

作者给的结论很清醒：

选对了吗？对。隐私约束和API依赖决定了，原生是唯一可行路径。

后悔吗？部分。如果以覆盖率为首要目标，网页应用首日的潜在用户池是10倍量级。

这是一个典型的技术决策样本：没有完美解，只有优先级排序。把什么放在天平上，决定了你站在哪一边。

产品叫Hiyoko PDF Vault，目前在Gumroad分发。作者@hiyoyok在X上持续更新开发日志——感兴趣可以去围观一个独立开发者的真实账本。

（对了，如果你也在纠结原生还是网页，作者的建议藏在上面的数字里：10倍用户池 vs 零网络请求的隐私承诺。选哪个，取决于你的用户愿意为后者付多少溢价。）