The desktop app

A desktop app for your students and teachers, for Linux, Windows and macOS. It is the Vumlo web app in a native window that reads without a connection, keeps what a student writes until there is one, tells them a day and an hour before work is due, and opens from links. It belongs to one institution: it is built from your vumlo.toml and talks to your server only. You build it; Vumlo does not publish installers.

What it does, and does not:

What you need on the server

Release 0.2 or newer: the desktop app uses Idempotency-Key, ETag and the app sign-in with Google (ADR-0058, ADR-0059, ADR-0062). server.public_origin must be the address people will reach (https://...): it is compiled into the app, and the app sends passwords there.

Make it yours

Everything comes from vumlo.toml, as for the web app, and vumlo-cli brand apply:

Key What it becomes
server.public_origin The server the app talks to (compiled in). The identifier of the app is its host, reversed: lms.ucu.edu.ua is ua.edu.ucu.lms.
institution.short_name The name of the app, its window and its shortcut (Vumlo UCU; a short name that is not in Latin letters gives way to the scheme, vumlo-uku, because a Debian package can only be named in ASCII), and, with vumlo-, the URL scheme of its links, vumlo-ucu://..., and the name of the installers, vumlo-ucu_0.2.2_amd64.deb.
institution.name The publisher of the installer and its description (the full name can be long, and in any alphabet).
desktop.url_scheme (optional) The scheme of the links, vumlo- and letters, digits and hyphens. Set it if your short name has no Latin letters; otherwise it is plain vumlo, and two institutions’ apps on one computer would fight over vumlo://.

Sign-in with Google needs nothing more than the web app does ([auth.google], ADR-0047): the same redirect address. The app opens Google in the person’s browser and comes back through a link.

Build it on your computer

You need Node 24, a Rust toolchain (stable) and, per system:

An installer is built on the system it is for. From the directory of this release (or of your repository, if core is vendored: vendor/vumlo-core):

./vumlo brand apply                         # writes .vumlo/generated next to vumlo.toml
cd web && npm ci && cd ../desktop && npm ci
node scripts/build.mjs -- --bundles deb,appimage      # Linux; nsis on Windows, dmg on macOS

scripts/build.mjs builds the web app as a static export, makes the icons from the Vumlo logo, writes the configuration of the installer (desktop/gen/) and runs tauri build. The installers are in desktop/dist/, named <scheme>_<version>_<arch>.<ext>, for example vumlo-ucu_0.2.1_amd64.deb. It warns, before the long part, if the server address is http or localhost, or the scheme is plain vumlo. If your configuration is not beside desktop/, give the generated directory: node scripts/build.mjs --generated /path/to/.vumlo/generated.

Build it with GitHub Actions

Copy desktop/release/desktop-release.yml to .github/workflows/desktop-release.yml of the repository that has your vumlo.toml (a GitHub fork of vumlo-core, or a repository that vendors a release as vendor/vumlo-core), and set CORE_DIR and CONFIG at the top. Push a tag:

git tag desktop-v1.0.0 && git push origin desktop-v1.0.0

The workflow makes the branding once (or uses a committed .vumlo/generated), builds the installers on Linux, Windows and macOS (Apple silicon and Intel), and puts them with a SHA256SUMS in a draft release. Open it, try an installer, and publish. “Run workflow” builds them without a release.

Signing

Without secrets the installers are unsigned. They work; the system warns:

To sign, add these repository secrets; the workflow uses what is there and says in the release what it did.

System Secrets Result
Windows WINDOWS_CERTIFICATE (the .pfx, base64), WINDOWS_CERTIFICATE_PASSWORD The installer and the program are signed. A code-signing certificate from a certificate authority is paid.
macOS APPLE_CERTIFICATE (the Developer ID Application .p12, base64), APPLE_CERTIFICATE_PASSWORD, APPLE_SIGNING_IDENTITY Signed.
macOS, to notarize also APPLE_ID, APPLE_PASSWORD (an app-specific password), APPLE_TEAM_ID Notarized: opens without a question. Needs an Apple Developer account.

Give it to people

Publish the draft release. Then, in the web app as an administrator, open Admin, Institution, Desktop app and paste the address of each installer (https://...; any of the five can stay empty). From then on:

Save all the fields empty and the notice, the page and the menu entry are gone. The links are public, since the download page is.

Which file goes in which field: ...-setup.exe is Windows; ...-aarch64.dmg is a Mac with Apple silicon and ...-x64.dmg an Intel Mac; .deb is Ubuntu and Debian and .AppImage other Linux. Use the address of each file on the published release (right click it, “copy link address”), or wherever you host them, and keep SHA256SUMS. A new version is a new tag, desktop-v1.0.1, and new files: paste the new addresses, save, and people see them at once. They install over the old version and keep their data.

Files

The window can upload a file and open one (ADR-0069, ADR-0061). It has no access to the disk of its own; two commands of the app do the work, and the window asks for them by file id:

The desktop app needs a server of the release that has file storage; against an older server the file screens answer with an error.

Limits to know about

Version v0.4.1. This page on GitHub