When is an installed app worth building?
Start with a job that needs the computer, such as opening a local file while offline. Then plan how people install, trust and update the app on the operating systems you will support.
When does your product need an installed app?
Start with one job that benefits from working on the computer, such as opening a chosen file without an internet connection. If the job only needs a web page and a connection, try that path first.
An installed app adds a download, a way to update it and a plan for each operating system you support. Decide which of those are worth the work for the job.
What does the app keep when the window closes?
Write down which files belong to the person and which settings belong to the app. If people will work offline, decide where their saved work goes and what happens when they reopen the app.
If you later test a real build, verify the app, files and storage all belong to a disposable local setup. Keep live sync, notifications and shared folders disconnected. If you cannot confirm the setup, draw the save and reopen steps on paper.
Compare tools
Scroll the table sideways to read every column.
| Tool | Where you startWhat you build and which tools it needs. | How people install itWhich platform-specific packaging or signing work is yours. | How they get the next versionWhere release files go and what verifies them. | What to keep and verifyWhich app files, settings and personal work must survive. |
|---|---|---|---|---|
| Electron | Use a web interface inside an installed Electron app. | Package for the target system and check its signing and distribution rules. | Built-in automatic updates are for macOS and Windows. Linux uses a separate distribution path. | Keep source, package settings and release files. Check where app settings and notes stay. |
| Tauri | Use a web interface with a system webview and a Rust-based native setup. | Check the target platform’s native tools, installer and signing requirements. | The updater requires signed update artifacts. Check platform installer signing separately. | Keep source, build settings and signing access. Give the app only the local file permissions it needs. |
| Flutter | Use Flutter and Dart to build a desktop interface. Check support for each plugin. | Use the Windows, macOS or Linux distribution path you intend to support. | Plan updates through your chosen store or package channel. Test the exact route you ship. | Keep the editable project, native settings and published build files. Plan to retain user files across updates. |
| Wails | Build a desktop window with web UI and Go for local work. | Build for the intended system and check its web view requirements. | Choose how people get the next build and rehearse the update. | Keep Go, web code, build settings and receipts separately. |
| Qt | Use a cross-platform framework with C++ development help. | Bundle Qt libraries and plugins and check separate dependencies. | Choose a distribution and update path for each target. | Keep project and user data separate. Check license terms by module. |
| Avalonia | Build a .NET desktop interface across Windows, macOS and supported Linux systems. | Choose packaging tools and verify each target’s requirements. | Set up delivery for each target and check an update with existing files. | Keep the C# project and build requirements. The core is MIT-licensed. |
| .NET MAUI | Share C# code across mobile and supported Windows and Mac targets. | Choose the Windows package or folder and a separate Mac Catalyst release. | Choose and test the update route for each platform. | Keep the project and platform signing settings. Save user data separately. |
| Electron Forge | Package an existing Electron app with its release configuration. | Select a maker to produce a target installer or archive. | Configure an update route and a release destination separately. | Keep configuration, signing access and existing user files available. |
| electron-builder | Add packaging configuration to an existing Electron project. | Pick a supported format such as NSIS for Windows or DMG for Mac. | Keep the correct update assets and metadata for your exact target. | Keep the project, packaging settings, signing access and saved user files. |
| Velopack | Add installer and update tooling to a desktop app you already build. | Package for the target and check the required build host and signing. | Point the installed copy to the matching release list and packages. | Save user data outside the replaced install directory. |
What should you check before sending an installer?
Choose one target operating system first. Identify who controls the signing credentials, where the installer is published, and how people will get the next version. Check signing and store requirements for that target.
Keep a copy of the version you distribute and record the installer or store channel it uses. An update should preserve the files the person already created. Test that outcome on a disposable copy before sharing a release.
How can you rehearse the first version and its update?
Draw an installed app for a fictional workshop. Use no real files, accounts, installer or signing credentials.
- Open one fictional noteMark which folder it came from. Show what the person sees when they lose their connection.
- Close and reopenDraw the original note and its saved copy. Write where you expect each to be.
- Try a later version on paperMark which program files change and which notes should remain. List the checks you would run before calling the update ready.