Example Apps

These are runnable reference applications that wire real desktop update flows to a faynoSync instance. Each one targets a different updater. The Electron, Squirrel, and Tauri apps show how the JavaScript SDK fits in — from a simple edge-first update check to full native-feed resolution. The Velopack app is the exception: faynoSync speaks Velopack's native feed protocol, so its stock client needs no SDK.

Every example is a complete, buildable app on GitHub. The snippets in these docs are trimmed to the update logic only (SDK calls, feed wiring, edge handling); the repositories contain the full UI, packaging, and CI.

Which example maps to what

Example	Framework / updater library	faynoSync updater type	How the SDK is used
Electron	Electron + electron-updater (generic provider)	electron-builder (*.yml)	SDK checkForUpdates as an edge-first gate, then the feed directory is derived from packageUrls and handed to electron-updater.
Squirrel	Electron native autoUpdater (Squirrel.Mac / Squirrel.Windows)	squirrel_darwin / squirrel_windows	SDK resolveNativeFeed resolves the feed edge-first (API fallback), then setFeedURL.
Tauri	Tauri + @tauri-apps/plugin-updater	tauri	SDK checkForUpdates as an edge-first gate; the native plugin does the signature-verified install.
Velopack	Velopack (Python, stock client)	velopack	No SDK — the stock Velopack UpdateManager reads faynoSync's native feed directly.

Why the SDK sits in front of the native updater

This applies to the Electron, Squirrel, and Tauri examples. (Velopack is different — see its own page — because faynoSync serves it a native feed straight from the CDN, so there is no SDK in front.)

Native updaters (electron-updater, Squirrel, tauri-plugin-updater) are good at downloading and installing, but they poll the API on every check and don't know about faynoSync's edge (CDN) responses. In those three examples the SDK runs first:

• On the common no-update path, the SDK's edge-first checkForUpdates (or resolveNativeFeed) answers from the CDN and sends the optimized /telemetry/beacon, so the API and the native updater are never invoked.
• Only when an update actually exists does the native updater start, using a feed URL the SDK resolved — pointing at the edge when it's warm, falling back to the API (which warms the edge) on a miss.

Some of the per-example code looks unusual out of context (deriving a feed directory from a package URL, treating 200 { "status": "no_content" } as "no update", stripping /RELEASES). Those are edge-delivery details the SDK normalizes — each page explains them where they appear.

Prerequisites

The three SDK apps read the same configuration (owner, app name, channel, BASE_URL, EDGE_URL, and an optional report key) from a .env file; see each repo's .env.example. The Velopack app is a Python project configured through environment variables instead (feed base, API base, TUF_ENABLED, ASK_API, and so on) — see its repo. All of them expect an app configured on your faynoSync instance with the matching channel/platform/arch and the relevant updater enabled on the platform.

Related reading

• JavaScript SDK — checkForUpdates, resolveNativeFeed, reportEvent, and edge fallback behavior.
• Updaters Support — how each updater type shapes the server response.
• Edge delivery — how faynoSync publishes cached JSON/feeds for CDN delivery.