Probably not for now, see #10881.

I would like to include myself to this feature request, it would be awesome that Flutter supported Windows 10 UWP.

This should cover Xbox One as well, which you can target in Xamarin/UWP

Yes please. Windows support would definitely be a game-changer.

this is not official, but you can check this project. https://github.com/google/flutter-desktop-embedding I think glfw is also available on windows so you can try 😉

Man... I want real xplat :)

I was just typing up the same feature request 😉... I hope this gets some traction!

As a user with several Windows, MacOS, and Chrome OS devices in my home... the latest model Surface Pro consistently ends up being my daily driver each year; ever since the release of the SP4. Seems to be extremely popular on campus and at work now as well. However, the scant selection of high-quality UWP apps continues to be the largest sore spot for me.

I believe the elegance & ease of Flutter could potentially provide the incentive devs/corps need, to include Win10 in their multi-platform strategy... and in the process, hopefully promote Flutter to as similar a status/popularity as Java; for IT exec consideration, when selecting tools & platforms for product development.

Xamarin, Ionic etc. include UWP, so why Flutter?

Removing assignment, since this is a very broad umbrella bug. Specific subtasks are tracked in individual bugs, which will get specific assignees and milestones as usual.

Removing from the Window MVP project. We're still evaluating UWP as a target, and will likely support it eventually, but the initial focus is on enabling Win32 to limit the scope.

All platofrms that don't support uwp are unsupported as of January 20th 2020

The decision to focus on Win32 APIs first are technical, not based on target platforms.

wpf should be ignored

There are currently no plans to use WPF.

I thought it would be worth sharing a September 2020 update on the state of the Flutter UWP experiment I've been working on. Progress has been slower than I’d like as this is a spare time / best effort project that I've been working on only during evenings and at weekends. However, I have been able to make a decent amount of progress over the last six months or so and get some scenarios working namely:

• a proof-of-concept WinRT Flutter embedder using CoreWindow in conjunction with WinRT input APIs running in the AppContainer sandbox: https://github.com/clarkezone/engine
• a corresponding test Flutter UWP runner (only 115 lines of c++!) with a demo Flutter experience using Flutter Gallery: https://github.com/clarkezone/fluttergalleryuwp
• using these I was able to publish a MSIX packaged version of Flutter Gallery successfully to the Microsoft Store, passing the WAC API checks for store certification (finally :-))

Still a ton to do to get this to something production-ready and I have no clue how long that will take but it certainly shows that Flutter UWP is viable.

There are a few largish remaining issues to solve such as how to do tooling integration with flutter create, how to get hot reload and observatory support working and more. More details here.

In the example below, I was able to take the source of Flutter Particle clock from https://github.com/miickel/flutter_particle_clock build it in release mode targeting Windows, take the resulting app.so binary, package it for UWP using the same Flutter Runner as used above for Flutter Gallery, publish to the Microsoft Store and install on my XBOX:

I don't think there's much reason to aim for a native version of Flutter on UWP. The two beneficiary devices are Xbox and HoloLens (mostly the former), so honestly I'd be more interested in building a UWP WebView2 wrapper that exposes WinRT APIs, then making sure that the Win32 version (if/when it gets WinRT API access) accesses those APIs in a similar way. Native performance on Xbox is not essential and the HoloLens barely exists.

My rationale is that a webview project would be infinitely more maintainable and the project could function as a much more relaxed, asynchronous project. Tooling would be a relatively minor extension to the web tooling at most.

Is coordinating with a theoretical web wrapper project something the Win32 team is willing to do? Goal would be the option to write once use anywhere with WinRT APIs. Or are WinRT APIs not on the Win32 team's roadmap?

https://github.com/woodemi/quick_blue/blob/master/quick_blue_windows/windows/CMakeLists.txt

https://github.com/woodemi/quick_notify/blob/master/windows/CMakeLists.txt

It is possible to use WinRT APIs now in plugin. No need for support in Flutter framework/engine

@cbracken , I think this might be closed as it collides with #102172

Yep -- was waiting to file that issue before closing this one out.

Closing this since our intent is to wind down development on, and remove the UWP embedder in order to focus on the Win32 embedder which, over time, will start to adopt Windows SDK support (once our supported OSes is a subset of those that support doing so).

See: #14967 (comment)

@cbracken
To be fair, UWP look like being slowly phased out.
Maybe just focus on WinUI+ Uno. That is basically open source. As Flutter is direct competition to Uno and Microsoft.
Its would be all community's work.
Regardless x86 architecture (Most the userbase, still be on Windows 10-11), and UWP still have year of support until end of Windows 11.

We are very proud to work closely with Microsoft to ensure Uno Platform can provide day-zero support for WinUI 3 and bring WinUI-built applications everywhere, including Web, Linux, macOS, iOS and Android.

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.