UpdateHub: a Windows front end for the updates the system does not surface

One list for the software Windows itself will not tell you about

UpdateHub is described as a user-friendly application for streamlining the software update process. The value proposition in the project description is that you can quickly check for updates for all the software installed on your device, including operating systems and applications, and that the interface displays all available updates and lets you choose which ones to install.

That last clause is the distinguishing one. Most update mechanisms on Windows are per-vendor. Each application has its own updater, the Microsoft Store has its own, and the operating system has Windows Update, and none of them talk to each other. A machine with a dozen applications from a dozen vendors has a dozen places to remember to check. UpdateHub's proposition is to collect them into a single list.

The scope is broader than applications. The README states that UpdateHub does not just update apps, it can also update apps from the Microsoft Store and the whole operating system. It also mentions keeping the OS and some drivers up to date, so a driver update can appear in the same list as an application update.

The audience is an ordinary Windows user, not a system administrator. The framing throughout is in terms of convenience, of a hassle-free update experience, and of a straightforward interface where you select what to install. The topic tags on the repository name the same ground, with software-updater, update-checker and updatehub among them, along with electron and windows.

The stated motivation is security rather than convenience, though. The README argues that outdated applications bring unwanted security threats and uses the Chrome zero-day of 21 April 2023 as the worked example, with the CVE reference, the type confusion in V8 description, the note that an exploit was known to exist in the wild, and the point that Google Chrome may not tell you about it directly. The pitch is that the app will.

Rollback to the previous version is the feature that distinguishes it

Beyond the update list, the project highlights two supporting capabilities.

The first is a rollback function, described as letting you quickly revert to the previous version if you do not like an update or updated by accident. On Windows, that is not a trivial thing to offer, because the package managers behind the scenes vary in whether they keep the previous payload at all, and because a driver or an operating system rollback has its own recovery semantics. The claim is made plainly in the README, and the README is the only documentation in the repository, so it is worth treating the behaviour as something to verify on your own machine rather than as an established fact.

The second is information. The app provides detailed information about each update, including release notes and version numbers, so the decision to install is an informed one rather than a bulk accept. That is a small design decision with a real effect on trust, because a list of twenty opaque entries is a list nobody wants to read, and a list of twenty entries with changelogs is a list you can triage.

The project also describes a roadmap item that matters for anyone who develops on the machine. In later updates it says, the app will be able to keep your code dependencies up to date if you are a programmer, and will allow you to keep custom files up to date with a specified source. That is a different feature class from updating installed applications, closer to a dependency manager, and it is described as future work rather than something present.

So the current product is an update discovery and installation surface with a safety net. The dependency and custom file features are stated intentions.

The published comparison against IObit is the only quantitative claim

The README asks what makes UpdateHub different and answers with a comparison table against IObit, a commercial update tool. The table shows UpdateHub detecting 23 updates where IObit detected 4, with a screenshot of each result side by side.

Two things are worth saying about that comparison. First, it is a single run on a single machine, and the README does not describe the machine, the installed software or the date of the comparison, so the numbers are illustrative rather than a benchmark you can rely on. Second, the direction of the difference is plausible from the mechanism: an application that queries the Microsoft Store and the operating system as well as per-application sources has more places to look than a tool that checks conventional installer registries.

The store integration is the piece that explains the gap, and it is also the piece with the most platform-specific weight. The Microsoft Store is the distribution point for a large category of consumer Windows software, and those applications are not registered in the usual per-vendor updater paths.

The system requirements section lists the dependencies that make this possible. Windows 10 1809 build 17763 64-bit or later, 250 MB of available disk space, and, as the README puts it, things you probably already have but in case you do not, WinGet version 1.4.11071 or later and PowerShell 5.1 or later. WinGet in particular is the mechanism that lets one tool query many package sources, and requiring a specific WinGet version tells you the app depends on a recent package manager rather than on its own discovery logic alone.

The safety story rests on official sources and Defender, not on an audit

The README has a section asking whether it is safe, and the answer is that all apps and software downloaded via the app come from trusted official sources, that Windows Defender also scans them, and that it verifies the security hash for every app downloaded to prevent unauthorised changes.

That is a reasonable design for a Windows update tool. Hash verification is the meaningful part, because a downloader that fetches from official sources can still be tampered with in transit or on disk, and checking the published hash closes that gap. Pairing it with Defender scanning means the payload is both authenticated and inspected before it runs.

But it is worth being precise about what that claim covers and what it does not. The hash check is against the hash the official source publishes. If the official source itself is compromised, the hash check confirms the download matches a compromised artefact. The claim is about integrity of the download, not about the trustworthiness of the upstream publisher.

The other part of the safety story is what the app does with the machine it runs on. Updating an operating system or a driver by hand is a privileged operation, and the repository does not describe the permission model, the elevation flow or what happens when an update fails midway. The README does not describe a rollback of the operating system specifically, only a rollback function in general.

The repository does contain a Privacy Policy.md alongside the README, the licence and an acknowledgements file, and the README states that the app is completely free with an optional donation link. There is no telemetry description in the README itself, so the privacy policy file is the place to look for what the app sends anywhere.

Where to get it and what the first run looks like

There is no installer wizard and no package manager entry, so getting UpdateHub is a direct download from the GitHub releases page. The README links straight to the latest release with the file name in the link target.

https://github.com/NexovaDev/UpdateHub/releases/latest#:~:text=3-,UpdateHub%2Dx64.exe

What you get is a single 64-bit Windows executable, and the system requirements tell you the machine has to be able to run it: Windows 10 1809 build 17763 or later with 250 MB of free disk space, plus WinGet 1.4.11071 or later and PowerShell 5.1 or later.

The first thing the app needs is a scan of what is installed, which is what produces the update list. That is the point where the WinGet and PowerShell requirements start to matter, because a machine that has never run the package manager may have no source list for the app to query until one is set up. The README does not describe that first-run sequence, so the practical expectation is that the first launch may need the Windows package manager present and initialised before the list is complete.

The interface then shows the available updates with their release notes and version numbers, and you select which ones to install. The rollback function is available for reverting an update you did not want, either because it caused a problem or because you applied it by accident.

Windows only, and the promise of other platforms is only a plan

The README has a section headed for macOS and Linux support and the answer is direct: currently it does not support macOS and Linux, and a plan to support it is coming in later updates.

That is the whole of the cross-platform story, and it is worth noticing what a Windows-only design implies about the implementation. The app is an Electron application, which means the user interface is web technology, but the update logic underneath has to reach into Windows specific mechanisms: the package manager sources, the Microsoft Store, the operating system servicing stack and the driver store. The Electron shell is portable; the discovery and installation layer is not.

For a project built on Electron, the download is a single Windows executable, and the README links directly to the latest release with the file name UpdateHub-x64.exe. There is no installer wizard, no package manager entry, no Linux build, and no mention of an ARM64 build, so the 64-bit x86 requirement in the system requirements is a real constraint rather than a formality.

The build and release picture is thin. The repository contains a .github directory, the acknowledgements file, the licence, the privacy policy, the README and an images directory, and the primary language is not recorded. The releases on GitHub are v2.4.1 from 2024-11-11, v2.4.0 from 2024-02-27 and v2.3.4 from 2023-12-27, while the last push to the repository was on 2026-06-07. A repository with no source, no build files and no issue discussion in the tree is a distribution point for a binary, not an open development project.

Where UpdateHub is the wrong tool

The first wrong-tool case is anything that is not Windows. There is no macOS or Linux build, and the README is clear that the plan for those platforms is future work. On a Mac, an update checker for the Mac's own software is a different problem with different package managers.

The second case is a machine you cannot easily recover. The rollback function is a good safety net, but on a locked-down or production workstation, an app that installs operating system and driver updates on your behalf, with an undocumented elevation model, is a risk you would want to scope carefully before allowing it.

The third case is a team that needs to review the code. This is the substantive objection. The repository publishes no source. The top level contains a README, a licence, an acknowledgements file, a privacy policy and images, and the primary language is not even recorded, so you cannot check what the app does with your machine, which update sources it queries, or what it does with the data it collects. The description mentions that in later updates it will keep code dependencies up to date and custom files in sync with a specified source, and an updater with that capability is exactly the kind of tool where reading the source matters.

The licence is recorded as a custom notice that GitHub cannot classify, with the LICENSE file in the repository as the authority, which means the terms need reading rather than recognising.

There is a version question too. The newest tagged release is from November 2024, and the last repository push is from June 2026, so the binary you download from the releases page is not necessarily the newest code the author has worked on. If the point of the tool is that it knows about current vulnerabilities, the freshness of the updater itself is a reasonable thing to check before you trust it with the machine.

Editorial conclusion

UpdateHub suits a Windows user whose machine has accumulated software the built-in updater never mentions, and who wants one list rather than several vendor tools, since the comparison the project publishes is against a commercial alternative that finds a fraction of the same updates. It does not suit macOS or Linux, and it does not suit anyone who needs to audit what the app does, because the repository holds only the README, the licence, an acknowledgements file, a privacy policy and images, with no source code published. Before installing, download the x64 executable from the releases page, read the privacy policy in the repository, and confirm that the rollback feature behaves as you expect on a machine where you cannot reinstall quickly.

Frequently asked questions

Official sources

1. Issues
2. NexovaDev/UpdateHub on GitHub
3. README
4. Releases