Update on WinAppDriver

[kat-y]

Thank you all for your patience, we hear your frustration at the lack of updates on the future of WinAppDriver. In November 2020 we mentioned that development would be paused for at least 6 months. We don’t have a timeframe of when the level of resourcing for WinAppDriver will change as our team is currently focusing on making a great platform for the future of Windows 11 apps – when there is confidence in a timeframe, we’ll definitely share it with you.

We are committed to bringing critical improvements for WinAppDriver to keep pace with other developments in the platform, so it can continue to be used alongside our other advancing technologies. One such improvement is ARM64 support in WinAppDriver v1.3 to ensure alignment with the Windows App SDK. Please feel free to contact me with any further questions or concerns!

[pradeipp]

Hi @kat-y Thank you for the updates, this really helps boost our morale and continue using WinAppDriver. Here are my questions:

1. Any updates on whether the project might go open source? or any intentions to?
2. The new build is expected to have issues(due to the shift to .net 5 and also the new platform-specific builds) so how are you planning the testing? I believe @DHowett is the sole resource in WinAppDriver at the moment...
3. And I believe there won't be a hard 6 months gap this time?

Thanks once again and hope to see frequent updates. Cheers 😊

[mrlacey]

our team is currently focusing on making a great platform for the future of Windows 11 apps

I hope we can look forward to a time when the team displays an interest in helping developers ensure their Windows 11 apps are well tested too.

[fforjan]

@kat-y there is simple PR pending from the community like #1539 or #1058

Although I understand you do not want to work heavily on this, could you open and accept some community items like the one previously set ?

[Wolfe1]

@fforjan @kat-y Agreed, at least the PR section should be looked at for now in order to capture any effort the community has done to improve documentation and such.

I have been trying to get some samples added for RobotFramework for over a year now #1148

[SnowISmirnov]

Please have a look to #1556. It is not possible to launch new version of WinAppDriver with Appium

[steffen-wilke]

If only I had a penny for every great developer tool that has been stalled due to "more pressing features" 😄. Looking forward to more updates on this repository hope this gets some priority and the community contributions are processed.

[liljohnak]

@DHowett @kat-y This seems like it needs to be adressed.
Please evaluate: #1610

[Wolfe1]

Agreed #1610 needs to be a top priority in order to stay in line with latest Appium.

[andrisi]

@kat-y this explanation (after 6 months) and the previous ones sound like coming from a cash strapped early stage startup, not a billion dollar company. FFS, hire a few developers and get things moving, this is a critical piece of software! Have a look at the great progress, documentation & perfect developer-relations at the https://playwright.dev/ team, also at Microsoft. When you abandon software like this you make developers disillusioned with native Windows apps, and thus moving to develop using other tools. Remember this: https://www.youtube.com/watch?v=Vhh_GeBPOhs

[andrisi]

FYI: microsoft/playwright#10291 - perhaps the two teams could join forces?

[LYDE1234]

@kat-y Hi Katy - my company is considering a move to Selenium w/WinAppDriver for desktop testing. We're of course interested in the long term viability of WinAppDriver and need a clear picture of what the situation current and future is. Any way of getting in touch with you directly? feel free to mail me at lay at milestone.dk

[liljohnak]

@kat-y @DHowett This is odd and has caused some confusion. Perhaps it can be added to your plans. Using Selenium in msedgedriver.exe .FindElementsByXPath("*") can be used to find children elements but, here the equivalent syntax is .FindElementsByXPath("*/*").
#669 (comment)

[anunay1]

@kat-y Any update when can we expect the open issues to be addressed.

[ChristoWolf]

Hi @kat-y!

I'm bumping this again to check on the current state of the project.

If there are insufficient resources on your team or even in any case, it would be great if the source for WinAppDriver itself would be made public so that the community can start maintaining the project.

Edit: Maybe I should give a few reasons why maintaining this project is important for many consumers:

• WinAppDriver is largely satisfying the W3C WebDriver standards and thus may be used similarly to other WebDrivers (e.g. the various Selenium WebDrivers and Appium).
• This also means that it is easily possible to provide API wrappers which are platform and WebDriver independent due to API agnosticism.
• WinAppDriver is officially supported as a relay in Selenium Grid 4.
• This means that Selenium Grid 4 can be used to easily distribute and parallelize Windows desktop application UI tests.
• As the official MSDN doc states, Coded UI Test is deprecated and WinAppDriver should be used instead.

[jozefizso]

We are Visual Studio Enterprise subscription customers. The Coded UI Tests functionality was discontinued for the benefit of using Appium and WinAppDriver.

So we are currently stuck with a project where we cannot even know if it ever will be developed in the future?

[andrisi]

FYI: I wrote to about 4-5 main committers of this repo at MS asking for an update. Two of those bounce.

Update: no one answered.

[DLightstone]

When, if at all, will the source code be made public?
Clearly Microsoft is not addressing issues presented in this status update thread.

[zannett]

Any update as to when any focus will be put back on enhancing the WinAppDriver, resolving existing issues, or making this an open source project?

[Wolfe1]

[zannett]

[aronweiler]

I would like to pile on here and ask what, if anything, is going to be the automated testing solution for Windows UI applications now that CodedUI is deprecated, and it appears that WinAppDriver is no longer being supported.

Microsoft leaving people high and dry here...

[ChristoWolf]

It would be so easy if WinAppDriver itself were open source.
@kat-y: You mentioned some time ago that you guys were looking into open sourcing the code, are there any news regarding this, or an ETA?

[PandaMagnus]

I would like to pile on here and ask what, if anything, is going to be the automated testing solution for Windows UI applications now that CodedUI is deprecated, and it appears that WinAppDriver is no longer being supported.

Microsoft leaving people high and dry here...

FlaUI? I've used it very briefly in the past and seems to be a decent alternative. IIRC it's also open source.

I suppose there's always direct UIA coding, but I definitely missed some of the niceties from WAD and FlAUI.

[aronweiler]

I find it interesting that MS seems to have abandoned this, because it fits very well with the AI initiatives that they are so deeply involved in. For instance, you could hook up tool calls allowing an LLM to easily use Windows applications without the inconsistency of integrating a vision component.

[ChristoWolf]

@aronweiler I don't really see a connection.
Also, there are several major problems with your idea:

• Any ML algorithm only works (i.e correctly labels) with a certain probability.
  Introducing flakiness just to make it fancy is not the best idea.
• Not sure which problems a large language model would solve.
• The purpose of WinAppDriver is to be W3C WebDriver compliant (at least partially), not to tackle arbitrary UI automation problems.

[aronweiler]

@ChristoWolf have to disagree with all of your points-

• While it is true that machine learning algorithms, including LLMs, can introduce a level of uncertainty due to their probabilistic nature, this does not inherently make them unsuitable for use with WinAppDriver. In fact, LLMs can be used to enhance the capabilities of WinAppDriver by providing natural language processing for complex automation tasks, interpreting user intentions, and generating robust automation scripts. The key is to use LLMs in a way that complements the deterministic nature of WinAppDriver, such as generating XPath selectors or assisting in the creation of test cases (I'm already doing this to great effect).

• WinAppDriver's primary purpose may have been to provide a Windows application automation interface that complies with the W3C WebDriver standard, however this does not preclude its use with additional tools like LLMs. By integrating an LLM, you can streamline the test development process, automatically generate test cases based on natural language descriptions, and even provide intelligent suggestions for test improvements. This doesn't change the core functionality of WinAppDriver but rather extend its utility.

• WinAppDriver may have been designed to work with predefined UI automation tasks, but the integration of an LLM could allow for a more dynamic approach to UI automation. For example, an LLM could understand the context of a UI and generate appropriate automation commands for WinAppDriver, drastically reducing the manual effort required to script complex interactions.

Overall, WinAppDriver + LLM seems to be winning combo, especially for test automation... if MS was interested.

[ChristoWolf]

@aronweiler ok so you are saying that my points are wrong because you would like LLM functionality?

Look, I think LLMs have great use cases, but a WebDriver server implementation is not it.
I think your ideas are absolutely sound, but should be part of a dedicated API and not WinAppDriver.

In any case, Microsoft has abandoned this project, so there will never be any such extensions to this implementation.
IMO the best we can do is to combine forces and try to get somebody to notice this issue and at least communicate with us.

[daluu]

I find it interesting that MS seems to have abandoned this, because it fits very well with the AI initiatives that they are so deeply involved in. For instance, you could hook up tool calls allowing an LLM to easily use Windows applications without the inconsistency of integrating a vision component.

Overall, WinAppDriver + LLM seems to be winning combo, especially for test automation... if MS was interested.

That might be a matter of business goals and priority. AI can span many areas, in the testing space, we have niche 3rd party players that have AI based automation tools. I'm guessing MS doesn't think it is worth the time to compete there. They focus on AI for other uses. If anything, they could just acquire those other niche companies and build upon them.

Things might be different if say Google or Apple took on AI for test tooling (Android test automation, XCode/iOS/macOS test automation, AI for SafariDriver, AI for ChromeDriver, etc.). Then I would think that would get MS's attention. If I'm not mistaken, I don't think Google nor Apple have taken on AI/LLM for their test tooling, at least with respect to WebDriver integration, have they? If one is interested in this area for AI, maybe ask around those company's user/dev communities to see if we can spawn some traction.

[eykh]

I guess it's time to ask the question again: what are people using in place of WinAppDriver?

Ranorex, TestComplete, FlaUI, etc.

After wasting LOTS of time (=money) with CodedUI and WinAppDriver and their stability issues, we went with Smartbear TestLeft. Rock solid, easy to use. The client nuget package still requires the "old" .NET Framework, which is the only annoyance.

Everything nicely integrated in CI/CD of course.

[AnatolyRyzhakov]

Another comment to pay your ATTENTION
@kat-y , please, share the latest news about WinAppDriver
People still waiting for

[ChristoWolf]

We know that this works, but it's a work-around for the fact that WinAppDriver has not seen any development for several years.

Also, I'm pretty sure that the Appium people will at some point stop implementing such compatibility bridges because it is not their responsibility to do so.

[aristotelos]

I have started writing a WebDriver2 implementation on top of FlaUI which might be interesting if somebody is looking for an alternative. It is still open for review: FlaUI/FlaUI#594

[james1301]

I've just seen this blog post: https://devblogs.microsoft.com/dotnet/dotnet-maui-ui-testing-appium/. That talks of using WinAppDriver for MAUI apps 🤔.

I've added a comment to reference this issue and the lack of any Microsoft support. Maybe if everybody else could as well, it may help get some feedback.

[aristotelos]

I have started writing a WebDriver2 implementation on top of FlaUI which might be interesting if somebody is looking for an alternative. It is still open for review: FlaUI/FlaUI#594

Update: This has moved to a separate repo, https://github.com/FlaUI/FlaUI.WebDriver. See https://github.com/FlaUI/FlaUI.WebDriver/releases.

[daluu]

I've just seen this blog post: https://devblogs.microsoft.com/dotnet/dotnet-maui-ui-testing-appium/. That talks of using WinAppDriver for MAUI apps 🤔.

I've added a comment to reference this issue and the lack of any Microsoft support. Maybe if everybody else could as well, it may help get some feedback.

Good to know about this blog post. In the current comment exchange there, nice to see that the referenced WinAppDriver version (1.2.1) still works for the use case of that blog post. But unfortunate to hear the response of the blog author:

I can understand that that is not a good look. However, when using the version specified, all seems to work fine for what we’ve been using it for in the .NET MAUI codebase. Besides it not being updated and not looking maintained, is there anything specific you have a problem with?

Sounds like the blog author just cares for his use case only, and if it works for him, then it's "good enough" and no need to worry about other use cases where things might not work.

[a-einstein]

Note there is not even a real version 1.3, just a Release Candidate 1.2.99.
Since 2021...

[alatriste1982]

Come on MS, any update on this one?

[ajsuydam]

@kat-y can we get any sort of update on this? need some sort of functioning driver.

[anunay1]

@kat-y Are you still with MS?

[ChristoWolf]

This is obviously abandoned, sad as it is.
I recommend to instead use FlaUI or their FalUI.WebDriver.

[jonathangiber]

Hi everyone,
Im using FlaUI with java, Im able to initialize a session and even use Actions class with FlaUI driver for using the keyboard and mouse.
But when trying to actually use the driver to find elements there is no success, I always get some kind of error.
Will appreciate any help, can be contacted at [email protected] or by linkedin https://www.linkedin.com/in/jonathan-giber-0747b071/

Thanks!

[igorrecioh]

Hi everyone,
Im using FlaUI with java, Im able to initialize a session and even use Actions class with FlaUI driver for using the keyboard and mouse.
But when trying to actually use the driver to find elements there is no success, I always get some kind of error.
Will appreciate any help, can be contacted at [email protected] or by linkedin https://www.linkedin.com/in/jonathan-giber-0747b071/

Thanks!

Hi @jonathangiber,

It would be better to address your issue in FlaUI repo so that anyone can help you.

Regards,

Igor

[HowTurnRight]

FlaUI is also going to be abandoned soon (even before its going to be fully implemented). Right now FlaUI is not completed and nothing is happening in this project since may.

[eykh]

I'm definitely not related to Smartbear. But we were so sick of these CodedUI and WinAppDriver issues, we finally switched to TestLeft. It just works.
It has its price, but it saves us so much money.

[daluu]

FlaUI is also going to be abandoned soon (even before its going to be fully implemented). Right now FlaUI is not completed and nothing is happening in this project since may.

where did you hear this news? I was not aware, I don't see mentions on the github repos about it being deprecated/abandoned/archived.

But it is true that the WebDriver integration for FlaUI is currently "experimental", so it's not without bugs. But I believe the source code is there? If so, the community is welcome to help take over and fix or complete what's missing.

[aristotelos]

FlaUI is also going to be abandoned soon (even before its going to be fully implemented). Right now FlaUI is not completed and nothing is happening in this project since may.

As the primary author of FlaUI.WebDriver, I can confirm that FlaUI.WebDriver is not "abandoned" (I don't know about FlaUI itself but did not hear any news about that too).

I agree that development on FlaUI is not very active but it has a great and quite up-to-date technology stack and it is open source. So I would encourage anyone to evaluate it and contribute to it.

[mykola-mokhnach]

Thank you for commenting this thread @aristotelos

We (the Appium team) would also be happy to incorporate any webdriver-compatible server to replace WAD, FlaUI included. We have been also actively looking for a person who could help with further maintenance, triage, and development/bugfixes for the replaced server part. Unfortunately we observed zero interest in that from the community. Basically, many people would like to use this free instrument to automate their tests, but very few (if any) would like to contribute back 🤷

[liljohnak]

@mykola-mokhnach where to contribute to windows desktop applications? There is value in contributing because my test code will continue to work in the next framework.

[mykola-mokhnach]

@liljohnak

where to contribute to windows desktop applications

sorry, I maybe did not express it properly. I mean contributing to open-source alternative WAD implementations built on top of W3C webdriver interface, for example FlaUI, which is mentioned above, or https://github.com/imsardine/winappdriver or https://github.com/kfrajtak/WinAppDriver or https://github.com/licanhua/YWinAppDriver

[daluu]

We (the Appium team) [...] have been also actively looking for a person who could help with further maintenance, triage, and development/bugfixes for the replaced server part. Unfortunately we observed zero interest in that from the community. Basically, many people would like to use this free instrument to automate their tests, but very few (if any) would like to contribute back 🤷

That kind of dedication for a single person / lead / point of contact, to take on I assume is a lot of responsibility and extra personal time for this kind of work/maintenance. Unless there happens to be some corporate/employer sponsorship for the work. Someone that would want to take on that role without sponsorship must really be passionate about the project/software or the field of work / industry.

For occasional, intermittent, contributions from anyone in the community, that I can see is easier for one to be a contributor.

On a quirky side note, it would be nice if MS could sponsor whoever helps (as maintainer) with replacing WAD integration with Appium. Given WAD seems abandoned, this could be a nice way for them to give back to the community. More helpful or better for sponsorship if the person happens to be from MS as well.

[jonathangiber]

I successfully upgraded to selenium 4 replacing winappdriver to FlaUI web driver (https://github.com/FlaUI/FlaUI.WebDriver) thanks to @aristotelos for adding all the necessary capabilities

[ChristoWolf]

@jonathangiber sounds great, I'll also do the switch soon!