☂ Add support for UWP

[steskalja]

Latest status: We have decided to not support UWP, as discussed in https://github.com/flutter/flutter/issues/14967#issuecomment-1085490495.

---

Is there any plan to add support for Windows 10/UWP? The reason I ask this is because there are almost 1billion windows 10 devices on the internet now and more that are not even on the internet.

[psled]

Probably not for now, see #10881.

[ivanmestre]

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

[webprofusion-chrisc]

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

[emsaints]

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

[charafau]

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:

[amartens181]

Man... I want real xplat :)

[avorib]

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.

[ghost]

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

[stuartmorgan]

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.

[stuartmorgan]

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.

[JohnGalt1717]

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.

[stuartmorgan]

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.

[JohnGalt1717]

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)

[stuartmorgan]

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

[Kapranov98]

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.

[JakeSays]

@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

[JakeSays]

@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.

[clarkezone]

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

[stuartmorgan]

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.

[nerocui]

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?

[JakeSays]

@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.

[nerocui]

@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.

[JakeSays]

@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.

[nerocui]

@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?

[JakeSays]

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

[kunit1]

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.

[JohnGalt1717]

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.

[stuartmorgan]

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.

[JakeSays]

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

[JohnGalt1717]

@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)

[JakeSays]

@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.

[JohnGalt1717]

@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.

[JohnGalt1717]

@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]

@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.

[JakeSays]

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

[dnfield]

@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

[JohnGalt1717]

@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.

[orestesgaolin]

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.

[clarkezone]

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).

[orestesgaolin]

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.

[clarkezone]

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

[lukaszciastko]

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.

[clarkezone]

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

[daniele777]

PLease add Windows Store !!!!

[clarkezone]

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

[daniele777]

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

[clarkezone]

@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.

[daniele777]

all right all the best!

[nerocui]

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.

[dnfield]

@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)?