How Does Edge-Drop Update on GitHub Builds?

An app that ships from two distribution channels — GitHub releases and the Microsoft Store — has two different update stories. GitHub builds of Edge-Drop auto-update themselves in place; Microsoft Store builds cannot, because the Store's update mechanism owns the lifecycle. This split confuses users who switch channels or who expect both builds to behave the same. This guide covers how GitHub auto-update works, why Store builds are different, what the user sees when an update lands, and how to switch channels. For neighbouring topics see how to install Edge-Drop on Windows 10 and 11 and how to uninstall Edge-Drop cleanly.

Two channels, two update models

Edge-Drop is distributed as:

• GitHub NSIS .exe installer — the canonical build, hosted on the project's GitHub Releases page. Auto-updates via electron-updater, which downloads a delta or full installer from GitHub and applies it on next restart.
• Microsoft Store MSIX package — listed in the Microsoft Store. Updates are delivered by the Store's own update infrastructure, on the Store's own schedule, and only after passing Store certification.

The two channels are not interchangeable from an update perspective. A GitHub build will never auto-update to a Store build, and a Store build cannot install a GitHub release over itself. Switching channels requires uninstalling one and installing the other. See how to uninstall Edge-Drop cleanly for the uninstall workflow.

How GitHub auto-update works

The mechanism is straightforward:

1. Edge-Drop ships with electron-updater, the standard Electron auto-updater library.
2. On a throttled cadence (typically every few hours, plus on startup), the app fetches a latest.yml file from the GitHub Releases asset URL.
3. The latest.yml contains the new version number, the download URL, and a checksum.
4. If the new version is greater than the running version, Edge-Drop downloads the new NSIS installer in the background.
5. Once downloaded, the user is prompted to "Restart to update" — typically via a small banner in the shelf or a tray notification.
6. On restart, the new installer is executed, the old version is replaced, and the new version starts.

The Store build cannot do this because:

• Store apps are installed as MSIX packages, not NSIS installers. The package identity is bound to the Store.
• Store apps run in an AppContainer sandbox. They cannot write to their own install directory.
• Store policy prohibits in-app updaters that bypass the Store. The Store must own updates.

This is not an Edge-Drop decision; it is a Microsoft Store policy. Every Store-listed desktop app faces the same constraint. The trade-off is documented in Microsoft Store listing: what to expect.

What the user sees

On a GitHub build, when an update is available:

• A small banner appears in the shelf, typically reading "Version X.Y.Z available — restart to update."
• The tray icon may show a badge.
• The user can click the banner to restart immediately, or ignore it and restart later.
• If the user ignores the banner, Edge-Drop continues running the current version. The downloaded update is staged but not applied until restart.

On a Store build, the user sees nothing in-app. The Store handles updates silently in the background, on its own schedule. The user can check for updates manually via the Microsoft Store app → Library → Get updates.

The asymmetry is the source of most "Edge-Drop is on an old version" reports from Store users. A GitHub user has the new version the day it ships; a Store user has it days or weeks later, depending on certification throughput. See GitHub installer vs Microsoft Store: which build for the choice.

How to check the current version

In Edge-Drop:

1. Open the settings panel.
2. Look at the bottom of the About / Help tab (the exact location may vary by version).
3. The version number is displayed, along with the channel (GitHub or Store).

Alternatively, the version is visible in the tray icon's right-click menu, typically at the top.

If the version is older than what is shown on the GitHub Releases page (https://github.com/Deepender25/Edge-Drop/releases) and the channel is GitHub, auto-update should fetch it within a few hours. If the channel is Store, the update arrives when the Store delivers it.

How to force an update check

On a GitHub build:

1. Open the settings panel.
2. Find the "Check for updates" button in the About / Help tab.
3. Click it. Edge-Drop fetches latest.yml immediately and prompts if a new version is available.

If the button is not present, the build may be very old; the safest path is to download the latest installer from GitHub and install it manually. The installer preserves user data.

On a Store build:

1. Open the Microsoft Store app.
2. Go to Library.
3. Click "Get updates."
4. The Store checks all installed apps and updates any with a newer version available.

How to switch channels

To switch from Store to GitHub:

1. Uninstall the Store version. See how to uninstall Edge-Drop cleanly.
2. Download the latest NSIS installer from the GitHub Releases page.
3. Run the installer.
4. Edge-Drop starts as a GitHub build and auto-updates from then on.

To switch from GitHub to Store:

1. Quit Edge-Drop (tray icon → Quit).
2. Uninstall via Settings → Apps → Installed apps → Edge-Drop → Uninstall.
3. Install from the Microsoft Store.
4. Edge-Drop starts as a Store build; updates come from the Store.

User data (history, pins, settings) is stored in %APPDATA%\Edge-Drop (or a similar location) and is generally preserved across channels. See where Edge-Drop stores data on disk for the exact layout.

What "restart to update" means

When Edge-Drop prompts "restart to update," it means:

• The new installer has been downloaded and staged.
• The current Edge-Drop process needs to exit so the installer can replace files.
• The user can choose to restart immediately (Edge-Drop quits, the installer runs, the new version launches) or defer.

If the user defers indefinitely, the staged installer sits on disk. Edge-Drop will prompt again on next launch. There is no forced restart — the user is always in control of when the actual update applies.

For users who run Edge-Drop at login and rarely restart their machine, the prompt may sit for days. A manual quit-and-relaunch applies the update.

Failure modes

A few patterns cause auto-update to misbehave:

• Corporate proxy blocking GitHub — latest.yml and the installer asset are fetched over HTTPS from github.com and github-releases.githubusercontent.com. If a corporate proxy blocks these, the update check fails silently. The user can manually download the installer from the Releases page.
• Antivirus quarantining the installer — some antivirus products flag newly-downloaded NSIS installers. Edge-Drop will report the download failed. Whitelisting the Edge-Drop install directory resolves it.
• Permission errors during apply — if Edge-Drop was installed for All Users, the installer needs elevation to replace files. The elevation prompt may appear at restart; if the user dismisses it, the update does not apply.
• Store certification delay — Store builds may lag the GitHub release by days or weeks. This is not a bug; it is the Store's pipeline.
• In-app updater disabled — some Edge-Drop builds may have a setting to disable auto-update. If disabled, the user must download and install new versions manually.
• Mixed-channel install — if both a GitHub and a Store build are somehow installed (unusual but possible), they will conflict. Uninstall both and reinstall one.

For diagnostic steps when an update is stuck, see how to uninstall Edge-Drop cleanly.

What Edge-Drop does not claim

• Auto-update is GitHub-only. Store builds do not auto-update via the app.
• Auto-update does not run on a precise schedule. The throttled check is best-effort.
• Auto-update does not provide a changelog in the prompt. The changelog is accessible via the in-app "What's new" view; see how to read Edge-Drop's in-app changelog.
• Auto-update does not downgrade. If the running version is newer than the latest GitHub release (e.g., a beta build), the updater does nothing.
• Store builds do not have feature parity with GitHub builds at all times. Store certification can cause delays or, occasionally, version skips. See Microsoft Store listing: what to expect.

Summary

GitHub builds of Edge-Drop auto-update via electron-updater, prompting the user to restart when a new version is staged. Store builds cannot auto-update; the Microsoft Store handles updates on its own schedule and the user checks via the Store app. The asymmetry is a Store policy, not an Edge-Drop decision. To switch channels, uninstall one and install the other; user data is generally preserved. For users who want updates as soon as they ship, the GitHub build is the right choice; for users who want Store-managed updates and certification, the Store build is the right choice.

Related reading

• How to Uninstall Edge-Drop Cleanly
• Where Edge-Drop Stores Data on Disk
• How to Install Edge-Drop on Windows 10 and 11
• What Local-First Software Means for Clipboard Apps

Sources

• electron-updater — GitHub README — official documentation for the auto-updater library Edge-Drop uses on GitHub builds
• Microsoft Learn — Microsoft Store policy for desktop apps — documents the Store policy that prohibits in-app updaters bypassing the Store
• Microsoft Learn — MSIX package identity — explains why MSIX packages cannot self-replace their install directory
• Edge-Drop — GitHub Releases page — the canonical source for GitHub build releases and changelogs
• Microsoft Support — Update apps and games from the Microsoft Store — official instructions for the Store-side update check that Store users rely on

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support