THE SHORTEST RELIABLE PATH
Follow the state in order.
Lemvia reads the appcast
The app checks https://lemvia.app/updates/appcast.xml for a newer build number.
The user reviews the update
Lemvia presents the available version and asks the user to confirm installation.
Sparkle verifies the archive
The downloaded update must match the embedded EdDSA public key and the signature in the appcast.
macOS verifies the installed app
Developer ID code signing and Apple notarization remain part of the platform trust chain.
Why two signature layers are useful
HTTPS protects transport from the website, while the EdDSA signature lets the installed app verify that the archive was signed with Lemvia’s update key. Apple code signing identifies the Developer ID publisher, and notarization records that Apple accepted the submitted release for distribution.
These controls solve different failure modes. A working HTTPS connection alone does not prove an archive belongs to the expected update key, and an update signature does not replace macOS platform verification of the installed application.
What build 1 users must do
Lemvia 1.0 build 1 was released before the updater was included. Because that build cannot discover build 2, it cannot bootstrap itself through Sparkle. Install build 2 once from the signed DMG on the official download page.
After build 2 is installed in Applications, future releases can be discovered from the app menu or menu-bar menu. Release notes, build numbers, signing status, and the public checksum remain visible in the changelog.
Direct answers
Can build 1 update itself?
No. Download and install build 2 manually once. Build 2 and later contain the Sparkle update channel.
What happens if a signature is wrong?
The update must not be installed. Sparkle compares the archive with the EdDSA signature and public key before extraction and installation.
Where are release changes published?
The official changelog and RSS feed are generated from the same verified release data at lemvia.app/releases.
PRIMARY SOURCES