Fluent Store puts the Microsoft Store, WinGet and Chocolatey in one window

One search box over several package sources

Fluent Store describes itself as a unifying frontend for Windows app stores and package managers, and the workflow it targets is specific: you search all repositories at once, pick out an app, and install it without ever opening a browser or command prompt.

The value of that framing is that Windows package management is genuinely fragmented. The Microsoft Store, the WinGet command line tool, and Chocolatey each have their own interface, their own catalogue and their own idea of what an app is. A front end over them is not a new package manager, it is a search and install surface across the ones that already exist, which is why the project can be useful while remaining a thin layer.

The listed features follow the same logic. There is a graphical interface for WinGet, so the command line tool is usable without a terminal. You can download Microsoft Store apps without installing them, which is a different operation from installing and useful when you want to inspect or carry an installer. And the app can find Microsoft Store listings for installed apps, including some system apps, which means it can act as a catalogue of what is already on the machine rather than only what could be added to it.

On top of that sits a social layer. With a Fluent Store Social account you can create collections of apps to install or share in one click, so a curated set of applications travels as a single unit.

The source table is the honest part of the documentation

The project publishes a matrix of package sources against four capabilities: search, download, install, and collections. A source that implements at least one of the three features in the table can be added to collections.

Microsoft Store and WinGet are the complete entries, with search, download, install and collections all available in the latest release. Chocolatey has search, download and install, but no collections, and it carries a tracking issue reference, number 30. GitHub Releases has no search, with download and install available, and no collections. UWP Community and Fluent Store itself support collections but not search.

The two entries with nothing at all are Scoop and WebCatalog, both marked as not available at this time, with tracking issues 40 and 85 behind them. That gap matters for anyone whose workflow is Scoop based, since a Scoop user is the person most likely to want a graphical front end. The same applies to WebCatalog, which is the format for packaged web applications.

Two footnotes add the nuance the table cannot. UWP Community projects have download links but they do not go directly to an installer, so Fluent Store will attempt to follow the link and download and install it if the pattern is recognized, and otherwise the link is opened in the default browser. And Fluent Store Social only supports collections, meaning lists of apps drawn from other sources: it does not host any packages itself, and a collection installs only if the appropriate package source is enabled on the machine.

Getting the app, and what it asks of your Windows install

There is no package manager recipe in the documentation. The download routes are two: the GitHub Releases page for the project, and an IPFS gateway serving the beta installer, a file named FluentStoreBeta.appinstaller. There is also a FluentStoreBeta.appinstaller at the top level of the repository, and an Installer directory alongside it, plus a PublishTool directory that suggests the publishing pipeline is scripted rather than manual.

The system requirements are the more useful part. Fluent Store requires Windows 10 version 1809, build 17763, or any version of Windows 11. The documentation also states that stripped down or de-bloated Windows installs are not supported, which is a useful warning because those trimmed images are popular with people who want a small, clean system, and they typically remove the components a Store app depends on.

The release history explains the shape of the project. The tags are v0.4.0 Beta from 2025-03-10, v0.3.3 Beta from 2023-07-25 and v0.3.2 Beta from 2022-07-27. So this is a beta that has been in beta for four years, with a long gap between the 2022 and 2023 tags and a steadier pace since. The last push was on 2026-10-11, so the code is being worked on even though the release tag is from 2025.

A blank Home page usually means the plugin setup failed

The documentation includes a troubleshooting entry for a specific first-run failure. A newly installed Fluent Store can show a blank Home page, and the explanation given is that the plugins are not available, possibly because of a program or internet error during first-time setup. The remedy is to re-attempt the setup through the path Settings, then Plugins, then Default Plugins, then Reinstall.

The important detail is that this is a setup step, not a rendering bug. The Home page depends on the plugin layer, so if the initial plugin download failed, the page has nothing to show. Reinstalling the default plugins is the documented way to recover, and the fact that the answer lives under Settings rather than in a console means the recovery path assumes a working UI.

This is also the clearest statement of the architecture from a user's point of view. Fluent Store treats its package sources as plugins, which is what allows a source that supports only download and install to appear in the same table as one that supports everything, and what allows new sources to be planned without changing the core application.

The source tree shows a WinUI app with a plugin SDK

The repository layout is the most detailed evidence of how the project is built. There is a FluentStore.sln solution and a FluentStore-AppOnly.slnf solution filter, which is the arrangement for building the shell without the extra projects, and the projects inside the solution are named after layers: FluentStore.App for the application itself, FluentStore.ViewModels for the view models, FluentStore.Services for the service layer, and an API directory.

Two of those names carry most of the architectural weight. FluentStore.SDK is the plugin SDK, and FluentStore.SDK.AbstractUI sits beside it, which suggests that a plugin can present its own interface but that some part of that presentation is abstracted away from the core. OwlCore.WinUI is a separate project, indicating that a WinUI component library is pulled in rather than written here, and Sources and Tests directories cover the source for the sources and the test projects.

The language is C#, and the repository topics point at the platform and the presentation stack: microsoft-store, uwp, windows, windows-10 and xaml, with the primary language listed as C#. The MPL-2.0 licence sits in a LICENSE file at the top of the repository.

For an adopter, the practical question is how much of this you can rely on. The plugin SDK is the extension point, and a project that has been in beta for four years with a modest release cadence gives you a stable-enough interface to build against, but not one with the release discipline of a shipped product.

What Fluent Store is not, and when a shell script wins

It is worth naming the alternative honestly. WinGet on its own handles search and install for a large part of what this app front ends, and it is the tool Microsoft ships and maintains, with a command line interface that scripts can use. A team that already drives WinGet from a script or a configuration management tool gets the same result without a graphical layer and without a beta application in the path.

The difference in approach is that Fluent Store is a desktop client that also handles the cases a package manager command does not cover as neatly. The Microsoft Store catalogue, apps that are installed but have no entry in any package manager, UWP Community packages whose download links do not point at an installer, and a shared collections workflow are all things the WinGet command line does not present. The IPFS download route and the appinstaller packaging are also hints at a distribution model built around the Store ecosystem itself rather than around the tool.

The trade is straightforward. If your Windows work is running one package manager from a terminal, WinGet is the simpler answer. If your work spans the Store, WinGet and Chocolatey, and you want one searchable window with a shared collection concept on top, that is the case Fluent Store makes, and the table of source support tells you exactly how far it goes today.

Editorial conclusion

Adopt Fluent Store if you are on Windows 10 build 17763 or Windows 11 and want one searchable window over the Microsoft Store, WinGet and Chocolatey instead of jumping between a browser, the Store app and a shell. Do not adopt it if you need Scoop, WebCatalog or GitHub Releases search, since those cells in the source table are marked as unavailable or in development, or if you are on a stripped down Windows install, which the documentation says is not supported. Before you install it, check two things: that your Windows version is 1809 or newer and that your install is not de-bloated, and that the plugins finish setting up on first run, since a blank Home page is the documented symptom of that step failing.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. README
4. Releases
5. yoshiask/FluentStore on GitHub