Updating Desktop Rust

Summary

Desktop software can be fast, local and secure--critical for good legal technology. But, unlike web apps, desktop applications go stale and require updates for each new build.1 Each such update is a moment of truth for the application’s developers. For some period during the update the application is almost unavoidably non-functional. If things go wrong, the user may be stuck with the current version forever. Worse, a bad update may brick the application altogether. And you’ve worked really, really hard to deliver great software in the first place.2 There are some Rust crates addressing this, but because it is so central to the user experience, this is again an operation Tritium wants to own. So what’s a good approach? Let’s consider a few examples. Background Update Daemon Some applications run a background service which manages updates. Adobe, for example, seems to have a separate auto-update binary called Adobe Acrobat Update Service that runs as a daemon. A separate service running at predictable intervals allows them to ensure pristine conditions for updates at off-peak hours, perhaps with even timing staggered to ensure sufficient bandwidth on the update server. They can manage atomic updates and rollbacks while the user sleeps. Oh, and they also get routine passive telemetry about their installed base as a side effect. But for legal technology, privacy is paramount, and users don’t expect Tritium to phone home when idle. An integrated drafting environment needs to be trusted with reading, editing and redlining confidential and trade secret documents. Surprising the user with separate named processes in Task Manager risks damaging that trust. It also seems over-expansive from a security perspective to keep a possibly elevated, network-accessible application running in the background just to ensure your application remains up-to-date. This approach is out. Asynchronous Background Thread The excellent Zed editor adopts a more nuanced approach. Instead of a separ...