Flutter: ☂ Add support for UWP

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 :wink:

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.

I think this is a mistake. All platofrms that don't support uwp are unsupported as of January 20th 2020. Ie by the time this is ready.

It's pointless to support a legacy platform when you don't have to because the mass migration is occuring right now aggressively.

The sole focus should be uwp and wpf should be ignored.

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.

Sorry, win32 should be ignored.

Why?

Because win32 limits flutter on windows platforms. Uwp does not because by the time you have this out there will be no windows platforms supported that don't support uwp, yet there are platforms on windows that do not support win32 (arm64 which would require a rebuild entirely)

To be clear, anyone interested in contributing effort towards UWP support is still welcome and encouraged to do so.

yet there are platforms on windows that do not support win32 (arm64 which would require a rebuild entirely)

Windows 10 on ARM supports Win32, you only need to compile the application under ARM64, as is the case with UWP.

All platofrms that don't support uwp are unsupported as of January 20th 2020. Ie by the time this is ready.

Support for Windows 8.1 ends in 2023. It does not support UWP.

@stuartmorgan Hey I am interested on working on UWP support.

You mentioned above "We're still evaluating UWP as a target" - I'd like to know what you have discovered.

Thanks,
-Jake

@Kapranov98 I just finished experimenting with porting flutter to Windows 10 ARM. Win32/UWP is the least of the issues. Dart itself requires substantial changes to run on WinARM. The ARM specific code in dart was never designed to run on anything but posix'ish systems (ios, android, linux, etc). Not to mention WinARM only supports the Thumb-2 instruction set, and as I understand it the dart jit uses the ARM instruction set (although I need to get official verification of this). Getting the port to work will be a fairly substantial effort.

@Jakesays did you try enabling /appcontainer as part of your experimentation?

You mentioned above "We're still evaluating UWP as a target" - I'd like to know what you have discovered.

I'll start an initial document to collect information soon and link it from here. There aren't a lot of specifics at this point though (and once the initial document exists, things like the results of your ARM investigation would be very welcome as additions). When I say "still evaluating" I mean that we still plan to support it in the future, and as part of that will evaluate what all needs to be done. Since it's not our focus for an initial MVP, there isn't a lot of active current investigation.

Part of that will involve breaking down specific aspects, since as the comments above point to there are a number of different elements, each with their own challenges.

Does this conversation change now that Windows 10 X is a thing? Win32 will be able to run on Windows 10 X but I think UWP will be a much better fit. Is Flutter plan to support dual screen device at all? Surface Duo and Surface Neo?

@nerocui As I understand it the Duo is an android device so I imagine Flutter would work just fine (at least on one screen). I'm not sure which CPU the Neo is running, but if it's ARM then Flutter is pretty much dead in the water. Dart currently doesn't generate compatible assembly code for winarm (winarm uses thumb-2 instructions exclusively, and IIRC Dart uses both thumb-2 and arm instructions). It would be a non-trivial undertaking to make it work.

@JakeSays Neo use Intel Lakefield so it's x86. I'm more concerned about the UWP part of the story. On a mobile device like Neo, managed life cycle from UWP app model will come in handy. Win32 will not be ideal for battery life. Also, win32 apps on Neo will be running in a container, which is bad for performance. Targeting UWP is actually a really smart move. Both Android and iOS run managed app model, UWP should bring more consistency. Windows 8 can pretty much be ignored, none of the statistics show any meaningful market share.

@nerocui Ok then getting flutter to target UWP should be possible. The biggest issue is the lack of OpenGL support in UWP, but that should be solvable by using ANGLE underneath flutter.

I was looking in to UWP but my target was ARM/WinIOT.

@JakeSays UWP should be ok for most devices, but it's a headache for Windows on ARM. As ironic as it is, UWP(if ever comes) flutter will have to remain emulated on ARM based Windows devices. What level of completion did you achieve for the flutter/uwp port?

@nerocui I stopped working on it once I discovered the Dart issue.

While UWP is definitely desired, Win32 is definitely not going anywhere. Microsoft announced recently that they are adding Win32 support to Windows Store. Also, many games continue to be developed under the Win32 platform.

Yep, Microsoft accept Win32 app on Store and it use widely in the world than UWP. Win32 app has best performance but it has a limit in battery consumption. Win32 has only 2 states Running or Not Responding (Freeze), but UWP has more states (more friendly with mobile devices) such as Running in background, Suspended.

https://docs.microsoft.com/en-us/windows/uwp/launch-resume/app-lifecycle

Battery is important for mobile device like laptop or Windows 10x device

This should be a simple conversation:

As of January 14th there are 0 supported versions of windows that don't support UWP.

There is major versions of windows that don't support win32 apps being deployed to them in the store or otherwise.

Win32 is a legacy platform. If you were maintaining an older system, sure, win32 is it. But flutter is all new code. There is 0 reason to write it for an API that is legacy and not supported on arm, when it can be written for UWP and supported everywhere where windows is supported.

But flutter is all new code.

This is not actually the case; I have spoken to people interested in add-to-app scenarios to allow adoption of Flutter in existing Win32 applications.

There is 0 reason to write it for an API that is legacy and not supported on arm, when it can be written for UWP and supported everywhere where windows is supported.

Comments above have already explained that supporting those devices is not a simple matter of Win32 vs UWP. Similarly, sandboxing restrictions that are needed for some deployments or distribution models would apply to the engine, which is a large, existing codebase, not green-field development, so there are complexities there as well.

This argument also ignores the fact that there are many people developing new code who care about install base, not supported versions. The reality is that Windows 7 is still a very substantial portion of the install base, and that's unlikely to change dramatically in the immediate future.

There are good reasons to support UWP, and as I've said several times we do plan to support it in the future. Significantly oversimplifying the tradeoffs involved in order to claim that the decision is simple won't accelerate that process, however. Again, anyone who feels strongly about UWP support is certainly welcome to contribute to the development of a UWP embedding.

@stuartmorgan are you aware of any discussions about a solution to the thumb 2 only restrictions of winarm?

@stuartmorgan UWP can be used in win32/Winforms/WPF applications. XAML Islands are straightforward and well supported. Win32 doesn't work on winarm as oultlined by @JakeSays. Thus your argument makes 0 sense and is not justification for flutter targeting a legacy api for the case of embedding flutter in legacy apps.

Further for all NEW development:

Windows 7 install base is dropping like a stone. WinARM is about to shoot up massively in the next year. Windows 7 will be < 5% of Windows market (less than 50 million devices and none of those paying for software) by July at current rates) and right there bouncing on the bottom with Windows XP and Vista (almost solely due to embedded systems where they would never roll out a new Flutter based application without replacing the OS with it because of lack of support.

Your statements and this entire approach of Win32 demonstrates a failure to understand how Windows versions expand and then drop (before endless revisions of Windows 10, all of which have UWP so this flow is irrelevant):

1. New version released, very slow adoption on new devices only and only in the consumer space.
2. (Win 7 => 10) Consumer devices are updated more quickly and market share grows.
3. Growth is limited by tech geeks that don't like change claiming that new version is worse than old version even though it isn't.
4. Businesses continue to sit on sidelines as new version gains majority market share in consumer space.
5. Microsoft announces retirement date of support and patches for old version of Windows as consumers start ignoring tech geeks and realize new version is vastly better than the old one. Adoption reaches about 50%.
6. Businesses through pressure from users that like the new version way better; software that works better on the new version; and a looming deadline for obsolesce start deploying new version on replacement hardware. Adoption reaches about 60-65%
7. Forward thinking IT managers start doing controlled rollouts of new version on a group by group basis.
8. Deadline looms months away, and the rest of the IT managers just ram it down, bitch about problems because they didn't plan it out properly and slam Windows (these are the tech geeks from above) for their problems. Market share goes from 65% to 90% in 6-8 months as the rush at the deadline for support completes.
9. The only systems left are embedded who pay extra for security patches because of the high cost of replacing these systems that were hardware designed for the previous OS and generally require hardware replacement.
10. Embedded systems start getting hacked, so businesses do cost benefit and start replacing hardware.
11. Only people left using OS are 3rd world countries that can't use anything else and getting hacked isn't an issue.

We're at #8 right now. If developers are targeting Windows 7 for new software they are ignorant of history. Windows 10 rollout is exactly following Windows 7 rollout before it. There is 0 reason to target #9 because they don't roll out major software updates even with incremental flutter in win32 apps between hardware releases.

Thus:

1. XAML islands address your incremental win32 apps with flutter inside of them argument. And virtually 0% of people that actually buy (and don't steal) software will be using a platform that can't use XAML island by September of this year right around when flutter desktop will be stable enough for production.
2. There is no logical market for targeting Windows 7 for a new application. Absolutely no one with any understanding of history and how the desktop market works between consumer and business would write a new application in win32 unless there was an absolute blocker on an API (which is highly doubtful the APIs are largely mirrored now). And even if they did, it would be running on Windows 10 and thus no reason why they couldn't use XAML Islands for flutter in that win32 app.

Thus the flutter decision to use win32 is ridiculous and shows a complete failure to understand the Windows market. (which isn't surprising coming out of Google sadly)

@JohnGalt1717 I may be mistaken, but my issue with winarm had nothing to do with win32. Also, and this is just a suggestion, but you may want to turn down rhetoric a bit. Using terms like ignorant and making broad, unsubstantiated claims really impede getting your point across.

Getting Flutter to run on winarm is not a trivial effort, as has been pointed out several times in this thread. Getting Flutter to run on win32 is a fairly trivial endeavor as it requires little changes to flutter itself. It makes sense to start with low hanging fruit (win32), especially given that most of the interest I've seen regarding Flutter and windows has been all about the desktop. This has little to do with win32 vs uwp and more to do with the fact that the reality is there are a LOT of win32 systems out there NOW.

@JakeSays WinArm doesn't allow win32 apps to be published to the store on Arm. (other than Office) Aside from the compile issues.

What part of my claims isn't substantiated? The data 100% supports my position. By the time Flutter for desktop is ready for release on Windows, there will be 5% or less of Windows machines that can't run UWP and a ton that you can't deploy a win32 app to. (i.e. all ARM devices including Duo or Neo or whatever one runs windows, and all of the 3rd party versions that are ramping up.)

Getting flutter to run under UWP which works on WinArm and WinX64 and WinX86 shouldn't be any more difficult than win32. It also gets you spell check in text boxes etc., proper scaling based on DPI without heroics, and better culture support out of the box. (not to mention media playing is vastly better and easier than win32. I.e. I can play widevine, playready, AES encrypted video trivially with 3 lines of code in UWP. To do the same in win32 is a massive endevor. To say nothing about captions.

There's no "low hanging fruit" with win32 versus UWP. UWP is desktop. Everything else is legacy desktop. (other than Silverlight obviously) They're back porting UWP and it's APIs for legacy platforms to support companies not rewritting their apps. They've added XAML islands for exactly the use case outlined of adding Flutter to existing applications (and anything else UWP).

"There are A LOT of win32 systems out there NOW".

Here's how the diagram looks in September: 5% of people running windows would be locked out by September. Of that 5% virtually none of them buy software based on historical data. By October 5% of windows users will be using it on ARM of some sort and will be locked out of Win32.

So pick your poison.

Note however when you're doing so, that the number of people locked out of UWP will continually get smaller, while the number of people locked out of Win32 will continually get larger. So you're effectively guaranteeing a rewrite in 12-24 months if you go win32 instead of UWP all for a dying market that you can't effectively support anyhow, because Microsoft isn't going to be fixing bugs in Windows 7, only security updates for those that pay for them. (which won't be using an app with flutter anyhow)

It also ensures that the Windows version of the video player will always be massively limited because of the massive lift required to get DRM to work on Win32, there won't be an inline spell checker or auto-correct for those using a software touch keyboard, and culture stuff will be way harder to get right.

This is called backwards thinking.

If you don't like the word ignorant, that's not my problem. If you don't know the facts and history, then by definition you're ignorant. In this case harmfully so. If you want to use a socially correct word that hasn't be banned so be it, tell me what you'd like me to use and I'll do a find and replace.

Tell me where I'm actually wrong. And even if my assumptions and projections are slightly off, tell me how my assertion over time isn't right and less harmful and less work than the alternative which is vastly more work, vastly more bugs, and a vastly more difficult time reaching parity with other platforms over time for things like video, spell check, etc. No matter how you slice it, by this time next year virtually no one will be using Windows 7. And that means that Flutter will be 100% available for virtually everyone in every situation if it's done in UWP and not win32. Versus win32 which caters to a dead OS and locks flutter devs out of the new and growing market for WinARM.

As an example, I can, right now, in UWP create a video player with all of the functionality of the current video player, plus captions plus DRM in UWP in a few minutes with excellent documentation that can be consumed by Flutter as part of the flutter video library. I know for a fact that they're working on captions and DRM for the flutter video player right now. And I don't need to know anything but UWP calls. That means that it's trivial to provide full video functionality in Flutter with UWP and almost any C# can do it which is a huge group of people versus those that know how to use C++, create DirectX surfaces, and create media encoders/decoders/transcoders and hook it all up. (yes, in win32 you can't play lots of formats without custom libraries that are supported out of the box in UWP) The effort to create the same product between UWP (even if written in C++) versus win32 is about 1/100th the amount of time.

The same is true for serial communications, bluetooth, location tracking, etc. etc. etc. (and location tracking and sensor APIs are just now, in Windows 10 2020/H1, coming to win32 and won't work in previous versions of windows 10 so you're relying on everyone using the very latest version of Windows 10 to even have access to this functionality, versus 100% of users in Windows 10 having access to UWP functionality for these apis.) Name your functionality that you take for granted with plugins for flutter for Android/iOS and you'll see the same thing: Implementing them is trivial in UWP versus win32 and thus you're far more likely to get them implemented in UWP than if you write flutter for desktop in win32 aside from all of the other issues.

@JakeSays Still waiting for you to demonstrate anything disrespectful (or wrong) with what I said. From what I can tell, you just don't like a word, which I used correctly. And, most importantly, I used it in the abstract, not against you or anyone else personally. It was not an ad homonym attack.

@stuartmorgan are you aware of any discussions about a solution to the thumb 2 only restrictions of winarm?

@JakeSays I have not been following discussions at the level of the Dart compiler; I'm not aware of discussions around ARM support, but that doesn't mean they aren't happening. You should definitely file a Dart feature request if you haven't already.

The biggest issue is the lack of OpenGL support in UWP, but that should be solvable by using ANGLE underneath flutter.

The current Windows embedding already uses ANGLE, and James has been experimenting with UWP support since the early days of his work on that embedding, so that's already well underway.

@stuartmorgan I'll do that.
And yeah I had forgot that the windows embedder is using ANGLE.

@JohnGalt1717, please review our Code of conduct. Flutter's community standards require professional and respectful discourse, and actively doing our best to make people feel welcome.

There are a lot of passionate and talented people working on Flutter, and a lot of good reasons to pursue or not pursue a particular line of development. I can tell you're passionate about having Flutter work on UWP. So are others. Some are also passionate about getting it working on win32. This is an open source project, all it takes to make it happen are contributions. In the mean time, please avoid suggesting that contributors working on alternative paths are ignorant, wasting time, or engaged in backwards thinking.

If you cannot see why your last few posts fail to rise to the level of mutual respect we aspire to in this community, please take a less active role.

/cc @timsneath @Hixie

@dnfield given I did none of those things I fail to see your point. I outlined factual history, and a path being taken that ensures that this will have to be rewritten, and will not reach parity with other platforms.

If you read carefully, at no point did I call anyone ignorant (which litterally means unaware of facts and is not derogitory, itself a statement of fact), nor did I accuse any individual of backwards thinking. (Ie targeting a legacy platform that cuts you off from the future while embracing a dead and increasingly irrelevant past as of January 14th)

So I fail to understand how anyone would be offended unless they decided to identify with the generality I used and I can't control that.

If you feel offended by statements not made about you then I'm sorry you feel that way. Maybe the solution is to take my position seriously and think about it logically and demonstrate that you did indeed take these facts into account and are not ignorant of them and you have some long term plan for how win32 is going to work on windows that requires the store and that store doesn't allow publishing win32 arm apps. And that the overhead of using win32 will ensure that windows is always behind other platforms as you're cutting your possible contributors by 90+% with this choice. Then it would be clear that you are neither ignorant nor backward thinking and thus what I said shouldn't offend you.

Instead, I get "I'm offended (about something not directed at me), thus you're wrong". Which isn't an argument in any debate.

Given that none of my position has been addressed no matter how it has been phrased, it's clear that flutter is not likely to in any timely manner be a viable solution on windows and allow parity of an application written for iOS, android and windows. Which ensures that my team will not be using flutter as planned on our next project since you're forcing us to use at least 2 frameworks (and thus at least 2 programming languages) as a result of this decision so I might as well choose a path of excellence instead of compromise even if there is more overhead.

James has been experimenting with UWP support since the early days of his work on that embedding, so that's already well underway.

@stuartmorgan @clarkezone Is there any publicly available example of running Flutter on UWP? I'd love to try this out even if it's in very early stages.

I am working on a prototype of UWP support currently. It's still very early (eg I haven't yet seen pixels) but I do have a plan for how to do it. It will be dependent on a minor amendment to a previous Angle change I made.. I have that coded up but not yet submitted to Angle. Disclaimer: this doesn't constitute a commitment to ship something, its still very much an exploration of what's possible. I will report back here when I have made slightly more interesting progress (eg pixels).

Thank you for the prompt response @clarkezone

I found in your FDE fork a branch called uwptest. Is it the one that you are experimenting at? I would love to follow your updates on this route.

NP, yea, that’s the FDE branch. In there short term there will be a lot of temp hacking to prove out certain theories.

Hi, @clarkezone! Can I ask, is your work backed by Microsoft? Can we expect Microsoft to support Flutter to create Windows apps? If so, are there any plans of making UI Fabric available for Flutter?

I think, recently there has been more and more interest in building beautiful corporate software to improve employee engagement/satisfaction. I'm currently working on a number of such projects. Just recently, we released a Flutter-based Android application for one of the Big Four financial firms. While those enterprises tend to use C# and Xamarin for their internal software, they expect higher quality of UI for their workplace experience mobile apps - in which case, Flutter proves to be a better option. At the same time, Microsoft produces great devices used in the corporate environment that could run those Flutter apps, so it would be great to see more support from Microsoft and/or Google to make this happen.

Hi Lukasz. My work is not backed by MS, it's done on a personal basis in my free time. Agree on your other points for sure. FWIW I've made some pretty good progress, I have prototype Flutter runner working end-to-end for output/rendering (no input yet), the big / next task I'm currently working on is to make everything link correctly without pulling in user32/gdi32 etc.. this step is required to be able to successfully see the prototype run on non-desktop devices such as XBOX, Windows 10x emulator and is proving to be (another) yak shave :-)

PLease add Windows Store !!!!

@daniele777 that's what i've been working on;-) Status update: down from 84 linker errors to 10

Can i help ?? to improove project ?? can do me task?

@daniele777 not at this point, still getting the basic PoC working. Linker errors are cleared but there is a build issue in the invocation of Dart getting into an infinite loop in the build pipeline. There are also other issues. I’m going to be on vacation for a couple of weeks hence no progress for a bit tho once I’m back and we’re through the PoC phase there may be parallelizable items which I’ll report on here in that eventuality.

all right all the best!

Can't wait for this to get here sooner. I tried the current win32 based flutter on windows. OMG the render is so pixelated that it looked like it's modern design but implemented using 10 year old framework. It's not something one would expected to see on a 4k screen. Being used to the smooth edges on text in UWP apps and modern web apps, win32 rendering looks extremely dated.

@nerocui - if you're seeing pixelated rendering on Windows that is very likely a different bug that will not be fixed just by migrating to UWP. Could you file a new issue about that with steps to reproduce (and perhaps a screen shot of the pixelation)?

@dnfield It's not like images are pixelated. It's just the text and shape are rendered (seems like) without hardware acceleration so that the edges doesn't look smooth. This happens to a lot of win32 programs I see. There is no reproduction steps, as it's just the text and button on the default template page.

@nerocui It's because win32 apps don't have proper DPI scaling compared to UWP. It's POSSIBLE with a TON of work to get win32 text rendering working properly, but it's VERY difficult.

@JohnGalt1717 Thanks, that's exactly my point. Flutter should be about building beautiful cross platform apps, but win32 is the single thing that's making the apps ugly. It makes the flutter implementation on windows look inferior than the other platforms.

win32 is the single thing that's making the apps ugly

As @dnfield said, it's extremely unlikely that this is the case. Flutter text rendering is being done entirely by Skia, into a (properly scaled for DPI) GL context. Creating the GL context with UWP APIs isn't going to change the rendering.

Please file a bug with screenshots highlighting the issues you are describing.

It may be as simple as the embedding ignoring an anti-alias flag somewhere for example. But without steps to reproduce we can't tell.

https://github.com/flutter/flutter/issues/53308
Filed issue. Please see if it's accurate/enough info.

I'd guess that if you set your DPI to 150% or worse 175% and load up some text you'll see it.

Please stop posting here about details of rendering; it's unrelated to this issue, per my explanation above, and thus off-topic.

ready for pubblish on windows store? any news?

No, not ready to publish to the store. Pixels and input are working on XBOX and Windows 10x. Still iterating on the API. Still a lot of work remaining.

I've been thinking about a slightly different approach - I haven't tried it yet but might do if I find some spare time - what about using Flutter for Web with Skia WASM on desktop (which could be backed by Blazor)? I can think of a limited access to I/O being one downside, but the actual UI rendering and event handling should work as expected. Windows appears to have a good support for PWAs (so does Chrome OS), and this approach might be easier to implement while still achieving good performance.

@lukaszciastko no, that will be one more Electron. Flutter should be rendered into a native Windows window(HWND), that in its turn could be embedded to any kind of native Windows app (win32, Winforms, wpf).
IMHO uwp shouldn't be considered as a main kind of Windows app. Even MS didn't it.

@clarkezone I can't wait to see your work rolled in to the project so we can apps that run on Windows

so we can apps that run on Windows

It's already possible to run Flutter apps on Windows, and has been for some time. This issue is now specifically about UWP.

I'll update the title to make that clearer.

so we can apps that run on Windows

It's already possible to run Flutter apps on Windows, and has been for some time. This issue is now specifically about UWP.

I'll update the title to make that clearer.

Stuart, I haven't seen anywhere in the documentation on how to build and run Flutter apps on Windows. Can you please tell me where I can find this info?

@steskalja You have some doc here https://github.com/flutter/flutter/wiki/Desktop-shells#create
In resume, you have to be in the master branch and run:
flutter config --enable-windows-desktop

In the project you want to try it:
flutter create . // Will add the windows folder, be careful with changes in android and ios folders,
flutter run -d windows

More specifically, my thought around this dev. is to hope that there is some relation with Project Union. I love flutter and so happy that this SDK is a thing. I am concerned on the future of Win32 apps in the Windows OS.

What is the knowledge base that the flutter team has?

When you get this finished, does it mean we can implement Flutter plugins in C# and use from plugins any APIs, SDKs and NuGet packages available to UWP apps?

@kinex I am curious to know why you would think the two related. Adding .net support for plugins would be relatively straight forward, and wouldn't require UWP. It is kind of out of scope for flutter though.

@JakeSays From my understanding the execution environment (UWP in this case) defines how the plugins are created and what is available to plugins. So maybe the answer to my question is "of course", but I am not fully sure.

In Android plugins you can use Kotlin (or Java) and any Android APIs, SDKs and packages. In iOS plugins you can use Swift (or Objective-C) and any iOS APIs, SDKs and Pods. I would expect same with UWP and it would make this really awesome.

Making it easier to use C# in plugins is something we intend to do, but is orthogonal to UWP support.

A UWP runner would mean being able to use UWP-specific APIs in plugins, but my understanding is that very few APIs are actually UWP-specific (e.g., per this documentation "The general rule is that a desktop app can call a Universal Windows Platform (UWP) API.")

@stuartmorgan That isn't actually true. Eventually with project reunion that WILL be true, but it isn't right now and even then it's for legacy software, not new apps as would be the case with flutter. There is a massive amount of stuff you can't do without UWP (i.e. accessing the plugins for various video codecs, the DRM video player, etc) still which is why I've always had an issue with the approach the flutter team is taking. There is 0 operating systems supported by Microsoft (and thus secure) that can't run UWP on the market (i.e. targeting Windows 7 is ridiculous and shouldn't be a goal of Flutter, only Windows 10 should be a target). Thus, there is 0 reasons why this shouldn't be native UWP from day one.

Worse, all Windows 10 S and variants CAN'T run win32 apps so flutter will be locked out from those. They will also be locked out from ARM/ARM64 devices too unless they run on UWP and Windows X that runs win32 apps in a docker container using Remote Desktop will have a significantly worse experience than native UWP apps as a result, especially when it comes to graphics performance.

So if google/flutter were forward thinking with Windows support it would entirely be UWP from day one which allows C++ and .NET (the vast majority of Windows devs use .net, not C++) AND supports all current AND future windows devices with the best possible interactivity. The current win32 approach is both short sighted and poorly researched (which indicates a really huge blindspot within Google which is concerning given the billion+ devices that run windows).

Given that Skia is already running on UWP there is very little reason why this wouldn't be the defacto environment and the focus of 100% of google's efforts on Windows. (and really, working with Microsoft to get the entire Xamarin remote simulators and direct deploy to iOS devices on Windows working too)

@JohnGalt1717 You've made this argument several times in this issue already; repeating it is not constructive. If you want to accelerate the development of UWP support, you are welcome to contribute to it.

@stuartmorgan I'd be curious to know your thoughts on using c#. I have some ideas on how to make that work.

@kinex actually flutter plugins are essentially just C code that interacts with flutter via a simple api. To write them in C# would basically require a ".net plugin" written in C that would host the CLR and bridge the flutter world and c#. Theoretically it would be possible to write flutter plugins in java on windows, or any language as long as the language environment can run on the target operating system.

@JakeSays I filed https://github.com/flutter/flutter/issues/64958 with my current thoughts on C#, since I had apparently never filed it here. Anyone interested in C# specifically should follow that issue.

@JakeSays Ok thanks for the clarification. Without better knowledge I assumed something like this: C# plugins (maybe implemented as .NET libraries?) would be loaded by the UWP runner and the Dart code could call them via the UWP runner process. In this imaginary architecture those C# plugins could access the same APIs, SDKs and NuGet packages as any .NET library hosted by an UWP app.

Anyway, good to know there are plans regarding C# support. I believe there will be more plugin authors (=more plugins faster) and more stable plugins if C# can be used instead of C++.

@kinex you're right in that c# plugins would have access to the full .net set of libraries, as well as nuget packages. When the c# code is executed it's running in a full .net environment (or .net core as the case may be).

FFI is a far more lightweight solution for plugins. See https://pub.dev/packages/win32, for instance. But this is far off-topic for an issue that is ostensibly about building a UWP-based runner.

@timsneath I think ffi and plugins solve two different problems. iirc there are a lot of limitations with what you can do with ffi (for instance it's synchronous).

Again, I've filed #64958 for C# plugins; please continue any discussion that's about C# but not UWP there.

nice stuff going on
somebody should tell Microsoft to contribute here too

@airbus5717 what do you mean? Microsoft contributes to the discussion here all the time.

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: