How Floodtide verifies an update

Floodtide keeps no database of versions of its own. For every app it asks the sources that already know, and the row names which one answered.

• The app's own update feed. A Sparkle feed whose address Floodtide reads from the app bundle itself. When the app declares one, that feed wins outright over every other source.
• Homebrew's cask catalogue. Read directly from Homebrew's own catalogue, so Homebrew does not need to be installed. An app that Homebrew installed stays Homebrew's to update, and Floodtide prefers the cask's answer for it.
• GitHub Releases and Electron feeds. For apps that publish neither an appcast nor a cask. Floodtide picks one unambiguous Mac build for this Mac's processor rather than guessing between several.
• The Mac App Store. Only for apps the store installed, read from what the store is offering this Mac. A store app is never offered a direct download, and an app from outside the store is never asked about in it.
• Floodtide's signed catalogue, and your own sources. A hand-researched feed that only ever names which source to read for an app, so the reading still goes through the sources above and nothing about verification is duplicated. A Sparkle address or GitHub repository you set yourself is checked before anything Floodtide discovers.

What is compared is the version and, where both sides publish one, the build number. A release is offered only when it is newer than the installed copy on that comparison. A release that is older, or that is the version you already have, is not shown as an update.

Two comparisons are refused at the scan rather than after a download: a jump that does not add up, such as 5.92 to 2584447, is held out of Update All and scheduled runs, and a release named a demo or trial build is never offered to a licensed copy.

Before a row gets an Update button at all, something has to vouch for the file it would download. The rule is asked twice, once by the scan and once by the download itself, so no row offers a button the download step would refuse. Three things count, and a row needs one of them.

• A checksum published by the source. The SHA-256 a Homebrew cask records for the file, or the SHA-512 an Electron feed publishes beside each download.
• A signature in the feed. A Sparkle feed can carry an EdDSA signature for each download, and the app carries the matching public key. Floodtide verifies the file against that key.
• The installed copy's own signature. When neither is published, the copy on your Mac has to be validly signed by a Developer ID team, and the replacement is then held to that same team once it is unpacked. An unsigned app with no checksum and no feed signature gets no Update button: the row shows the release and says Floodtide could not confirm the download is genuine.

• The connection. Shipping builds download over https only. A plain http address is asked for over https first and refused if the server will not serve the file that way. A link that answers with a web page rather than a file is refused too.
• The checksum. Where the source published one, the SHA-256 or SHA-512 of the bytes that arrived is compared with it. On a mismatch the row says the download did not arrive intact, and nothing is unpacked.
• The feed signature. Where the feed signed the download, the EdDSA signature is checked against the key in the installed app. On a mismatch the row says the download is not signed by the developer Floodtide expected.

The download is unpacked into a folder of its own, and the app inside is checked before anything on your Mac is touched. The row shows each step as it runs: Unpacking, Checking signature, Checking with Gatekeeper.

• It is the same app. The bundle identifier has to be the installed app's. A download that is a different app is refused and remembered, so the same file is not fetched again on the next scan. A developer's own rename is allowed only when both copies carry a Developer ID signature from the same team and the download is notarised, and even then Floodtide asks you before it lands.
• It is not older. The version and build inside the download are compared with the installed copy, and an older version or an older build is refused. A download that turns out to be the build already installed is recognised by its code signature being identical to the installed copy's, and the row says so instead of claiming an update.
• It runs on this Mac. The macOS version the new build needs is compared with the one you run. A build that needs a newer macOS is refused with that version named, and the refusal lifts by itself once you upgrade. The new build also has to carry code for this Mac's processor when the installed copy does, so an Intel-only build never replaces a native Apple silicon app.
• The code signature holds. Floodtide runs codesign's deep, strict verification over the new bundle, which hashes every file inside it. Finder metadata on the copy or an older signing format is forgiven; a modified file or a broken seal is not.
• The signing team matches. The team identifier in the new build's signature has to equal the installed app's. A validly signed app is only ever replaced by a validly signed app, never by an unsigned one or one that names no team. A different team is either a genuine change of developer or a hijacked feed, and Floodtide cannot tell which, so the update stops and asks you; your answer is kept for that one app. An unsigned installed app may only move to a validly signed build.
• Gatekeeper agrees. Every signed bundle is also assessed by Gatekeeper, which weighs notarisation, revocation and this Mac's security policy, with at least ten minutes allowed on slow Macs. On a Mac whose profile allows App Store apps only, Gatekeeper refuses every Developer ID build, and Floodtide says that this is the Mac's policy rather than a fault in the update.
• And again after the swap. The copy that lands is checked a second time against the copy it replaced. If that final check fails, the original is put back and the row says so. Only a route that runs this recheck may end on Done, verified.

Some apps ship as an installer package rather than an app bundle. A package runs its own scripts as an administrator, so it is held to its own bar: Gatekeeper assesses it as an installer, and when no checksum vouched for the download, the Developer ID Installer certificate it is signed with has to name the installed app's team. Floodtide records the package's SHA-256 before that assessment and checks it again immediately before the package is handed to the installer, so what runs is the file that was assessed.

A vendor's own installer app that arrived with no checksum has to clear three things in one requirement: a Developer ID signature, Apple's notarisation, and the installed copy's team.

The update is refused, nothing on your Mac has changed, and the row says in one sentence what was found and what to do next. A checksum mismatch reads "The download did not arrive intact". A failed signature or Gatekeeper check reads "The update does not meet Floodtide's code signature or notarization requirements", with the step to download that update from the developer instead.

A refusal that is about the file itself, a different app inside, a failed signature, nothing installable, a format Floodtide cannot open, is remembered against that release, so the row keeps saying what was found rather than spending a download to find it out again on every scan. A refusal that is about this Mac, a macOS floor or an App Store only profile, is remembered with what it was established against, and lifts by itself when the Mac changes.

Every step of an install has a time limit sized to the app. A check that overruns ends the update saying which step it was, with the app untouched, and a check that was cut short counts as a check that did not pass, never as one that did.

With backups on, which is the default, Floodtide copies the installed app before it replaces it: a clone where the disk supports one, otherwise a zip archive, into a Floodtide Backups folder you can move to another disk. If that copy cannot be made, the update does not go ahead.

Undo Last Update puts the newest copy back in one click while the app is not running, and the restored copy goes through Gatekeeper again before it lands. The copy is kept for three days, a week, two weeks or a month, a week by default; the Undo button counts the days left, and Delete Backups in Settings removes them all.

Separately from backups, the swap itself keeps the original aside until the new copy has landed and passed its final check. A failed install puts the original back even with backups switched off.

Earlier versions, in an app's details, lists the older releases its source still publishes. Choosing one installs it through the same signature, team and Gatekeeper checks as an update; only the rule that a download must be newer stands down, which is the point of going back. Going back is not offered for an app that needs administrator rights to replace.

Beyond a failed check, there are rules that keep an update waiting without refusing it.

• The app is open. Floodtide never closes an app for you. A scheduled run leaves an open app alone and installs its update when you quit the app. Quit and Update, which you press yourself, asks the app to quit politely; if it refuses, the button's menu offers Force Quit and Update, which closes that one app only after you confirm.
• The last automatic attempt failed. With automatic updates on, an app whose last automatic attempt failed is left at that version for about 17 hours before a scheduled run tries it again, so an hourly check does not download the same failing file every hour. Your own Update, Update All or Check for Updates still tries it straight away.
• The Mac is not ready. A scheduled run does not start during your quiet hours, on a low battery, in Low Power Mode or on a limited connection, and tries again once that has passed.
• A scheduled run is stricter. It leaves Floodtide itself, any app that would need your administrator password, any major version when Update All is told to leave those out, any app that needs the vendor's own installer, any release an earlier run already proved cannot be installed, and any app you switched off. It never answers a question, such as a changed signing team, on your behalf.

• Install without your say-so. Automatic installing is off until you switch it on, and Floodtide's own updates have a separate switch. A check on a schedule only looks. The macOS page lists the system updates Software Update is offering and opens Software Update; Floodtide never installs macOS itself.
• Shorten a check. An automatic run and Update All run the same checks as a single Update, nothing shortened.
• See your password. An app in a folder macOS protects needs the same administrator prompt any installer shows, once for the whole batch and announced before it appears. macOS handles the password; Floodtide never sees or stores it, and a scheduled run never asks for it.
• Send your app list anywhere you did not allow. Which apps and versions this Mac runs is shared once a day with no identifier, so that every Mac helps every other; the app tells you so on first launch, and Settings, Privacy shows the exact payload and turns it off. The anonymous usage line is off until you switch it on. Nothing else about you leaves the Mac. The privacy policy has the request-by-request list.
• Ask for permissions it cannot explain. No Full Disk Access, no Accessibility control, no screen recording. Floodtide reads app version information from your Applications folder like any file browser.