Wino Mail rebuilds functionality from the app Microsoft deprecated, one account at a time
Built-in Mail & Calendars app clone for Windows.
At a glance
- What is it?
- Wino Mail is a WinUI 3 replacement for the Mail, Calendar, People and To Do apps Microsoft deprecated on Windows, written in C# and XAML with an explicit rule that contributors stay responsible for AI-assisted changes. It ships through the Microsoft Store as GPL-3.0 software while also selling an Unlimited Accounts add-on, and that pairing is worth understanding before you install it.
- Who is it for?
- Adopt Wino Mail if you used the retired Mail and Calendars apps and want the same interface back with broader account support, since preserving that user experience is the project's stated purpose. Do not adopt it if you need features the project has not rebuilt yet, because the entire rationale is bringing Mail and Calendars functionality over time, which means gaps are expected rather than accidental.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The motivation is a deprecation notice
Wino Mail is a native Mail, Calendar, People and To Do client for Windows, and it exists because Microsoft deprecated the app it replaces.
The author describes themselves as a big fan of Windows Mail and Calendars because of its simplicity, and finds it more intuitive for daily use than the Outlook desktop client and than the new WebView2-powered Outlook version. Seeing Microsoft deprecating it is what dragged them into starting Wino a couple of years ago.
The stated goal is specific and constrained: bring all the existing functionality from Mail and Calendars over time, without changing the user experience that millions have loved since the Windows 8 days.
That last clause is the design constraint worth carrying into any evaluation. This is a compatibility project, not a redesign. The reference implementation is a specific shipped Microsoft product with a specific set of behaviours, and fidelity to it is the point. It also sets the expectation about missing pieces: functionality arrives over time, so a feature that Mail and Calendars had and Wino does not yet have is a backlog item rather than a deliberate omission.
The project has an unusual sentence about its own history. It started before the current AI era, and it welcomes AI-assisted contributions when they comply with its coding rules, architecture and maintainer decisions. The contributing section reinforces this: contributors remain responsible for every submitted change, including AI-assisted changes.
Two distribution channels, and beta is a separate thing
Wino Mail is available two ways, and the README is clear that these are not equivalent.
The Microsoft Store channel is the recommended route for most users. The direct route exists for users who prefer to install outside the Store, delivered through App Installer.
The two channels are described differently, and the difference matters. Beta releases are available from GitHub Releases, and the README states plainly that they can contain unfinished changes and are for testing. So the GitHub releases page is not a faster route to the stable build; it is a separate, less stable line.
The recent release history is on the permissive side of versioning, with tags like 2.2.0.0 and 2.1.1.0, and the most recent is from October 2026. The four-part version is consistent with a Windows app where the last component often carries a build counter rather than a semantic version.
There is also a commercial dimension. The project asks for donations to fund the website and development costs, and separately points to buying the Unlimited Accounts add-on in Wino as a one-time purchase. That second item is a paid unlock inside GPL-3.0 software, which is a licensing arrangement worth reading carefully rather than assuming.
For context on the surrounding activity, the repository is not archived and the last push was on 2026-10-15, so development is current rather than a slow drift.
What it supports, and what WebView2 is doing in there
The feature list is what tells you whether this is a daily driver for you, and two entries deserve particular attention.
The protocol coverage is broad: Outlook, Gmail, IMAP, POP3, CalDAV, CardDAV, and local data support. CalDAV and CardDAV alongside IMAP and POP3 is the notable part, and the list also covers calendar and contact standards. Adding a CalDAV calendar or CardDAV address book server is not a niche request in a self-hosted or privacy-conscious setup.
The account model includes linked and merged accounts, so you can keep separate identities separate or unify them as one inbox.
Then there is WebView2-based mail reading and composition. This is the entry that changes the character of the app. Rather than rendering rich message bodies natively, it uses an embedded browser engine. That is a pragmatic choice for HTML mail compatibility, and it is the same technology the author criticised in the new Outlook version. The practical difference is that here it is applied to message rendering rather than to the whole application shell, which is why the shell can still be native WinUI 3.
Offline workflows and local search come with background synchronization and toast notifications, which together are what make an installed mail client usable rather than a thin web view. EML and ICS file integration handles file associations, and protocol activation covers mailto, webcal, webcals and a Wino protocol handler.
The interface is native WinUI 3 with light, dark and high-contrast support, and the high-contrast entry is a real accessibility commitment rather than a checkbox, since Windows high contrast themes are a hard requirement for a number of users.
The repository layout suggests a cross-platform ambition
The root of the repository is more revealing than the README about where this project is heading.
There are two solution files and two code workspaces: WinoMail.MacOS.slnx and WinoMail.MacOS.code-workspace alongside WinoMail.slnx and WinoMail.Windows.code-workspace. A Windows mail client with a parallel macOS solution and workspace, named as a first-class target rather than an afterthought, indicates that the codebase is being structured for a second platform.
The solution files use the .slnx extension, which is the newer XML-based solution format, so the project is on current tooling rather than a legacy solution layout.
Central package management is in place through Directory.Packages.props and Directory.Build.props, alongside Directory.Build.targets. That is the modern approach for managing versions and shared build properties once across a large project, and its presence is a good sign for how many packages a project of this size would otherwise accumulate inconsistently.
The rest of the tree follows a normal application layout: src/ for the code, tests/ separate from it, controls/ for reusable UI, build/, scripts/, tools/, docs/ and icons/, plus nuget.config and global.json which pins the .NET SDK version for everyone building the project.
The configuration directories are the ones that stand out. There is an AGENTS.md, a .claude/ directory and a .codegraph/ directory. Three separate conventions for machine instructions to coding assistants, which is consistent with the README's explicit statement about welcoming AI-assisted contributions under rules. Whatever approach you take to the project, those files are where the project's expectations for generated code are written down.
Editorial conclusion
Adopt Wino Mail if you used the retired Mail and Calendars apps and want the same interface back with broader account support, since preserving that user experience is the project's stated purpose. Do not adopt it if you need features the project has not rebuilt yet, because the entire rationale is bringing Mail and Calendars functionality over time, which means gaps are expected rather than accidental. Verify first what you need against the current feature list, particularly CalDAV, CardDAV and background sync, and read the licensing position before relying on the Unlimited Accounts add-on in a deployment where the GPL-3.0 obligations matter to you.
Frequently asked questions
What is Wino Mail and why does it exist?
It is a native WinUI 3 client for Mail, Calendar, People and To Do on Windows, written in C# and XAML. It exists because Microsoft deprecated the built-in Mail and Calendars apps, and the project's goal is to restore that functionality without changing its user experience.
How do I install Wino Mail?
From the Microsoft Store, which is the recommended route for most users, or directly with App Installer if you prefer to install outside the Store. Beta releases are separately available from GitHub Releases and can contain unfinished changes.
Which account types does Wino Mail support?
Outlook, Gmail, IMAP, POP3, CalDAV, CardDAV and local data, with linked and merged accounts supported. Rich mail reading and composition uses WebView2 rather than a native renderer.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/bkaankose-wino-mail)Was this useful?