iNKORE.UI.WPF.Modern: a Fluent 2 skin for WPF, ported from WinUI and the Community Toolkit

This is a reskin, not a framework migration

iNKORE.UI.WPF.Modern is described in one line as modern, Fluent 2, styles and controls for your WPF applications, and the short name is iUWM, with iNKORE being the name of the studio that maintains it. The project states plainly that this project is not called iNKORE, not called iNKORE UI, and nothing else, which is a small but real piece of clarity for anyone who has searched for it and found the studio's other projects instead.

What the library actually is, is a set of styles and controls that you drop into an existing WPF application. The feature list says it provides modern styles and new features for the majority of the stock WPF controls, which is the key phrase. Stock controls. You are not replacing your application's architecture, you are changing how the controls it already uses are drawn and how they behave.

That framing explains the whole library. WPF is a mature framework whose default look has not changed since the Windows 7 era, and the community has wanted the Windows 11 aesthetic without rewriting the app in WinUI. This is the answer to that, and the answer is XAML styles plus a set of controls that WPF never had.

The additional controls are ported from the Windows UI Library, which is Microsoft's own WinUI toolkit, and from the Community Toolkit, plus custom controls made by the maintainers. That is the practical significance of the porting work. When a Fluent 2 feature exists in WinUI, you get a WPF equivalent of it here rather than having to write it, and the visual result matches what a WinUI developer would ship.

The language is C#, the distribution is the NuGet package `iNKORE.UI.WPF.Modern`, and the licence is recorded as a custom one that GitHub cannot classify, with the terms in a `LICENSE.md` file at the root.

Themes, backdrops, and snap layouts in one package

The second feature line is theming, and it is more than a colour palette.

There are light and dark themes that can be easily customized, and a high contrast theme is also included. The high contrast theme matters more than it might sound. WPF's high contrast support follows the system setting, so a high contrast theme shipped as a third theme in the same system is a different thing from the system behaviour.

The third line is the Windows 11 visual features: Mica and acrylic backdrops, snap layouts, and other modern features available. Mica is the Windows 11 material effect behind a window that picks up a faint tint of the desktop or wallpaper, and acrylic is the more translucent variant used for flyouts and panels. Both are rendering behaviours that a desktop application can only have if someone implements them, and they are the feature most obviously borrowed from the current Windows design language. The phrase other modern features available is a hedge that suggests the list continues beyond what the summary enumerates.

Snap layouts are the fourth item, and they are the one that is not purely visual. A snapped window in Windows 11 can be offered a set of layout zones in the system menu, including custom layouts the user has defined. A WPF application that participates in that has to declare its window chrome accordingly, and the sample directory has a `samples/ButtonsOnTitlebar/` project, which is the part of the work that is specific to a WPF window rather than a control template.

The samples are worth listing because they show the scope. There is `Acrylic10Example`, `FlyoutExample`, `NavigationViewExample`, `TransparentNavigationViewExample`, `SettingsNavigationTest`, `ButtonsOnTitlebar`, `WindowExample`, `ExamplePhotoTaker`, `NoAppXamlTest`, `StarterKit`, and a plain `WpfApp1`. NavigationView is the Fluent 2 replacement for a navigation pane, flyout is the overlay menu, and the StarterKit is a starting point for a new application.

The library targets two runtimes at once

The platform support line is the one to read carefully, because it describes an unusual target range.

The library targets.NET Framework and.NET 6.0 or higher, and runs on Windows 7 or higher, with Windows 10 or higher recommended. The parenthetical after that is a commitment: the project says it will never leave Windows 7 users behind until the market fully says goodbye to it.

Supporting.NET Framework and.NET 6 side by side is a real engineering constraint rather than a marketing claim. The two runtimes have different dependency resolution models, different XAML compilation behaviour, and different default settings for some APIs, and a library that has to work on both cannot use the newer APIs without conditional compilation and cannot rely on the newer project system conveniences.

The payoff for a consumer is the same as the constraint: an existing.NET Framework WPF application, which is most of the WPF applications in the world today, can adopt the modern look without a runtime migration. The cost is that the library's public surface has to be conservative, and that some of the newest WinUI behaviours are approximations rather than ports of the real thing.

The tree shows the build setup. There is a `Directory.Build.props` and a `Directory.Build.targets` at the root, which is the MSBuild convention for sharing properties across all the projects in a solution, and `iNKORE.UI.WPF.Modern.sln` for the solution itself. The `source/` directory holds the library code, `samples/` the sample projects, `libraries/` presumably the third party sources it builds against, `tools/` the build tooling, `installer/` the packaging, `assets/` the images and banners, and `docs/` the documentation sources including a `docs/promotions.md`.

The gallery app is the fastest way to see what you are adopting

Before you restyle an application, you want to see what the result looks like across every control and every theme, and the project provides exactly that.

A gallery application is provided, and there are two ways to get it. You can check the latest version of the gallery in GitHub Actions, meaning the build output of the most recent CI run, or you can download the stable version from the Microsoft Store. The Microsoft Store route is the notable one, because it means a stable build is distributed through a store rather than only as a GitHub artefact, which lowers the barrier for someone who wants to look at it without building anything.

The gallery also solves a practical problem with the documentation, which the project is candid about. The documentation site is described as a work in progress, with the note that the team is currently working on it and that it can be a huge process, and the preview is available at the docs address with a reminder that it is not finished yet. So the honest picture is that the visual reference you need is the gallery app, and the written reference is still being written.

That is why the project is recruiting documentation writers, and the ask is specific. There is a note asking for passionate volunteers to write and improve the documentation for the library, with the stated goal of making the project more accessible and user-friendly for the entire community. Whether you are an experienced developer or just enthusiastic about contributing to open source, you are welcome, and the route is a pull request in the separate iNKORE-NET/Documentation repository, or the Discord server, or a Telegram group. The note that it is very easy to join is not a rhetorical flourish, because writing a getting-started page is a bounded task with a clear definition of done.

What the release cadence tells you about the project

The version history and the working habits give a picture of a small studio project with an irregular rhythm.

The three most recent releases are v0.10.0 on 2025-01-23, v0.10.1 on 2025-07-19, and v0.10.2 on 2025-11-18. The last push to the repository was on 2026-10-06, so the code is being worked on well after the last tagged release. The default branch is `main`.

A version number still in the zero tens, with patch releases spread over ten months and then a gap of nearly a year to the last push, describes a project that is maintained between releases rather than released continuously. That is normal for a UI library, where a release is a packaging event rather than a code event, and it also means you should not expect a semantic version promise. There is no deprecation policy described, and a 0.x version number conventionally signals that breaking changes are permitted.

The two things that follow from that are practical. If you adopt the library, pin the exact version, because a minor bump can change a style. And if you depend on a specific control's behaviour, check the release notes between your version and the newest one, because the versioning scheme gives you no guarantee.

The community infrastructure is more developed than the versioning. There is a Discord server, a Telegram group, a Twitter account, a community guidelines page with rules linked from the project site, and a sponsorship link on the studio's own site. The contribution section asks for bug reports and pull requests on GitHub following the project's contribution guidelines, and separately asks for documentation and translation volunteers. The project also asks for help in a way that is worth reading twice, because the ask is not only code. It asks you to star the repository, share it on social media, tell your friends about it, and add gadgets to your projects, with instructions linked in `docs/promotions.md`.

That is a small project dependent on reach rather than on funding, which is fine to know when you are deciding how much to expect from it.

Where this library is the wrong answer

The boundaries are clear and they mostly point at one fact: WinUI 3 exists.

First, for a new application starting today, this is the wrong library. WPF is in maintenance mode on the platform, and the modern Windows application stack is WinUI 3. Choosing a Fluent 2 style library for WPF is a sound way to make an existing app look current, and an odd way to start a new one. The stated purpose of the project is modern styles and controls for your WPF applications, which is precisely the retrofit framing.

Second, the fidelity is a port, not the original. The controls are ported from the Windows UI Library and the Community Toolkit, and a port is an approximation of behaviour as well as appearance. Anything that depends on subtle WinUI interactions, specific animation curves, or a control that has not been ported yet, will look right and behave differently, or will not be there.

Third, the documentation is not finished. The project says so, twice, and it is actively recruiting writers. For a library whose selling point is the visual result, evaluating it means running the gallery and reading the sample projects, which is more work than reading a reference, and it means the guidance you find may change.

Fourth, the version scheme gives no stability guarantee. A 0.x library with irregular patch releases and no stated deprecation policy means you own the upgrade work, and any style change in a minor version is your visual regression.

Fifth, the licence needs reading. The repository listing records the licence as a custom one that GitHub cannot classify, with the terms in `LICENSE.md`. For a component library that you will redistribute inside an application, the exact terms matter and cannot be inferred from a badge.

Sixth, and this is a Windows-only consideration with a long tail, the library supports Windows 7 and .NET Framework because the maintainers made a deliberate choice to keep older users working. That choice constrains the code base in ways a newer fork would not accept, and it means the library will not always be able to use the newest platform APIs. For most teams that is a benefit. For a team shipping only to Windows 11 and modern .NET, it is a constraint you are paying for someone else's priority.

Editorial conclusion

iNKORE.UI.WPF.Modern fits a team maintaining a WPF desktop application that has to look like a current Windows app but cannot move to WinUI, because the library delivers the Fluent 2 look as XAML styles and controls rather than as a framework migration. It is the wrong choice for a new project starting today, where WinUI 3 is the direction Microsoft is pushing, and the wrong choice if you need documentation you can rely on, since the site is described as unfinished and the project is actively recruiting documentation writers. Check three things before you adopt it: that your target framework is covered, since it supports .NET Framework and .NET 6.0 or higher, that the licence in the LICENSE.md file suits your distribution, and that the gallery application gives you a working reference for the look you are about to restyle.

Frequently asked questions

Official sources

1. iNKORE-NET/UI.WPF.Modern on GitHub
2. Issues
3. README
4. Releases