Most download pages are a lie waiting to happen: someone ships a new build, forgets to bump the version string on the marketing site, and now the "Download" button hands out a stale installer while the changelog above it talks about a feature that isn't in the file yet. Influxx 1.2 closes that gap on the macOS download page by making the version number, the DMG link, and the "Latest" badge all resolve live from the same update feed the desktop app itself checks for updates — there's no separate string for a human to remember to edit.
One Feed, Every Surface
The logic lives in website/src/lib/download.ts. resolveLatestDesktopRelease() fetches a channel manifest — latest-mac.yml, the electron-builder auto-update manifest — preferring the stable channel and falling back to rc if stable isn't published yet. parseLatestMacYml() does a minimal regex-based parse of that file (the code comment explains this is deliberate: the website package doesn't want a YAML dependency for a fixed, simple manifest shape) and pulls out a semver version and optional releaseDate. That version then flows into formatDesktopVersionLabel(), which does almost nothing on purpose — it strips a leading v and returns the rest untouched. A comment in the source is explicit about why: an earlier version of this code collapsed something like 1.4.138-rc.10 down to 1.4.138 RC, which hid which release candidate was actually live. The fix was to stop being clever with the string.
The fetch itself is defensive by construction. fetchChannelManifest() requests with cache: 'no-store' specifically so the site doesn't serve a marketing CDN's stale cached copy after a fresh publish, and it wraps the whole thing in a try/catch that returns null on any network or parse failure rather than throwing. If both the stable and RC manifests fail to resolve, resolveLatestDesktopRelease() falls through to fallbackLatestDesktopRelease(), which returns a hardcoded last-known-good version and DMG URL. That fallback exists for exactly one reason: a marketing page should degrade to "slightly stale" under a network hiccup, never to a broken download link.
Where "Influxx 1.2" Fits
This wave of changes — what the team is calling Influxx 1.2 internally — is really a collection of independent fixes that share one theme: the parts of the product a user can see should never silently drift from the parts a user can't. The live download feed is the clearest instance of that theme, because a wrong version string on a download page is a failure mode almost every company with a native app has shipped at least once.
"The old failure mode wasn't exotic — it's the most boring bug category there is. Someone ships v14, forgets the marketing site says v11, and a support ticket comes in three days later asking why a feature they read about isn't in the build they downloaded. You don't fix that with a reminder in a runbook. You fix it by deleting the place where a human was supposed to remember something."
— Marcus Field, Staff Engineer, Web Platform at ETAPX
Keeping Every CTA in Sync Without Hammering the Feed
DownloadPageContent.tsx, the component behind /download, doesn't call resolveLatestDesktopRelease() directly — it reads from useLiveDesktopRelease(), a shared subscription hook. That hook keeps one module-level cache and one polling interval regardless of how many components on the page are asking for the release, with a listener set that components subscribe and unsubscribe from as they mount and unmount. The poll interval is DESKTOP_RELEASE_POLL_MS, set to 15 seconds, and the hook also listens for the page's visibilitychange event to force an immediate refetch when a tab that was backgrounded becomes visible again — so a page left open in a background tab still catches up right away instead of waiting out the rest of its poll window.
The practical effect: the hero download button, the mid-page CTA, the footer, and the version accordion on /download all read from the same in-memory value, so they can never show four different version numbers at once even though four different components independently subscribed to the release feed. The hook also exposes a live boolean — true only after a real network resolve has succeeded, not just when a cached fallback is in memory — and the download page uses that to show "Resolving latest release…" rather than asserting a version number it hasn't actually confirmed yet.
Only What's Actually Published
latestReleaseToDownloadRelease() in download.ts builds the download matrix shown on the page, and it only ever lists a Mac ARM64 row — the code comment notes this is deliberate, because listing placeholder x64 or universal rows for architectures that aren't published yet would be its own small version of the same lie: a button on the page that looks downloadable but isn't backed by a real file.
"I've been burned by download pages before — click the button, install it, and the About screen shows a build number that doesn't match what the release notes on the same site were describing. I checked the Influxx download page against the in-app updater out of habit and they matched exactly, including the RC suffix. Small thing, but it's the kind of small thing that tells you the team actually looked at this page after they built it."
— Renata Silva, DevOps lead at a mid-size SaaS company, Influxx user
The Other Kind of Reliability: Not Crashing on Bad Shape
A second, smaller fix landed in the same wave, on the adjacent /release-notes page. That page pulls its entries from a backend content feed rather than a static array, and during prerendering it turned out one of the JSON fields on a release note — the sections array each entry uses to render its body — could come back in a shape that wasn't actually an array. The rendering code was calling .map() directly on that field, which is exactly the kind of assumption that works until the one day it doesn't, and when it doesn't, it doesn't fail quietly — it throws, and a page that throws during static generation fails to build at all.
The fix wasn't a patch over the symptom. A new normalization step validates and coerces each incoming row before it ever reaches a render path: fields expected to be arrays — sections, each section's body and bullets, the entry's links, an improvements block's items — are checked with Array.isArray() and defaulted to an empty array if the check fails, instead of assumed. The rendering component itself was also hardened as a second layer of defense, so even a row that somehow skipped normalization can't crash the page it's rendered on. If the feed comes back entirely malformed, the page falls back to a small set of known-good static entries rather than rendering nothing or crashing outright.
This wasn't a security issue and nothing about it involved user data or credentials — it was a data-shape mismatch between what the frontend assumed and what the backend could actually return, the kind of gap that shows up in almost any app that renders structured content from a remote source. The fix is a reminder that defensive rendering isn't paranoia; it's the difference between a malformed row degrading gracefully and a malformed row taking down an entire page's build.
"Both of these fixes are unglamorous in the same way. Nobody is going to open a changelog and get excited that a download button now points at the correct file, or that a page doesn't crash when a field comes back oddly shaped. But those are exactly the bugs that erode trust fastest when they happen and are cheapest to prevent when you actually go look for them."
— Ingrid Halvorsen, VP of Engineering at ETAPX
What Changes for a Visitor
Practically, none of this requires anyone to do anything differently. Load /download, and the version label, the Latest badge, the RC-or-stable pill, and the DMG link are all resolved at page-load time and kept fresh every 15 seconds after that — a person who leaves the tab open through a release doesn't need to refresh to get the new build. The accordion on the page defaults to whichever version is currently latest, and if a fresh publish lands while someone has an older entry pinned open, the page only snaps the open state back to latest when the visitor hadn't already navigated elsewhere in the list — respecting that a person actively looking at an older entry probably wants to keep looking at it.
Frequently Asked Questions
Does the download page ever show a version that doesn't match the actual installer?
Not under normal operation — the version label and the DMG link are derived from the same resolved release object, so they can't independently drift. If the live feed is unreachable, the page shows a fallback version paired with a fallback DMG URL for the same build, rather than mixing a live version number with a stale link.
How often does the download page check for a new release?
Every 15 seconds while the tab is open and visible, plus an immediate refetch whenever a backgrounded tab becomes visible again, so it doesn't wait out the rest of its interval before catching up.
Will the page show Windows or Linux builds?
No, not currently. The download matrix only lists architectures that are actually published — right now that's Mac Apple Silicon — rather than showing placeholder rows for platforms without a real installer behind them.
What happens if the update feed is completely unreachable?
The page falls back to a hardcoded last-known-good version and DMG URL rather than showing a broken link or an empty state, and it displays "Resolving latest release…" instead of asserting a version it can't confirm.
Was the release-notes crash a security vulnerability?
No. It was a data-shape bug — a JSON field expected to be an array wasn't always one, which crashed a render call. No user data, authentication, or access control was involved.
Does opening the download page in multiple tabs cause redundant network requests?
No. The polling subscription is shared at the module level across every component and mount on the page, so multiple CTAs reading the release don't each open their own polling loop.
If I already have Influxx installed, should I use this page to update?
The page itself suggests otherwise — it points existing installs to the in-app Check for Updates flow, which pulls from the same feed and applies the update without a fresh download from the browser.
A download button is a small piece of UI carrying an implicit promise — that what you get when you click it is what the page just told you it was — and the least exciting kind of engineering work is often the kind spent making sure that promise actually holds.
