 I want to welcome everyone to APM Conf. This is the third edition of the APM Conf. This year we are doing it virtually, but I hope everyone has the same rich experience of APM Conf like they've always had before. We have a fantastic program. Some really compelling talks. I've got people emailing and complaining that there are like three talks that are all I want to attend. How do I choose between one? That's a good problem to have. And so, yeah, I'm hoping everyone will have a great experience. I want to kickstart the conference by introducing the lead of the APM project, Jonathan, who has been the center of the gravity at least for this project. And doing some really cool work, especially with the 2.0 that's coming up. And I'm sure in his talk, he's going to give a glimpse of what is coming and get into some interesting peaks inside what's happening, which is this whole keynote about. So over to you, Jonathan. Thanks again for being the person driving this whole thing. Thank you so much. Absolutely in a rush. Thank you for that warm introduction and thank you on behalf of myself and everyone here for being the kind of leader of the organization of this event. I was really happy that you approached us to do this and so let's let's kick it off. I'll go ahead and share my screen. So, yeah, welcome to APM comp 2021. This is the third official APM conference that we've had. The first was in London, and the second in Bangalore, and now everywhere, I suppose, still sort of an Indian time zone, but people from all over the world. Zooming in from wherever we happen to be I'm in Vancouver, Canada right now. This, this talk is supposed to be a kind of what's going on with the project State of the Union type talk. It's going to be largely about APM 2.0 because that is our main focus as a as a project right now, and you've heard me talking about it for a long time, and we are very close to releasing it. And, and burst the bubble of anticipation. I'm not going to say that it's released as of this keynote that was kind of my original hope. But like all deadlines. This one just came up a little too quickly. So anyway, in case this is the first time that we're meeting one another. I wear a couple different hats. Figuratively, I only wear one hat, literally it's the one that I'm wearing right now and also in this picture. I just get stuck on my head, I guess. So I am one of the maintainers of the APM project. There's lots of other maintainers will not a lot. There's a few other maintainers. We all do, you know, put a lot of effort and work into this project and are super grateful for the contribution of everyone who contributes. I work for a company called headspin. That spins a, you know, device cloud that is built around apium and gives you lots of other stuff to go along with your apium tests at headspin. I also lead something called headspin university where in the last year I've released a pretty massive e-learning course designed to get you, you know, certified on apium and selenium. So that's something you could check out. And I also maintain a blog and newsletter called apium pro with lots of apium tips and tutorials and things like that. And increasingly some more application based stuff as well, which we'll see a little bit about later. So on to the apium 2.0 report. The first thing that we want to remind ourselves of is apium's overall vision, right? Hopefully apium 2.0 is a step forward in apium's overall vision. That's kind of what our intent is for it. It's not just, oh, well, we decided that it's time to go from one to two. I mean, why would we? We've been at one for like seven or eight years. So we obviously weren't in any hurry to get to two. But again, just a reminder, the vision of the apium project is if we could say it in just, I don't know how many words these are, five words, that we want apium to be a web driver compatible automation tool for everything, for every platform, right? We believe in the possibility and the vision of web driver as an automation technology and what it did for web browser automation. And we think that can be expanded and applied to everything. Obviously not always straightforwardly, but in some way or another. And I won't go into all the kind of reasons for this vision and the benefits of it because I've talked a lot about that in previous keynotes like this at the last apium conference, which you can look up on YouTube if you want. So if we want to talk about what apium 2.0 is in a little bit more detail from a perspective of sort of what some of the problems were with apium 1 and what some of the solutions are that apium 2.0 can bring, we hope. We could say that one of the first problems that we encounter with apium 1.x is that the drivers that we were using to support automation on different platforms kept sort of diverging not necessarily in terms of their features, but in terms of their development cycles, right? So we have these different drivers for apium that you've used. If you've used apium, the XC UI test driver, which lets you automate iOS applications. The UI Automator 2 driver or the Espresso driver, which allow you to automate Android applications. There's a host of other drivers that exist that you might have used. The Mac driver, the Windows driver, UITV driver, you know, there's a bunch of these other drivers that are out there that you might have used from time to time. Each of these drivers are sort of developed kind of in their own line of development. It just makes sense because, you know, iOS has its own thing. It's different from Android. It's not like Apple and Google get together and decide, okay, on this day, we're going to release the same feature to both of our platforms. So these drivers deal with different technologies and develop at different paces. With apium 1, that was a problem because all of the drivers were combined essentially into one project and it made it hard to parse out and distinguish types of changes from driver to driver. So with apium 2.0, we've taken the step to kind of enforce that each driver is its own independent entity with its own, you know, GitHub repo or, you know, package or whatever it is. But apium is going to help you manage those different independent entities. They won't all be kind of conglomerated into apium anymore, but apium will make it easy for you to manage them. And that's part of what apium 2.0 hopes to do. Another problem with the way things were before is that we kept finding more and more platforms that we wanted apium to support. And there's way more platforms that we wanted to support than people we had to support it. We have a pretty small core team. You know, a lot of folks that use apium aren't necessarily, you know, that excited about contributing to apium itself, or maybe the skills involved are just a bit different than what they use day to day. So apium is written in JavaScript and if you're a, I don't know, a Java based S debt or something, it might be a little formidable to think about hacking on the apium code base itself. So one things we wanted to do in apium 2.0 is to make it easy for us as the core team or for you or for anyone to write and share apium drivers because we know that we can't support all the platforms that are out there. But together the whole world we can write. We just need a few people who know about these other platforms to write drivers for them and apium 2.0 is going to make it easy for you to share those drivers and for others to consume them. That's what we call the driver ecosystem. We're also developing something called the plugin ecosystem. And the idea behind plugins is basically that we kept on seeing that people were coming up with these really interesting ideas for features to add to apium ways to integrate apium with other technologies or ways to extend apium for kind of, you know, niche use cases, maybe not use cases that everyone would need or not in all cases, still, you know, very useful and valid, but we kept on feeling a tension of whether or not we wanted to put these features into apium, because then we'd have to maintain them. And they might be useful, but they might not be globally useful. So we had this problem. And so we decided to create a plugin system for apium that makes it easy for anyone to write and share plugins that can extend apium as behavior or modify the way apium responds to commands or integrate with other technologies. The sky is really the limit when it comes to creating plugins. And of course this whole plugin ecosystem is going to be managed the same way as the driver ecosystem and apium 2.0. So I have some examples of plugins and drivers down the road here. So if you're a little confused about specifically what this means, we'll see some some examples. Another big problem with apium as it stood was that the documentation was quite frankly bad at one point it was quite good but you know documentation often drifts from reality. And our information architecture was problematic partially because of the whole divergent driver development problem we've already talked about. So with apium 2.0 we're also exploring ways to better delineate documentation responsibilities with drivers becoming their own sort of entities that makes it a lot easier for a specific drivers to host their own documentation. So we know that the main apium documentation isn't cluttered with information that's only relevant to one particular driver it might be confusing to people who are coming, you know wanting to automate another platform. That's just one sort of example of ways that we're trying to improve the documentation. And this is, in fact, a lot of the work that that remains before we release apium 2.0. So kind of from a development perspective, there's a lot of stuff that's accrued over the years inside of apium. And there are some things that we didn't really want to get rid of because we didn't want to make breaking changes. But at the time has come to get rid of some of those things and make some breaking changes. So we'll be removing support for older incompatible drivers, some old methods and some old capabilities and things like that. So in terms of new features for apium 2.0 it's basically what we talked about in the previous slide, there's going to be this driver ecosystem where you know drivers can now follow their own independent development have their own independent versioning systems. And you can, you know, upgrade a driver that you use without necessarily having to upgrade the apium server at the same time, giving you a lot more flexibility, you could, you know, have a certain version of the XEI test server and choose to keep that version pinned while still incrementing and upgrading versions of your UI Automator 2 driver, if that's the way you want to do it just like we're used to with dependency management in general. So it's just going to be a lot more of a sane situation. So in terms of the ecosystem, we're releasing code libraries that make it very easy for third parties, by which I mean, you know, you to create and distribute drivers that that you want to experiment with. So last, well night for me morning for those of you in India. We have a workshop where we built a driver and some plugins in real time over the course of the workshop. And so we're starting to develop, you know, the appropriate way to document and train people on how to build their own drivers which I'm super super excited about, and we got great feedback from the workshop. And I'm sure we'll be running more workshops like that in the future because I really want everybody who has an interest and the, you know, the development capacity to be creating drivers. And the same is true of the plugin ecosystem right this is the other aspect of Appium 2.0 that's kind of a big new feature, the ability to write your own code and plug it into Appium and have it modify the way that the Appium server works or the way that certain commands are handled. And it's basically up to you what you want to do it's extremely powerful. And if you know the whole thing about great power and great responsibility definitely applies here so very excited about that, just like with the driver ecosystem, we're distributing code libraries that will make it easy for you to write, you know, the minimal amount of code that you need to do to describe changes in the way Appium works and that can get plugged right into Appium without you having to write a whole ton of boilerplate code. And of course, you don't just have to use one plugin at a time. You know, there's, I don't know how many plugins right now that you can choose from, maybe about 10 or so. And I'm hoping that as the years go by that number will increase to you know the hundreds, as people come up with new and interesting use cases. So you'll be able to kind of search from this library of plugins and pull in the plugins that you might find useful for your particular automation needs. So, that's kind of an overview of Appium 2.0. You might be wondering, okay, sounds great. How do I use it. I've only been using, you know, Appium 1.21 or whatever. I just have one slide here on this because it's obviously a little too much to go into in this kind of, you know, keynote style talk. That would be more like a workshop thing. But it's very easy to install Appium 2.0. You just npm install Appium. You just want it right now you want to use the next tag, because it's not the official release yet. So I'm going to give you the latest version of Appium 2.0, which I think is beta 17 or 18 at this point. Then you can use the driver management tools that come with Appium to install some drivers. So if you want to install the standard drivers that you might use for iOS and Android, you can run these commands that you see here Appium driver to install and then the name of a supported driver. And this command line interface is pretty complicated and has lots of options. So you can always check out the guide that I wrote on Appium Pro to the driver command line interface to figure out what all those other options are. One of the other important things you'll need to do when creating sessions with Appium 2.0 is to make sure that your Appium client is sending capabilities that are W3C compatible, meaning they have to have the Appium vendor prefix in front of them if they're not a W3C standard capability. Now, you might be in a position of using one of the updated Appium clients already, like the most recent Python client or something like that. And in that case, you don't even have to worry about this because the Appium client will automatically add these prefixes for you. But this is going to be a breaking change in the Appium server. We're not going to accept non-standard capabilities moving forward. So you either need to standardize them yourself or rely on the client to do that for you. And if you want to do some, let's say, some image element finding or image comparison, you might want to install the images plugin. That functionality has now been moved to a plugin. Or if you want Appium to turn into a device farm for you and manage, you know, a fleet of emulators or real devices or simulators, you can install this plugin that Cy and Srinni wrote, which basically adds a special web server to your Appium server that lets you, you know, connect and manage devices and run multiple tests at a time on different devices and things like that. Really, really cool project. But for more details, I definitely recommend reading this migration guide that we're working on. It's a kind of work in progress. So keep an eye on this. You might want to watch it on GitHub, because this is going to contain the list of all the breaking changes and things that you might need to do to update your tests or your CI workflow to make sure that Appium 2.0 continues to work for you. Okay. Of course, in addition to, you know, getting your server set up and making sure your test code is up to date for Appium 2.0, you might also want to continue using Appium desktop. And in the past, Appium desktop was a single application that you could download, and it would have a server like you see on the left that you could start, and it would have an inspector, which allowed you to inspect your applications. Both of these still exist, but we recently decided to split them into two separate applications. There are a number of reasons that we did this, which I'm not going to go into here. But basically all you need to know is that if you want to use these apps, you just have to go to the right place to download them. If you want the Appium desktop server, you go to the same place you always have on GitHub. And if you want to use the inspector, now you need to go to a different GitHub repo. It's called Appium-Inspector in the Appium organization. And that's where development on the inspector is happening moving forward. I also recently gave a webinar, which I think you can find online, which announced that the inspector is actually now also available as a web application. So an example of how it's hosted is up at the Appium Pro website. So if you go to inspector.appiumpro.com, you don't need to download anything. You've just got a full-blown inspector. And to use this, you need to start your Appium server with a special flag, which is documented in the readme, but otherwise it works exactly the same as the inspector that you would download. And it doesn't cost you hundreds of megabytes of bandwidth or take 10 to 20 seconds to load. It's just here. It's just a webpage. You can even have multiple tabs open with multiple inspector sessions at the same time, which I think is pretty awesome. So definitely give that a look. And now let's explore some of the examples of Appium 2.0 drivers and plugins right now that are in different states of development. And so I'm listing them out just to kind of give you a flavor of what's coming or what could be coming. And I'm not listing these because they are official in any way. Some of them aren't. Some of them are just things that I've been working on or that others have been working on out of interest. It's designed to kind of inspire you to think of, oh, well, what could I create? Or what might my company need or how might my company be able to use this Appium 2.0 architecture profitably for us and for our customers? I know there's even one or two talks at this conference which go into how folks are creating Appium 2.0 drivers or plugins and the process that they went through and the benefits that they're experiencing. So I'm really looking forward to those talks particularly because this whole idea was basically designed to create a platform for others to be creative with. And so I'm excited to see what that creativity comes up with. All right, so let's look at some of the new drivers that I'm aware of. They're probably more that I'm not aware of or some that I've forgotten. One of them is a driver that I've been working on at Headspin, which we recently open sourced. It's a driver for the Roku TV platform. You can test your Roku developer channels using this Appium driver. I would say that the status is pretty early. So it's, you know, it's not full featured yet. But there's another another guy who's helping contribute on this project and we're going to hopefully get a new version of it released on NPM here pretty soon. So that one's in beta. At Headspin, I've also been working on a driver for another TV platform called Tizen, which is more than a TV platform. It's kind of Samsung's operating system. But this driver is specifically for web application that run on Samsung TVs. And I just need to put a few more touches on the Readme before I open source it and make it available, but it's going to be public pretty soon at this URL. So keep an eye on that. I've also been doing some work on trying to create a driver for Chrome OS or Chromebooks. So the Chromebook device and the Chrome operating system that runs on it. I think we have a path forward here for automating applications, especially the web based applications that run on Chrome OS. And finally, I've also been doing some R&D on creating a driver for the KaiOS feature phone platform. So KaiOS is a kind of lightweight operating system that runs on on feature phones that are a little bit more affordable than the smart phones that we're trying to develop right now. So it's a pretty growing market in a lot of the world. And there's a lot of apps that are being developed for this. So at Headspin, we're pretty interested in allowing KaiOS developers to test their apps using Appium. So there's not really anything to open source for this stuff yet, but the intent is to open source all the work that's happening on these platforms. So if you want to be a part of that, you know, hit me up on Twitter or something like that. And we can talk about that when we're ready to move out of the R&D phase into actual development. All right, now let's talk about some plugins that you can go check out. One of the plugins already mentioned is the images plugin. This is actually a set of features that used to be an Appium 1.x as part of the core server. But because they have some pretty gnarly dependencies, we decided to move them into their own plugin. So the repo is there at that link. And you can use the Appium plugin command line interface to install this plugin. It works pretty well. There's also this device farm plugin, not to be confused with the device farm product. It's just the generic name referring to, you know, a set of devices that you have available. This is developed by Cyan Srinni and you can find more details at this URL. They've got some pretty fun screenshots there, so I definitely recommend checking that out. Another one that they've been working on is a gestures plugin that takes some of the common gestures that you might need in an Appium mobile test like swipe and pinch and zoom and stuff like that. And it takes away the hard work of having to build W3C action commands to implement those plugins and instead just gives you a nice server endpoint to call. Sorry not to implement those plugins to implement those actions. And it gives you a nice server endpoint to call for that from your client instead of having to, you know, reverse engineer all of that behavior. There's another plugin I wrote that basically tries to unify the document type definitions for both iOS and Android page source. This is kind of an experimental thing. I'm not sure if it's ever going to be particularly useful, but I think it's a good example of a plugin that's pretty simple that you could read the code and probably understand what's going on. And just kind of takes what's happening in the iOS world and the Android world and makes them a little bit more similar, which might make it easy if you're doing cross platform testing. It's also another very simple plugin, which basically takes Appium's requirement for W3C standard capabilities and undoes that requirement. So I don't recommend using this plugin, but if you for whatever reason aren't in a position to update all of your test capabilities with appropriate W3C style capabilities, you could just install this plugin to the Appium server and it will relax that rule for you. And there's another one I'm going to talk about a little later, but I won't talk about it now. Alright, so another thing that's important to talk about is what's happening with Appium 1.x now that 2.0 has been in beta for a long time and is around the corner in terms of its release. So we have published a plan for what's going to happen with Appium 1.x. I recommend reading this guide to it. It's full. Some very important information in there, but I can summarize it here for you. Basically, we're no longer working on the Appium 1.x server and here I'm distinguishing the Appium server from Appium drivers. So when I say server, I mean stuff that's like not the XC UI test driver, not the UI Automator 2 driver, but kind of Appium's internal mechanisms and things like that. We'll still be making updates for a while to the drivers like the XC UI test driver and UI Automator 2 driver to make sure that if iOS releases a new platform, we're going to try and support it and so on. But in terms of features for the Appium 1.x server, we're done with that for good now. If you find any significant bugs in the 1.x server that need to be patched, we'll also work on patching those for basically the next six months. And like I said, we'll continue making platform related updates or bug fixes and so on to the 1.x drivers for the next six months. But basically all of the development work that we care about is happening on Appium 2.x. And that doesn't mean that, like I said, the drivers are going to be abandoned for Appium 1 immediately. They'll continue to work for a while. They might even continue to work after this six month period, but after that we're not guaranteeing that they're going to continue to work with Appium 1.x. And this feels pretty good to me, especially given that Appium 2 has actually been out in beta for well over a year and we've been trying to get people using it for that whole time. So hopefully a lot of you are already using it and if you're not, now is definitely time to get going with it. You know, check out the migration guide. Hopefully you'll see that there's not actually a whole lot of work that you need to do to get it working real. So in terms of a final release date for Appium 2.0, unfortunately I can't give you a firm one at the moment because there are some significant pieces of work that remain. The most significant in terms of the time and effort involved is going to be the documentation project. We want things to actually make sense for folks that are coming new to the project and for people who are trying to get information about certain drivers and things like that. There's a fair bit to do there. And we need to make sure that Appium desktop is compatible with Appium 2.0, which means adding the ability to manage these drivers and plugins from Appium desktop. And that's a bit of work. We have some ideas how to do it, but we haven't done it yet. So then there are a few other things which are important, but may not block a 2.0 release, like some of that removing of old cruft and whatnot. We could potentially do that incrementally as time goes on. We're obviously hoping for more testing and adoption of Appium 2.0 in the community, IEU, and especially with cloud vendors. We're hoping that in addition to HeadSpin and I think one or two others that already support Appium 2.0, or at least have beta support for it, that all the cloud vendors will get on board and have a plan for supporting Appium 2.0 here quite soon. And then obviously because we're putting a lot of weight on this whole driver and plugin ecosystem, we want people to be writing drivers and plugins so that we can really figure out if we've built the right kind of interface for them, because those are the types of changes we don't want to be making too much in the future, because anytime we change the driver or plugin interface, you know, that creates compatibility issues or potential compatibility issues. So we want to make sure we get that right. So now is definitely the time to start hacking on your own driver and plugin and giving us and specifically me feedback on that. Okay, that's basically the state of the union, but as always I wanted to do something that was a little fun for this talk and something that I've been wanting to experiment with for a long time is building a game, right? So everybody likes video games. I always have ideas for games that I think would be fun to build. Actually didn't get so far as trying to implement any of my ideas, building a game, but I did get so far as to download this game development environment called Unity and open up one of their tutorial applications and kind of see how it's put together and start to figure some of that out. So this is a screenshot of that tutorial game that I did not create from scratch. It sort of came with the environment, but I got to play around with it and build a version of the game for Mac and for Android and that was super fun. And I started to think about, you know, what it would take to automate this type of thing, you know, and people have been thinking about this for a long time. And they've always asked me, well, how can Appium automate a game, you know, like this, this is a basically a platformer style game where you have a little character that moves and jumps and stuff like that. So people have asked me like, how can we use Appium to automate this type of thing. And the kind of honest answer that I've always had to give as well, probably don't want to use Appium to do that. It's not probably the best tool for that job. There are a number of reasons. One is that games typically don't have UI objects in the traditional sense they don't typically have, you know, form fields and buttons and lists and stuff like that I mean they might have them as part of their menus, or what they're going to be more focused around, you know, things like sprites or, you know, 3D objects and cameras and, you know, light sources and stuff like that and it's just a whole different world from, you know, the world of a web page or an iOS SDK based application. So the tools that Appium is built on for iOS and Android are all designed around these standard UI objects, which typically don't exist in games. So, you know, when you open up a game in Appium and you try and get the page source hoping to maybe see something like a player element in it or, you know, a ball element or a token element. Instead, you just get one kind of black box and you have no insight as to what's going on inside that from the Appium perspective. So, there are some things you can do to work around this and I've tried to, you know, help move the state of what's possible forward with Appium. So, for example, adding image based automation to Appium where you can say, you know, like I did a while back with the demo of Angry Birds, you can give Appium a picture of a game object and say, well, you know, find where that object is on the screen, and then you can sort of, you know, run some Appium touch commands to tap that object or swipe it around. But you're still kind of working blind because even if you can use image based automation to automate actions, you don't really know what's going on inside the game as a result. All you can do is look for certain things that are on the screen. And games are so dynamic that you're often not in a position to be able to guarantee that the game state is always going to be represented by the same image as it was last time you were in that exact same state. Another problem with image based automation is that, you know, the libraries that exist that Appium can use are just kind of too slow. So even to play a game like a platformer game where you just run and jump around, it's kind of too much for this type of automation. So, you know, I'm not maybe super proud of this, but I think it's great that other projects have come in to fill that gap, you know, Appium basically had no answer for this question. So some other folks came in and made some other own answers. So I'm thinking of projects like Alt Unity tester from Altum and AirTest from NetEase. Alt Unity tester I think was actually demoed, I don't know if it was for the first time, but fairly early on in the project I think at the first Appium conference. So this is something that people have been working on for a while and they've come up with some pretty good solutions for. But it's still not Appium, you know, and I obviously want these things to work in Appium as well. And even tools that, you know, say they integrate with Appium like Alt Unity tester is sort of destroy one of the basic premises of using Appium, which is that you want to use this single web driver based API for everything. And instead they force you to kind of use two APIs, which are distinct in a side by side fashion. And that's, that's fine. That's possible. But to me it wasn't ideal. So, you know, I took this, took this sample game that I was able to build from the tutorial code. And, you know, I started thinking about, okay, well, what if what would I want out of an Appium, you know, game automation thing, how would I even try and, you know, turn this type of behavior that we're seeing right here into a test, right. So the type of behavior we're seeing, we could have one test case that says like, well, let me just show you some code, you know, this is kind of what I was dreaming up. I was thinking about this problem like what would I want this test case to look like. So here's a test case where we're trying to say that this game should allow the player to run and catch some tokens. So these little diamond like things here, while avoiding enemies, right. So while jumping. So, imagine that we have basically a page object called game that, you know, encapsulates all of the whatever the details are here, and just exposes some high level game specific functions that we can use in our test suite. And the same principles that we would use for developing, you know, a mobile app test suite or a web app test suite. Well, we say, oh, let's let's make the player run for 1000 milliseconds or one second. And then let's make an assertion on the state of the game. And so this is something that is really important to be able to do that's hard to do with Appium, you know, you could use Appium's action API to, you know, hold down an arrow key or something like that. So how would you make a character run with Appium with Appium how would you determine that there was a token nearby the player. How would you make an assertion on that. You really couldn't without relying on, you know, somewhat flaky image based automation. Same goes for figuring out if there's an enemy near the player that might need to be jumped over. Or how would you run and jump at the same time and how would you make that expressible in your test code. And then how would you make an assertion that after you've made this jump, the number of tokens that is quite close to the player like within a couple blocks of the player is actually decreased right because we've we've changed the state of the game we've taken the number of tokens from whatever it was before down one because we've consumed one of these tokens. We could, you know, find another test case here and the little example I showed of if we run into an enemy, and we don't jump on its head but we just run into this red blog here. We want to assert that the player has died. You know, so this is a pretty short test case basically we're just saying that we're asserting that the player has already done something in the game so it's not starting at the initial spot. Then we're having it run in this direction towards an enemy. And then we're checking that the player died. Right. So this is this is something that I think would be pretty cool to have. And I guess what I want to say now is actually these videos are an example of Appium running those tests so that code I showed you wasn't just. Oh, I this is what I hope will happen. That's actually code that I wrote that uses this Appium plugin that I developed to integrate with the Alt Unity Tester server. And actually can figure out the state of the game and can run and jump into all these things in basically real time without a lot of lag. And actually use it to, you know, automate these types of applications. So I chose Alt Unity Tester as a kind of basis for this plugin because it seemed like an amazing technology for Unity app specifically and that's one that a lot of people already used. And again, I just had this limitation of not being kind of directly integrated with Appium, which is fine, you know, there's no reason that it has to be, but I would like it to be so I created this plugin, which basically embeds an Alt Unity client. But then it allows you to basically use whatever driver you want right so you could use the Appium UI Automator to driver to launch your Unity game or you could use the Mac driver to launch your Unity game which is what I did for this example. And then you can just switch into the Unity context and use the commands that are available within that context to actually, you know, work inside of your game versus from the outside, which is where you would normally be with Appium. One of the nice things about this is you don't need to learn the Alt Unity API because everything gets mapped to the standard Appium commands that you already know. You just have access to this API kind of under the hood, just like you would with all the other Appium drivers. So I will say that this project is still in very, very early R&D mode. I didn't get a lot of sleep last night and I was working on it all today still. So it's not like ready for you to use, but I am developing it in the open and hope that it can become something that we all use here pretty soon. I decided to write it in TypeScript kind of as a fun experiment to show that Appium drivers and plugins can be in TypeScript as well, not just JavaScript. So please come help make it awesome. It's up at the Headspin organization here at this URL. So come and check it out. Again, it's not in a place where it's ready for general use, but hopefully over the coming weeks it will get there and become something useful. So that's basically it for me. I had to end with a cheesy graphic with Appium 2.0. You know, the power is yours, but also the automation is everyone's that's kind of the goal here. And I do hope that we can learn something from Captain Planet and that somebody in the audience can figure out how to use Appium 2.0 to solve some of the world's actual problems. And you know, app testing is certainly a worthy problem for us to solve, but there are also some bigger ones, including climate change here. So if anyone could think of how to use Appium to help help rectify that situation. I would love to support that. Okay. That's it for me. I'm not sure we're at time wise to rush, but I would love to take any questions. If we still have some time. Absolutely. I think we can take seven minutes more. I think we could take seven to eight minutes easily. So, okay, great. Go ahead and stop sharing and I'll just have my face up here. That way I can also read some zoom questions at the same time. Wow. Lots of questions. Okay. Yeah. So there's, there's some questions about Appium 2.0 as it relates to specific platforms. So, you know, someone's asking about iOS execution. So this is an important point. Appium 2.0 has nothing to do with iOS or Android. It has nothing to do with what's going on in those drivers. So that's a question for the maintainers of the XC UI test driver. So we don't ask like, is Appium 2.0 going to have this or is Appium 2.1 going to have this for iOS? Appium is no longer related to iOS specifically in any way. The question to ask is, will the next version of the XC UI test driver have this or that? And to do that, you have to go to that repository on GitHub and interact with the maintainers there to figure that out. I do just happen to know because I watched that repo as well that the, I guess the final release of the most recent version of iOS had a significant time regression. There's just an Apple bug that we can't fix or work around. So hopefully they will fix it and release the patch and the next version of Xcode. Okay, let's see what else looks interesting here. Will Appium 1 test run on Appium 2? I think I covered that in the talk. More or less, yes, but just read the migration guide. Again, there's not changes on like the iOS and Android specific sides of it. It's just some kind of architectural structural changes including requiring W3C capabilities and things like that. So let's see. WinApp driver, the Windows technology that the Appium Windows driver uses, someone saying they don't have a lot of momentum and there's no other best alternatives for Windows app automation. That's a sad fact. And Microsoft indicated that they wanted to do more to help that, but they haven't followed through. So I'm not sure what's going to happen with that. I did talk to some other people in that thread about potentially creating a new Windows driver, but I am like very, very far from a Windows developer, so I'm not a good person to actually drive that forward and hopefully somebody with some knowledge of Windows automation will want to, you know, pick up that torch and run with it. I was asked, would some of the of the plugins that I mentioned be moved under the Appium plugins repo, for example the gestures plugin or the device farm plugin, maybe, but maybe not. I mean that's the nice thing about plugins they don't need to be in any one repo for them to be useful. They can be anywhere on GitHub anywhere on npm and you can find and install them, just the same with your Appium server. So, kind of doesn't matter, but maybe. Great question from Garov, how could some experienced users contribute to documentation. I'm hoping to make a call for people to contribute to docs pretty soon. The big problem right now is we don't have a good structure in place. And so getting a lot of people working on a bad structure is just going to make it more work in the long run. So we need to get a good structure in place and create, you know, to do and places where documentation needs to be forwarded or moved or updated. And then I think we can have a board that tracks that effort and maybe have a team of, or we can call it a swarm of open source contributors coming and, you know, tackling some of those talks issues would love for your help to organize that for sure. Someone says hi hello. Hello to you as well. Specific, specific bug questions. I'm not going to answer right now. Will Appium 2.0 be released for Raspberry Pi? I don't know. You could probably run Appium on a Raspberry Pi. I don't see why you couldn't. It's just a Node.js library. So I'm going to go ahead and say yes. I ran it on a Raspberry Pi at the last Appium conference and I don't think we've done anything that would make it not work. So yes, I think. Is this anything related to Appium? I'm not sure what this is, but I'm going to go ahead and say yes because everything that we're talking about is related to Appium. I'm going to try to get started with plugin creation. Well, coming to the workshop yesterday would have been a great first step, but we'll create some resources and some guides. But right now the best thing to do is to go to the Appium plugins repo where the kind of official Appium plugins live. And there you can read the code of the existing plugins. Some of them are very simple. There's something called base plugin there. And the read me for base plugin actually has a lot of information about what you would need to do to write your own plugin. So I would start with that. That's probably enough to get you going. But like I said, we'll also hopefully be releasing a sort of general guide to driver and plugin creation or maybe I'll do a set of videos on that or something. So keep an eye on anything like that. We'll all announce on my Twitter, which I think was on the slides. It's just jlipset on Twitter. What are the reasons to split Appium desktop and Appium inspector? The two big reasons for me were that Appium desktop was a massive application when you unpacked it. It was like a gigabyte in size. It was ridiculous. And most people need the inspector, but most people don't need the server. And the server was the thing that took up all the size. So I use the inspector, but I don't use the graphical version of the server because I just run the server from the command line and so do a lot of other people. So I wanted to be able to download and launch the inspector in less than like 15 minutes or whatever it normally takes because Appium desktop was such a beast. So that was one reason it just seemed like they're different enough applications and it would be nice to have the one that people use most be much more lightweight and easy to use. The other reason is that the Appium desktop server cannot be a web application because it is its own server and it has to run Appium and Appium can't run in a browser. But the inspector is just an Appium client and that can run in a browser. So I wanted it to be its own project so that we could do things like run the inspector on Appium Pro as a regular old website. And I think that that's a huge win for people so that they don't even need to download anything to use the inspector. That's the other main reason. Let's see. Someone's asking if Appium 2 is compatible with the Apple M1 chips. I don't know. I think so. I don't have an M1 laptop yet. Hopefully soonish but we haven't done anything between Appium 1 and Appium 2 that's fundamentally changed the way that the technologies work. So it should work. The only question is is there some dependency that Appium has that for whatever reason doesn't work. But it wouldn't be because of anything that is Appium specific. It would be like, oh, does the Android emulator work? You know, do all of the Node.js native bindings and the dependencies we use work and things like that. So I don't know until I try it. I think some people have tried it on M1 machines and found it to work but I haven't myself. Let's see. Is the Appium web inspector the browser version? Is that only for hybrid apps? Or is it also for native applications? It's for everything. It's the exact same inspector that you would use as an application on your computer. It's just hosted in a website. It is literally the exact same thing. In fact, when the inspector is running as an app on your machine, it's also still a website. It's just running in a container so it looks like an application. So there's no difference between the versions of the inspector that you download versus the one that you run on the website. Yes, G2 mentions that to make the Alt Unity plugin work, we need to add the Alt Unity tester asset within the game and you have to build it into the game. And yes, that's true. Otherwise, there's no way of doing this with Unity. The only way to get access to game state and game objects is to actually build things into your game because Unity doesn't expose those in some kind of you know, officially supported way. Like Apple officially supports X UI test and exposes automation capabilities. Unity doesn't have anything like that, which makes sense because Unity just compiles applications into you know, kind of opaque binaries and runs them on a huge number of platforms. So in this case, yep, you were not, you know, testing the binary that we're shipping, we have to build in the Unity server, the Alt Unity server to make it work. But because that's the only option we have, I'm cool with it. But yeah, you have to follow the directions that Alt Unity provides for embedding the asset in your game for that to work. Um, let's see. Will there be scenarios? This is a question from Vinod. Will there be scenarios where multiple plugins are triggered at the same time? Yes. This is fully supported. Plugins can choose whether or not they allow other behaviors to also run. So plugins aren't guaranteed to work with one another. And this kind of has to be the case because the plugin has to have the prerogative to choose to fully overwrite an apium command or to, you know, allow the original behavior to run and then to do some modification on the result of the original behavior. So internally apium kind of stacks the plugins in the order in which they're included and it will run each of them within the other. But at any point plugins can decide not to continue down that chain and just do something on their own. So you could run into a situation where two plugins don't play nice together. But that's kind of the reality of the world if two plugins are trying to modify the same behavior and conflicting ways, you just don't want to use them at the same time. But if two plugins don't conflict, then you can absolutely use them at the same time. I think I was just about to interrupt and say, I think we are at a good point. I see there are a lot of questions. There are people who are curious to learn more. So it's always great to see that. I think there are 44 questions and I also see a lot of people asking questions in the chat itself. So lots going on. I believe Jonathan will be available in the head spin virtual booth and you can meet face to face with him and ask him more questions. I know it's pretty late for him but he's going to hang around for some time at least. And I'm going to take this opportunity now to quickly jump in and walk through some of the important things people need to know to get the best out of this conference. So I'm going to quickly share my screen, maybe take 15 minutes to run everyone through some important updates, important information they need to know. But before I jump in, I do want to thank Jonathan for the wonderful session. I think people are still asking questions. So that's in my view a way to measure how good a session was. So fantastic job again Jonathan, thank you.