# SwiftList: NTFS MFT and USN Journal Search for Windows

> SwiftList is a C# WPF launcher that indexes NTFS volumes through the USN Journal and MFT instead of walking directories. It is aimed at Windows users who want Everything-style instant search with a plugin SDK, and it only makes sense on NTFS.

**SwiftList/SwiftList** — A modern, high-performance local file search and productivity tool for Windows. A sleek, customizable alternative to Everything and Listary built with C# WPF and NT Services, featuring instant NTFS MFT parsing, real-time USN monitoring, and plugin support.

- Repository: https://github.com/SwiftList/SwiftList
- Website: https://swiftlist.github.io
- Stars: 460 · Forks: 20
- Language: C#
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/swiftlist-swiftlist

## What SwiftList solves, and who it is actually for

Windows search is slow because it walks directory trees. SwiftList takes the other route: the README states it reads the NTFS USN Journal and MFT directly, so the index is built from filesystem metadata the volume already maintains. The project positions itself as "a modern, open-source alternative to Everything and Listary", which tells you the target audience precisely: people who already know that filename search on Windows can be instant and want an open source implementation with an extension surface.

The second audience is developers. The repository ships a PluginSdk/ directory and a Plugins/ directory, and the README lists what a plugin can extend: search providers, aliases, context-menu actions, result columns, previews and themes. That is a wider surface than most launchers expose. If you only want to type a filename and press Enter, the SDK is irrelevant to you, but it explains why the codebase is split into App/, Core/, Service/, Cli/ and PluginSdk/ rather than being one executable.

## How the USN Journal and MFT indexing pipeline works

The architecture is a two-process split. A service runs at SYSTEM level and owns the index; the WPF application runs per user and owns the UI. The README calls this "process isolation" and frames it as a deliberate boundary between the indexing service and the per-user app UI. The practical consequence is that the index survives the app being closed, and that the app does not need elevated rights for every search.

Index population has two phases. The initial phase reads the MFT, which is why the README describes indexing as millisecond-scale rather than proportional to directory count. The steady-state phase consumes USN Journal records, which the NTFS driver writes whenever the volume changes, so the index follows the filesystem instead of polling it. The README describes the result as "a low-footprint background service keeps the index in sync in real time".

Search itself is fuzzy matching, described as FZF-style, with prefix, suffix, exact and exclude operators, plus pinyin aliasing for Chinese filenames. The README names three entry points: a quick popup, a full main window, and an inline bar that docks into File Explorer or native file dialogs. The docked bar is the part that overlaps with what Listary does, and it is the reason the comparison in the README is not just marketing positioning.

## Installing SwiftList and running a first search

The README points at the project homepage and at direct release assets. For x64 there is an installer and a portable zip; for ARM64 there is a separate installer and a separate portable zip. The README marks the installer as "recommended, supports the background service", which is the one line that matters most: if you take the portable route, you are choosing not to have the service installed the same way.

If you build from source instead, the README lists the prerequisites: Windows 10/11, the .NET 10 SDK, Visual Studio 2022 or JetBrains Rider, and Inno Setup if you want to produce the installer. Two batch files are documented.

```bash
build_and_run.bat
```

That script, per the README, rebuilds App/Core/Service/plugins and relaunches everything locally. It is the development loop, not a distribution step. For release artifacts the README gives a second script, which produces both architectures:

```bash
make.bat
```

The output lands in dist/ as Release builds for x64 and ARM64. There is also install-dotnet-runtime.bat at the repository root if the runtime is missing on the target machine.

The README does not include a worked search example, so the first real use is best taken from the User Manual it links to, which the README says documents "search syntax, every hotkey, and every settings option". That is the honest boundary: the README tells you how to get the binary running, and the manual is where the query syntax lives.

## NTFS-only indexing is the constraint that decides adoption

SwiftList indexes through the NTFS USN Journal and MFT. Those are NTFS structures. The README does not claim support for exFAT, FAT32, ReFS or network shares, and nothing in the repository listing suggests a fallback directory-walking indexer. If your working set lives on a NAS mount, a USB stick formatted as exFAT, or a WSL ext4 image, the mechanism this project is built on does not apply to it.

There is a second, quieter limitation. The installer is marked as the build that "supports the background service", and the service runs at SYSTEM level. That is a real privilege decision, not a detail. A portable unzip-and-run build cannot install a SYSTEM service the same way, and the repository root contains portable-cleanup-registry.reg, which implies the portable build writes registry state that you may later want to remove. Anyone deploying this on a managed machine should read Installer/ and that .reg file before running either build.

Finally, this is a Windows 10/11 project built on .NET 10 WPF. There is no macOS or Linux target in the README, and the UI stack rules one out.

## SwiftList compared with Everything and Listary

The README names both alternatives directly, so the useful question is where the approaches diverge. Everything is the reference implementation of MFT-based instant search on Windows, and SwiftList adopts the same underlying idea: read filesystem metadata rather than traverse directories. The difference the README emphasizes is extensibility. SwiftList ships PluginSdk/ and Plugins/ as first-class top-level directories, with documented extension points for providers, aliases, actions, columns, previews and themes. Everything's model is narrower by comparison.

The Listary comparison is about the inline bar. Listary's signature behaviour is search inside file dialogs and Explorer, and SwiftList's README claims the same: "an inline bar that docks directly into File Explorer or native file dialogs". So on the feature Listary is known for, SwiftList is not offering a different approach, it is offering an open source one.

Where SwiftList differs from both in architecture is the process split. The SYSTEM-level indexing service is separated from the per-user UI, and the README treats that as a headline property. That is a design trade: you get an index that persists and updates independently of the app, and you accept a service installation and its privilege footprint.

## Licence, upgrade path and what maintenance costs you

SwiftList is MIT licensed. For a Windows desktop tool that is about as permissive as it gets: you can read the source, build it with make.bat, and ship modified binaries, subject to the usual requirement to preserve the copyright notice. The README also carries a donation address, which has no bearing on the licence terms. Nothing here is legal advice; read LICENSE in the repository root if the terms matter to your organisation.

The release cadence is visible in the release list: v4.2.0, v4.2.1 and v4.2.2 all landed on 2026-08-05, three builds in a single day. The last push to the repository was on 2026-08-05. That pattern suggests small corrective releases rather than a slow, scheduled train, and it means the version you install today may be superseded quickly.

Upgrade mechanics differ by build. The installer path is the one the README recommends, and the repository contains portable-updater.bat for the portable path, which tells you the portable build has its own update mechanism rather than relying on the installer. If you deploy the portable zip across several machines, that script plus portable-cleanup-registry.reg is the pair to read before rolling out a new version.

## Conclusion

SwiftList is for Windows 10/11 users on NTFS volumes who want sub-second filename search and are willing to run a SYSTEM-level indexing service, and for developers who want to extend search through PluginSdk/. It is not for you if your data lives on exFAT, FAT32 or network shares, since the README ties indexing to the NTFS USN Journal and MFT, nor if you want a cross-platform tool. Before adopting it, check the User Manual for the exact search operators and hotkeys, confirm the installer path against the portable build if you cannot grant service privileges, and read Installer/ and portable-updater.bat to see what an upgrade actually replaces.

## FAQ

### Does SwiftList need the background service to search?

The README marks the installer build as the one that supports the background service, and describes a SYSTEM-level indexing service kept separate from the per-user app UI. The portable build is offered as a no-install, unzip-and-run alternative, but the README does not document how indexing behaves without the service installed.

### Which .NET version does SwiftList require to build from source?

The README lists the .NET 10 SDK, alongside Windows 10/11 and Visual Studio 2022 or JetBrains Rider. Inno Setup is required only if you want to build the installer.

### Can SwiftList search network drives or non-NTFS volumes?

The README ties indexing to the NTFS USN Journal and MFT and does not claim support for other filesystems or network shares. Treat NTFS volumes as the supported case until the documentation says otherwise.

## Sources

- [Official documentation](https://swiftlist.github.io)
- [Official README](https://github.com/SwiftList/SwiftList#readme)
- [Project repository](https://github.com/SwiftList/SwiftList)
- [Release notes](https://github.com/SwiftList/SwiftList/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/swiftlist-swiftlist