 On today's Visual Studio Toolbox, Jerome is going to give us a behind-the-scenes look at the UNO platform. Welcome to Visual Studio Toolbox, I'm your host Robert Green, and we're in the cozy confines of Studio B today, and joining me is Jerome LeBat. Hey Jerome. Hey Robert. Thanks for coming by. Oh, that's a pleasure. It's cozy, for sure. Jerome is the CTO of the UNO platform. Yes I am, and it's been a very interesting ride for the past six years. Cool. So back in December we had our good friend Martin Zickman on the show, who gave people an overview of UNO, so if you guys haven't seen that, I highly recommend that. Basically it's you take your UWP XAML, and you can build Windows apps, iOS apps, Android apps, and WebAssembly, which is very cool. Absolutely. And Martin showed us that, gave us some demos, very, very cool stuff, and then I heard that you guys were in town, so I said, well we should get the UNO guys on the show. Absolutely. Not so much to tell us how to use it, but I guess my first question is, where did this come from? You obviously had a need, and now here we are years later with an actual open source product. So how did that happen? Well, it's all started with Microsoft, as it always does. The company behind UNO is inventive. It's an agency that does, that used to be doing, and still does, Windows phone applications and Satellite and WPF, and for quite a while we were doing Windows phone applications, then also the seven series and eight and eight five, and then Windows eight, Windows 10, and then we had a lot of developers that were doing Sable and C-Sharp. And then things evolved, then people started asking us, well, do you know how to do iOS apps as well? And at the time, Xamarin was starting up pretty nicely, but it was still, I think it was renamed at the time from Monotouch. So it's, Xamarin iOS got renamed by Miguel de Caza. And then we started working around, and we got to something that was very interesting, because we said we have to be able to reuse all those skills of the developers that we have, and inventive. And one thing led to another, we started to implement a few controls, and then it started working pretty well. Then we added lots of other controls, and we got to do some very nice applications that are still running as of today, using the Uno platform, it was not called that at the time. And we got to continue doing this. And at some point, it made sense to just align everything with the UWP API, or what is now called the WinUI, or it's going to be called WinUI, WinUI 3, and those kind of release. And it's all about reusing skills, really. That's what it is. And also the fact that Microsoft from the Gapgo and UWP and WinUI team have been designing the API set with all those screens in mind, from the very small screen, IoT and new phones, and to the very large screen that you can do with going to finance surface, the very large surface, and HoloLens or Xbox for that matter. So that means that they thought about all those concerns and it made sense to reuse all this and make sure that we can implement that contract properly and target all of this. And in between, we were doing this where I was an Android and then WebAssembly came in. And that's where it became very interesting to see. At this point, we didn't, it was closed doors, because we were developing that for our clients. And we said, well, we cannot keep that to ourselves or people are going to be wanting to use that. So was that part? So if you look at something like Xamarin Forms, there's a XAML that you use to express the UI. And it's, I mean, XAML is XAML. No one had XAML is XAML. It's not 100% the same as UWP. But if you know one, you can learn the other. And if you've never learned a XAML, you can just learn a XAML. And then when you compile, it builds into a Windows app, an iOS app, an Android app. So there's some type of, in the compile phase, it reads the XAML and knows how to translate that into native UI for iOS and Android as well as Windows. Obviously, the compiler in Visual Studio already knows how to do UWP into a Windows app that's already there. So you didn't, did you have to write your own compiler, your own translator? You could hook into the one already in Visual Studio? Somehow. Is that OK? A few things. But the most interesting part of that is that we're leveraging everything that Xamarin is providing. Everything that makes the Xamarin app, not talking about Xamarin Forms specifically, but Xamarin in terms of the binding to iOS and Android, where we're using all this. So every single feature that comes out, latest of those is hot restart. The hot restart works with UNO apps. I mean, it's just a few lines of code to add and then you can debug an iOS application, usually in your phone, from your Windows PC without a Mac. So it's something that was added by the Xamarin team and we just being able to take advantage of that. So the key part for iOS and Android is that it's not something that is so different. We're just sitting on top of Xamarin. That's pretty much it. So the part of the XAML is a bit different because the XAML is the XAML from WinUI. So what we did is took a, created a generator using the Roslin API. So the very smart forms of the Roslin API, they've been doing some amazing things there and we're taking advantage of that to generate C-Sharp from that XAML. And that's that C-Sharp is basically a representation of the XAML. And that's an interesting thing because that means that you could probably just write your C-Sharp directly and not use XAML instead. Or I could create my own ML, I could create row green ML. And as long as I was clever enough to write something using the Roslin analyzer to spit out the right code. That could be, that could be. Well, it won't be, but it could be, is the key. If you take a look at the Xamarin. It's interesting to understand the mechanics, right? Like when I first saw it, I thought, oh, that's really cool because, you know, if you have been doing UWP and you know that XAML, yes, you can learn Xamarin Form XAML, but it's kind of cool not to have to. And then I thought, well, how do they build iOS and Android? And then I kind of discovered that you're just using the same Xamarin build tool. So now there's some way of taking whatever ML, that XAML, and then just translating it or building something that then plugs into the Xamarin engine. And then after that, you know, all the work's done as long as you get it right. Exactly. So the interesting thing and the very important piece of that language is that what we're doing is we're taking the XAML and generating the C-sharp. And that C-sharp is basically something that you could write in UWP directly on Windows. And then at runtime, what we do is we take that tree that you're generating so you have a grid stack panel text block and then that chain or that hierarchy that you're generating, that gets translated into something that can be displayed. And it's using, and that's a very important part, it's using the native APIs to do that. And it's not, and that's something I'm going to show you, I have a demo for that explicitly. And that's a confusion from people in Evan Martin when he tried to explain you that, it missed that specific part. I'm going to be explaining that. We're using the native APIs to show the controls. So for instance, if you have a button, you can use a native button, but you can also use the XAML representation of a button. So you can draw your, if you want a video inside your button with the rounded corners with weird colors in it, you can do that. But you can also use the native button instead. And you can switch between the two. So that's where it gets interesting. And it gives you the ability to get from something that your designers will love, because it's going to be the same for all platforms, including the web, but also be able to say, well, I have a client that wants to use UNO and he wants to be using the native APIs and have the native look and feel. He can do that as well. And then because you're using UWP XAML, you don't have to write a designer. There's already one in Visual Studio, and there's already a team adding things like IntelliSense and all the beautiful trickery we had Dmitri Leyland on the show a while ago showing all these cool tools. And you don't have to duplicate any of those because you're using the existing XAML. Exactly. And the side effect of using that XAML is if there's a library or a piece of program that has been written that is using that same XAML, it will work. So you don't have to translate anything to get that running. So that's why we have the Windows Community Toolkit running and it's getting better. So we have a set of control that we're keeping updating to. So we have in the recent updates of the Community Toolkit, the tab view that's working now. So it's a control that XAML is very fond of and that control is working now. So how did you decide to... I mean, you mentioned Xamarin before prior to being purchased by Microsoft, Xamarin was not free and it was actually kind of pricey. And now it's obviously just a piece of visual studio. Uno platform is open source and free. And free. How did you decide that part? So... Thank you, by the way. Of course. I love it as a user, but as a company, how did you decide that part? If you want to use the... You can just go over to GitHub and then download the packages or from NuGet and then just use it. What is interesting for us is then saying, if something doesn't work for you when you want an update or you want a new feature, then you can implement it yourself and then send a pull request out. That works really well. And we have over 130 contributors now in our GitHub. So is that kind of the math? We can get money now or we can save money later? Well, it's more about if you come to us and say, I want to have that feature implemented. We have professional services and people that are going to be implementing those features. And it's about managing the priorities of the backlog that we have for implementing features. That's exactly how we're doing it. And we've been using Uno as part of Inventive to make all those apps we have over 200 apps that are running now. And for us, we use it. We live and the company's based off of that. And we had that model before open sourcing Uno. So we were designing Uno based off the fact that Inventive is using it to build apps. So you were going to do it anyway. Exactly. And then you said, okay, we can just do it anyway and just keep it ourselves. Or we can do it anyway and productize it. You make some money but now you're on the hook for support. Or you can do it anyway, open source it. And now you get more of the ecosystem and more people contributing to it. So you grow your development team on something you were going to do anyway. Exactly. Okay. Exactly. And we get people that are of interest. It's a whole world. People are contributing to Mac OS support to Uno. This is amazing. So that's what we're looking for. And getting people interested in filing bugs. It was a very interesting person from the Windows community that started looking at Uno and said, oh, that V6 that you've made for creating new templates for Uno apps, it doesn't have the tags in the creation of a new project. I'm going to add that. Okay. Just made a PR and then that's it. So that's the kind of thing that makes it so interesting to work with open source that anyone can contribute and makes the platform move forward for everyone. And Microsoft supports you guys and is happy to see it, I imagine. Yeah. So Microsoft, yes. So I mean, it's all about pushing.net. Right. That's what we're doing. We love the ecosystem. We love making sure that.net moves forward. We want to push C-sharp to the web. We're using all the tooling that's available here. The WCT folks and Michael Hawker specifically is MLNAMO. It's helping us as well. Providing feedback and adding features there as well. We have the Xamarin Forms guys that have been helping us as well for the implementation of the Xamarin Forms renderers. So being able to take a Xamarin Forms app and then make it run on the web using WebAssembly. So they've been helping us in testing out features and things like that so that we can make that feature move forward. So that's very interesting. And you as well. Of course. So yeah, Microsoft's helping, that's for sure. Awesome. So I guess those are the kind of the questions I had. Now it's your turn to lead the discussion. So Martin was on the show in December. I assume new things have happened since then. Yes, lots, lots of those, lots of those. So I'm going to be showing you what's hot lately. So over to your left top. Yeah. What's hot lately, especially with the release of the surface duo and all of those libraries. And I'm going to be showing you something that has been used by Microsoft to demo lots of features around the two-pane view. So that is a control that Microsoft is pushing as part of the surface a two-pane view that there it is. So what we did, and because Uno is something that is using the WinUI API, that control that you see on the screen is the exact control that Microsoft uses inside of WinUI 2.4 that's an upcoming release. And that is used on both use on both Neo and Duo. The Xamarin.Forms folks have been doing the same control. And that control is the exact same code that you will find in WinUI. So it behaves the exact same way. So for instance, I can take that app and put it on the second screen like that put it in the middle. And when it resizes and place itself in the middle, then you're going to see that the second part has been shown in on the side. And that is code that I have not developed. I don't, if I look at some of the features, I don't know some and some of what those do. I looked at the documentation when that happened. And that's very interesting to see because it's just the same code. And we're down to even reusing the same UI tests for that part. So the Uno tooling uses that. So it's very interesting to see what you can do with that. So that again is one of the benefits of what you're doing is that you just inherit things that show up in UWP and in what Microsoft supports. Exactly. There was there some work you had to do? I mean, what happens if I put that in an app and then I run it on, I create an iOS app out of it? It will run. So that, it will run the same way. So that control is able to work even if there's no two screens. Okay. That control works for that. It's able to actually, so the way it works is that you can set a size per one pound, one side of the screen or one side of the pane and then another side of the pane. And then if the window resizes or if you are an iPad and you have, let's say you dock the window or dock the app on one side or another, then the control will adjust itself properly. So that's the kind of thing that we're adding in the platform. So that's quite amazing that we can actually reuse that kind of things. And that allowed us that control. Like it took me, let's say four hours to port something like that. So it's very, very easy to do. And it took Microsoft some time to develop that kind of controls and thought into the thought that was put into designing proper concerns and properties and things like that to make sure that the control behave properly. And then it's a new thing, these dual screen phones are a new thing. So you can imagine the next several years that things will change. Of course, of course. V1 of the UI will then become V2 which will then become V3, et cetera. And we're going to update as we go and we're going to take the updates that Microsoft is going to be making inside of WinUI and follow along. So that's one of the very interesting thing of being able to reuse code because the APIs are the same. That's one interesting part. Another demo that I want to show you is the notion of styling. So when you look at, let's say, I'm going to be putting that application aside and I'm going to be launching another one which is that application. I'm going to be using that on the side. Let's keep the other one on the side because so what I have here is the application that I have here. So let's me just bump up that so we can see it better there. So what I've done is I have a grid and inside I have a checkbox, a slider, a button and a toggle switch. So those are Windows controls in the pure sense in a way. And if you put that inside of a Windows application or in an Uno iOS Android old web, it's going to look like this on that side. So that means that it looks like a Windows control. It looks very familiar. Exactly. The thing is that sometimes you may not want that. You may want an actual control that looks like the Android one and those are not the Android ones. So the interesting part about Uno is that you can style a control at runtime to change its behavior or it changes its appearance to change from example-ish control to a native control. So what I did here is I bound that checkbox to change the style of those controls. So when I do this, I change the style of those controls. So it's re-rendering completely and it allows me to change the visual aspect of that control. So there it is. And that's the original one. You see there's even the visual cues of the Android controls. So why would you do that? You don't. You don't. You don't. But that's to show a point of saying that it's up to you, the developer, to choose what you want to show. And it's not bound to, I want to choose for the whole app what it looks like. I can choose per control, per instance of a control. It's actually an interesting option to offer users, right? To have things look like a Win10 app, look the same across. Maybe you may want to say that if a user is picky, and then you change your UI completely and provide something else. And the way I implemented it is basically data-binding a style for Xamarin projects only and say that the scheck property of my checkbox that's above that uses a converter that tells, let's say for the Slider switch that's at the top. I'm going to be using either the native default style, which shows the actual Android or iOS depending on where it runs, or the XAML default slider that is the one that you're going to be seeing when you're on Windows directly. So that's how you can switch between the two. So that's to show that it's not frozen when you're building your app. You can change it even at runtime, even if it doesn't make sense in that kind of scenario. So that's to explain that that's very specific. It's something that people, especially people that do know about XAML, don't get on the get go. They think it's XAML, so it's probably just one way, and data-binding styles can be done. It can be doing that kind of feature set. And is that in the current version or is that coming? No, it's been there since the beginning. It's a feature. So the very important thing is that we have an inventive, we have designers that are very picky, and they want to have that design, the actual one. They want that slider to be blue and very specific size. So they want that kind of things. But there are also occasions where having the right design, the native platform design makes sense because it's a small app and then you don't want to design those controls because it can be complicated to do. So that's where it makes sense to use native control. So you can choose whenever you want. Okay, cool. So that's the one. And then I'm going to be talking about another feature that we announced from WebAssembly. That's AOT support. So AOT is what is called ahead-of-time compilation. And it's for WebAssembly. The idea is that at this point, and that's what laser is doing at this point, is that when you have C-sharp running in your browser, it's actually taking the IL that comes from the DLLs and it's not compiling that to WebAssembly. It's keeping that as IL. And then the monorun time takes that and executes that on the flow. That means that while it can take anything, an interpreter is not as fast as running code that is targeted for the platform that's underneath WebAssembly in that case. And what we've seen is that WebAssembly that IL interpreted on WebAssembly is about 30 to 40 times slower than running using compile down to WebAssembly code. So that takes a toll in an application. And up until now, the only ability to compile to WebAssembly was to use Linux. And we posted a while back the ability to use a Windows system for Linux, WSL, to compile that to WebAssembly. And then recently we made an update that allows us to use that completely from Visual Studio. So you can build that from Visual Studio without having to run any command line inside of WSL. So that gives you the ability to build AOT from Visual Studio. But what I want to show you is that, and that's another feature, is that you can use C++ that you compile down to WebAssembly inside of a C-sharp app. Really? Yes. And that is the interesting part. So what I'm going to be showing you now is, and it's a side effect of adding AOT from Windows. That gives the ability to do that kind of development. So what I have here, let's say I'm going to be looking at my page. So it's a very simple app. My XAML just has a text block with Hello World in it and a click button. And inside I'm going to be finding a DLL import. So for those who have been doing things for a while, and .NET for a while, may be familiar with that. The idea is that what you're saying at your C-sharp program, I'm going to be calling that method that comes from somewhere else. It's not .NET. It comes from an import that something exported over. In Windows, that means that you're referencing most of the time a DLL that has some exports and then you're calling that method from that DLL. What we did for WebAssembly is basically map that to be able to say that method I'm calling, it's coming from another WebAssembly module that's linked in when building the overall application. So what we're doing is basically that method. It's implemented in that file that I call my module, that CPP here. So it's basically A plus B. I'm calling that from my page. And what I'm going to be doing right now is just compiling that method so we can see what it does. So it's going to be running my application. And so I built it already so you can see the results from the bidding and see the proper results. Oh, okay, so I built it with the previous one so I'm going to be rebuilding it. So let's see that. So what it does here is basically compile the C-sharp, then calls some native tooling that's called M-scripten that calls Mono to generate some WebAssembly code. And it takes in as well some external WebAssembly code that is linked in. And then Mono just does the connection between the two and provides you with a single experience that you can just execute right away in your browser. And so you don't see it when it's building but it's actually calling WSL in the back. It's actually calling a lot of other things like Mono.net.net core inside of the WSL. So the tooling is just doing calls, executing bash commands in the behinder and it's amazingly powerful. Just done all on the back and you don't see anything. It's just it takes a bit of time and that's why we don't suggest to do that all the time. But when it does, when it builds and it gives you the proper results, that's probably just the first build. But then afterwards it gets running and you get your application running. That's a technique that we use in the calculator, by the way, Windows calculator. Did Martin show that? I think he showed that. Yeah, not only did he show that, I started adopting it. That's the calculator I use on this. Oh, excellent. Yeah. So it's been interesting. So we've been building that. The application that I've executed, so it's still building. Okay. So we'll let that go for a while. We saw it work, it's very cool. Okay. So yeah, it's been very interesting to be able to integrate all that and that means that for people to be able to reuse, let's say for Rust code or Go code or anything that's been compiled to... Oh, there it is. Compiled down to WebAssembly and reuse that without doing anything. So that one is 41. And if I change that, my C++ module here, instead of doing that, I want the actual truth and not just a partial truth, 41 and 142. I can just execute my little scripts. So that is compiling my C++ into WebAssembly module, which is very fast. And it's a little script that I put here. I'm going to show you that. It's just mscript and cc, takes my C++ modules, compiles it down to bitcode, which is the intermediate language that LLVM uses. So it's basically like a DLL, if you will. It's a very well done down mode. And then if I rebuild my application, changing that, then it's going to take again my new module and then build it into the application and do the proper results. So yeah, it's a lot of fun being able to plug all those things together and have a functioning ecosystem and you'll pull in all those things that are, you know, the two-paying view works in the web. Yeah, that's where it gets interesting. And we're going to be adding support. That's not the thing that are on the future. We're going to be adding support for the Duo SDK for web applications. So that means that if you have an application that uses the two-paying view on, you know, in your WebAssembly application, then if you go to a Duo or a Neo inside of Edge, then you're going to have the support for the hinge and support for the two screens. So that's very interesting to have as a feature set. Right, cool. Yeah, it's amazing. Awesome. Anything else? Anything else. At this point, no. I can show, I don't have a demo for that, but we've been poking at advanced features of WebAssembly and then the threads. And threading is something that has been missing for .NET applications and I've been able to, you know, I tweeted a little bit about that a few days before, where basically you can update the UI from a background thread. And that's going to make for very, very performant applications where you can push work on the background. Because at this point, most of the WebAssembly applications on .NET specifically, they've only been able to use the main thread. So if you're doing digitalization on the main thread, it's not a good idea because your application stalls. And it's not something that you want to have. So that is something that's going to be interesting. And last, but not least, the macOS. That is something that we're looking at. Yeah. People have been asking for that for a long time. And lots of people have, you know, Macs and want to be developing on their Macs. But they want to be able to, you know, take that app and put it on the web and put it on Windows and then you don't want to that's something that people have been interested in developing for. Yeah. And with. Definitely cool. For and with. Yeah. All right. Cool. Well, thanks so much for coming by. I'm glad you guys were in town. We're able to do this. Yeah. It was fun. Thank you very much for inviting me. All right. Hope you enjoyed that. And we will see you next time on Visual Studio Toolbox.