At Microsoft, we're committed to providing our teams with the best tools and technologies to build high-quality mobile applications. React Native has long been a preferred choice for its high performance and great user experience, but getting stakeholders on board can be a challenge. In this talk, we will share our journey of making React Native a preferred choice for stakeholders who prioritize ease of integration and developer experience. We'll discuss the specific strategies we used to achieve our goal and the results we achieved.
Raising the Bar: Our Journey Making React Native a Preferred Choice
AI Generated Video Summary
This Talk discusses Rack Native at Microsoft and the efforts to improve code integration, developer experience, and leadership goals. The goal is to extend Rack Native to any app, utilize web code, and increase developer velocity. Implementing web APIs for React Native is being explored, as well as collaboration with Meta. The ultimate aim is to make web code into universal code and enable developers to write code once and have it work on all platforms.
1. Introduction to Rack Native at Microsoft
I'm here today to talk about raising the bar. My name is Calcet, a maintainer for Rack Native at Microsoft. We use Rack Native in our biggest mobile apps, as well as on other platforms like Mac OS and Windows. We had a talk at Chain React about using and maintaining Rack Native for desktop. We also introduced the concept of the Microsoft Galaxy, with multiple Monorepos.
Why are you here? This is Zytrack. Go, go have fun. No, thank you for being here. I really appreciate you all. And well, as our lovely MC already said, I'm here today to talk about raising the bar. So, let's jump right into it.
She's already also mentioned that my name is Lorenzo Chandra. This is my face, but maybe you recognize me more like this. My name is Calcet. I've been a maintainer for Rack Native since 2018. I'm a senior software engineer at Microsoft. And what I want to talk about today is basically the journey that internally at Microsoft, me, and a few colleagues have been going through.
You see, our job, specifically me and my colleagues, is to be invisible. And you can be like, well, you suck at that. You're on stage. I can see you. You're already failing. And like, yeah, fair enough. But let me give you a bit of an explanation. So, first off, when you think about Rack Native, of course, you think about mobile apps. And at Microsoft, yes, we do use Rack Native a lot in some of our biggest mobile apps. Of course, these are mostly Brownfield apps. So, we have some parts native and some parts in Rack Native. But not only that, we actually do use Rack Native on all the other platforms that you can think of. We use it for Mac OS and Windows. And we had a talk at Chain React earlier this year from two of my colleagues, Chiara and Shivyan. And I would highly recommend you watch it because it really dives into the desktop aspect of using and maintaining Rack Native for those platforms. But not only that, a few years back, we did introduce the concept of the Microsoft Galaxy. You see, Microsoft is a big company. We don't only have one Monorepo, we have many of them.
2. Solutions for Seamless Code Integration
When working on Rack Native, we ensure seamless code integration across different apps and Monorepos. Our goal is to enable developers to leverage the tooling instead of fighting with it. Challenges like varying needs, different versions of Rack Native, and bundle size are addressed through our solutions, including the React Native test app. This sandbox app abstracts away the pain points of using a vanilla React Native app and supports multiple versions. It also supports the new architecture and offers an experimental single app mode. Our solutions cover iOS, Android, MacOS, and Windows platforms.
And when we work on Rack Native, of course, you want to have something that can be used across different apps. So, for example, I think we recently have done the full rollout of one of the main Rack Native experiences across all the main apps. And for that to happen, basically, we have all these different Monorepos interacting with each other, but that increases the complexity of using Rack Native by quite a bit.
So, that's where me and my colleagues come in. We basically make sure that all these different parts of the galaxy, all these different planets can use the code, can take the code from one Monorepo, put it in the other one, and everything should work. So, we are invisible in that sense, because we want people to flawlessly be able to work on their code, and then that code to go into the final app, into what we call a host app, usually the products that you use.
To say in a more proper term though, what we try to do is basically enable developers working on our products to leverage the tooling instead of fighting with it. And you're all, well, some of you are Rack Native developers, so probably you know that there can be potential pain points. And at Microsoft, we have a few that are very specific to this Galaxy approach that we have. So, when we have hundreds of engineers spread across many different projects, if everyone has different needs, if they use different versions of Rack Native, different versions of their libraries, that creates a problem.
If the bundle size is too big, that's definitely a problem, because our apps like Office, that's one app for, you know, Word, Excel, PowerPoint, like all in one mobile app, as you know, like there are some policies on the stores. So, we're always like, just write below that, and we need to keep it there of course. And you know, upgrading, we all know the story when it comes to upgrading, I see everyone is just like, oh my god. And I'm sorry, it's partly my fault, we're trying to be making better. But yeah, and sometimes the code doesn't work, like it works on your site, on your monorepo where you do development, and then you, you know, send it to Outlook and then they put it into their code base and it doesn't work.
So, a lot of these things, of course, cannot be necessarily solved at the core level. So, by sending PRs against React Native, sometimes we need to take things into our own hands. And to do that, we have been working on two main solutions. The first one is what we call the test bench. This is called the React Native test app, and it's basically a sandbox React Native app where we have abstracted away, 99.9% of the pain points of using a vanilla React Native app. This one supports from 64 to 72, and we're working on 73, and basically this means that you have the sandbox and you can very quickly, and I'll show you in a bit, swap from one version of React Native to the other so that in your test environment, you can verify that all the versions that your host apps are using, their code is going to work, basically.
It does support the new architecture. It supports the Xfce cloud config plugins. We're trying to make it as usable as possible for the community, too. And we also have an experimental single app mode. So if you have a small project side thing that you want to try to put into a different vanilla React Native app, please talk to me, because we're looking for sacrifices, people we can have a partnership with and try these things out. And of course, it's not just for iOS and Android. We care about MacOS and Windows, too. So out of the box, you throw your code in there and it works across all these different platforms. You don't need to take care of those.
3. Improving Developer Experience and RNX Kit
We've created a mono repo called RNX Kit, which is a toolkit that includes various plugins for Metro, custom profiles for Babel and ESLint, and a CLI replacement. One example is the tree shaking feature in Metro, which has shown great results. Upgrading from one version to another can be time-consuming, but by using RxKit tools, like Reckon Native Desktop, the process can be significantly faster. Watch the video to see a demonstration of the aligned apps command and the YARN style command for the codebase.
The other bucket, the other main solution that we're working in is basically improving the overall developer experience and creating extra plugins for our needs. And we've put all of these different things that all these, you can kind of see there, it's very long. We put all of that into this mono repo called RNX Kit, which is React Native Experiences and Kit it's like, because it's a toolkit, like we're putting everything in there, and you can just pick and choose whatever you want.
Across the various things, we do have some plugins for Metro. For example, the main thing that we have is a tree shaker for Metro because right now it doesn't have it. We do have custom profiles for Babel, ESLint, and a dropping replacement for a CLI even because basically we wanted extra tweaks, extra flags that you want to pass to the CLI when you do, for example, the bundling. And we're just like, well, if we just like put a bit of another on top, we can just like ship it to all our internal customers. You just run bundle and all the extra configs, we've taken care of that. And we do have a special talks announcing the RNX Kit repo in 2022 by Dan Foxman. And yeah. So as I was mentioning, like one of the examples of things that we have in there is the tree shaking in Metro. Of course, all of this is open source. So we have some people in the community that are able to also use it and some pretty interesting results. Tree shaking, as I was mentioning, bundling is very important for us. So we've been trying to literally shave as much as we can and the fact that it's also usable by the community was a really great signal for us. Of course, when it comes to this type of thing, they're great, but the best part comes when you put them together. So as we mentioned, like upgrading can be a lot, can take months for some of our biggest codebases. So you may be familiar with this. Like when you try to upgrade from one version to the next of Reckon Native, well, in here, this screenshot is from 68 to 71 I think because that was one of the main jumps that we did in one of our monorepos. This can be pretty long and pretty big. So what we've been doing is making it effortless in a way, at least for some codebases I would say. So when it comes to Reckon Native Desktop, if we pair it with one of the other tools in RxKit, you will see that things can get much faster than months. So I'm going to do a demo. And I'm going to preface this with the fact that when I was at Reckon Native Europe earlier this year, my laptop was a 16% battery. Everyone was like, is he going to make it through? I'm not going to challenge the gods of live demos again. I'm going to just show you a video, basically. So what we have here is the first command, aligned apps. And as you can see, this video is not sped up. This took three seconds. After this, I'm going to run basically the YARN style command for the codebase.
4. Explaining Restyle and Simplified Rerunning
This is Restyle, a Shopify design system library. We changed the version of Rack Native and did a YARN install and a pod install. The app is already rerunning, taking only 33 seconds for iOS. Android is also reworking flawlessly. We remove friction for developers by simplifying the process of changing versions and doing a YARN install.
And while this runs, what I'm going to explain to you is that this is Restyle. This is a Shopify design system library. So it's not a POC project. This is a true one that exists. And we did run the aligned apps command, which basically goes through your codebase. You tell it, hey, I want to get to this new version 72. Then what it does is basically changes your package. It puts the right version of all the packages that we know. And then we did simply a YARN install.
And at this point, what we're doing, we're already done technically. We are already rerunning the app. So in 30 seconds, basically, we did YARN aligned apps that changes the version of Rack Native or Rack Native Desktop and the other libraries involved. We did a YARN install to get the new versions of the packages and now we're going to rerun it. The key thing to understand here is that basically when you use Rack Native Desktop, you know all the changes, all the massive things that we were showing earlier. You don't need to do any of that. The only things you need to do is change the version of Rack Native and do a YARN install and a pod install. For iOS, of course, and Android, you just do pod yarn install and then you run it. And as you can see here, the app is already rerunning. This took, like you can see there, 33 seconds to rerun the iOS app.
Just for completion, I'm also going to show that Android is also reworking. Basically, it's very, very easy. We're removing a lot of friction because if our developers are working on the experience in this bubble where they only have their dev loop, they use this sandbox, if all it takes for them changing the version and doing a YARN install, we are removing so much friction for them to be able to work, and especially in a situation like this where you can swap very quickly between the different versions of React Native, and there you go. As you can see here, it's working for iOS and Android pretty flawlessly. Thank you. I swear, I can also do it live. It's the first talk in the morning. So far, I've been very positive, like, oh, look at this. This is awesome. This is cool. Of course it's not.
5. Challenges and Leadership Goals
We have been working through a lot of issues and appreciate everyone who has contributed by opening issues and sending PRs. Our goal is to improve the ease of use and transparency of Rack Native. We have made improvements in the breadability story, opened up the RxGit repository for open source contributions, and introduced features like tree shaking. However, our leadership wants more. They want to extend Rack Native to any app, utilize web code, and increase developer velocity.
We also have a lot of issues that we work through. I really appreciate everyone that has been sending opening issues, telling us, hey, I've used this. This doesn't work, and also sending PRs. I just wanted to also call out, thank you for your contributions. You're helping us making it better for everyone. So yeah. Thank you all.
And then, going back to invisible, so what I've shown you so far seemed pretty much done, right? It's working. Not really. But we're kind of getting there, right? So what we've built so far, to give you a super quick recap and also mention a couple of things that you mentioned so far, basically, we have improved the ease of use. We created, like, all these bubble presets and everything to have smarter defaults. We're trying to be transparent. We're putting everything that we can in the SOAPer's repositories on GitHub. We have tried to improve on the breadability story, especially for the standard dev loops through aligned apps and test app. And then of course, we have more advanced scenarios. All the things that we were able to open source are in the RxGit repository. So, for example, if you have a Brownfield app, you may want to look at the Rack Native host library that we have in there. Callstack did also publish a blog post about that. We do have tree shaking. We have some things that work better for monorepos and TyScript. So, that's great, right? It's all great. We've been doing a lot and everything is working. It's not enough.
So, basically, what has been going on is that our leadership is like, yeah, yeah, all good, all fine, but I want more. I want to take your Rack Native feature that you've built here, and I want to put it on any app. I don't want to be forced to, you know, only put it in one or two apps that already have all the things being built in for brownfield support. And also, why can I not just use my web code? I did wrote a React version of this. Why can I just – I just want to take this thing that I wrote once, and I wanted to make it work on all these different platforms. And basically, what these things are in common is that our leadership kind of wants developer velocity. Like, they want to increase the developer velocity.
6. Universal Code and React Native
They want to take the code as quickly as possible from the hands of the developer into production across all our platforms. Developer velocity is something that we're really trying to focus on right now. They want this web and React Native overlap to be much more prominent. We have figured out a way to take web code and make it work in React Native. It's literally the exact same code. The main thing to get code to work within web and native is the web API and navigator with the getBattery.
They want to take the code as quickly as possible from the hands of the developer into production across all our platforms. Because again, Microsoft is not only – we're trying to deliver to iOS and Android, but iOS, Android, Windows, macOS, and web. So, it's a bit more, and especially when these apps are so big, so full of features, you know, things can take months or years. So, developer velocity is something that we're really trying to focus on right now.
So, in a way, what they're asking, you know, developer velocity, they want this, like, web and React Native overlap to be much more prominent. So they kind of want universal code? This is kind of hard, right? So, let me give you a quick example of what this could look like. So, what we have here is basically a Vite in it. And in here, the only thing that exists, kind of out of the template is this use battery status. It's just a hook. It goes into the web API for the battery status. And it shows it. Very easy. Very simple. The battery is 100%. So, we have 100%.
What would it take to make it work in React Native? Just out of the box, the exact same code. Well, of course, there's gonna be a magic trick. But what I'm gonna show you is that we figured out a way that you can take that web code, that folder, the app that was showing earlier is within this test app. I can just import the exact same file, use the hook, and then in React Native fashion, with a view and a label, I can make it work there. It's literally the exact same code. And to prove Now we have 1 showing everywhere, on iOS it's showing minus 1 because reasons. If I change the code to 100, I do a multiplication here, and I just save, as you can see, it's working everywhere. So this is to prove that this can be somehow achieved. But what does it take to get there? Of course, this was a very... It's not like the previous example where everything's like, no, this is not in production, these are things that actually exist. No, this is very custom, of course. But it was just to prove the point. So the main thing to get some code to work within web and native is... If you look at this code, this is basically the one that I was using earlier, is that we have this web API. We have this navigator with the getBattery and it's something that we don't have in React Native.
7. Implementing Web APIs for React Native
Web APIs are well-defined and standardized ways for web coders to interact with the browser and access extra features. Implementing web APIs for React Native would require intentional implementation of only the necessary APIs for our products. It would also involve pay for play, implementing APIs for multiple platforms. We aim to make the bundler smarter and have taken the open-source route, as we are committed to open source. We started with an RFC, which is public on the RnsKit.
So how do we deal with that? Well, first off, web APIs, what are those? If you don't know, you probably all know, but basically these are the ways that the web coders, they can interact with the browser to get extra features. And the nice thing about them is that they're well-defined and standardized. This means that if you need to interact with the battery, there's the battery API there. And that's the way it's supposed to be interacted with, like the methods, what comes back from it, that's all defined. You don't need to come up with your own solution for it. You don't need to say, how am I going to call this method? How am I going to pick up the battery level? You just use this web API. And there are a lot of those of course for all the web. It's more than 1000. And because it's standard, it means there's no room for interpretation, which is something that is very, very interesting because all of a sudden, it's just a matter of implementing it, right?
Of course, we don't have it for Act Native, but the more we started thinking about it, the more we were like, huh, what would it take? So we started doing a bit of an investigation and we basically did a massive script. You don't need to read any of this, don't worry. We were like, okay, let's take all the interfaces. Let's filter out the ones that we don't want. And let's check how many of them we are left with. And basically from 1000, we went down to 200, which is like, okay, this is still a lot. So what we realized is that if we were ever to try something like this, to implement these web APIs for React Native is first off, we need to do it intentionally. We only implement what we need for our products. The second thing is, of course, is a pay for play. If we were to implement a web API, we need to implement it for Android, iOS, macOS and Windows. If we implement two, we have like eight different implementations. In your final bundle, you only need the specific one. In the iOS one, you need the battery for iOS. We needed to figure out a way to make the tooling, the bundler smarter. Of course, we tried to go for the open source route because we want everyone to benefit from it. We believe in open source. I'm from Microsoft. Some people are still like, huh, Microsoft and open source? No, we really are committed to it. I can swear by that. The first thing we did was an RFC. We did this RFC earlier this year. It's public on the RnsKit with having conversations.
8. Big Picture RFC and Collaboration
This is the big picture RFC where we gather ideas and collaborate with meta engineers. We aim for transparency and collaboration. If you're interested, please read and comment.
This is like the big picture RFC where we're trying to, you know, gather all the different ideas. Of course, for us, this means that these things need to work on iOS, on Windows, and MacOS. I wanted to very quickly call out the fact that we've been talking with the meta people, the meta engineers, on this RFC. The goal is very much to collaborate. We really want this to be as transparent and as collaborative as possible. So also, really, if you're interested in this problem, like, this RFC is where we're trying to solve the big picture conversations about it, so please have a read. I already know one person in this room that left some comments, so thank you. Let us know your thoughts, it's there. It's for you to read and comment.
9. Next Steps and Collaboration with Meta
The next step is to work on improving and adjusting to the requirements that come up in the RFC. The battery status web API has been merged and is in POC status, working on all four platforms. We have also improved the initial filtering script by creating a better tool with Rust to make data-driven decisions. This is the grandmaster plan that is still experimental and requires more work. We are looking forward to collaborating with Meta and sharing solutions.
Of course, the very next step after that is what I was showing you earlier. There's actually a pull request that you can go to, it's a draft pull request with all the instructions to run it locally. But basically we did a battery API, sorry, battery status API, which also turns out, it doesn't really, it's deprecated because security reasons. So we're like, we picked one, and we picked the rawest possible one. Like, eh, whatever, it's just a PLC. So it works good enough.
Of course, the step after that, because now we've been working on this for a couple of months, is that we are still improving. We're still learning a lot. We're still trying to make things better and adjust to the requirements that come up in the RFC and those things. So for example, for the battery status web API, we did end up merging the PR. And it has all four platforms working, so you can also test it on Windows and Mac OS. And it's still very much in POC status. Like, it's just there to prove the point.
And then the other big thing that we've improved on is that initial filtering script that we're showing, we've binned it, because we're like, well, it's very much arbitrary. We were like choosing kind of like out of the blue, like which ones we wanted and which ones we didn't. So we made a better tool with Rust to kind of like go through a code base and figure out which web APIs are used in that code base. And that helps us in making data-driven decisions, which is very important, especially for something of this size. So, yeah, this is pretty much it. It's like the grandmaster plan. What me and my colleagues have been working on, what we'll work on a lot still. Of course, it's very much experimental. So please don't take this to production anywhere. It's not ready. It's going to be years probably before it's in good shape for that. And of course, I was mentioning earlier that the idea is to and we've been interacting with Meta. Meta has already put out a few RFCs of their own, a few blog posts in this area. So we're really looking forward to collaborate more and share as much as we can as we go along the way and figure out together the solutions. But yeah, closing. We're slightly over time. So I'm going to be very quick.
10. Raising the Bar and Universal Code
We've been integrating the developer experience as much as we can, putting everything in open source. But it's not enough. We're trying to raise the bar and make this web code into universal code. Collaboration is key, and this is worth investigating. Once we get there, if we get there, that's what truly Invisible will look like. You will only write your code once, in your browser, and it will work on all platforms.
Developer experience is part of Microsoft. We've been doing a lot. We've been integrating the developer experience as much as we can. We've been putting everything in open source so that everyone can leverage those, but it's not enough. So what we've been doing is trying to raise the bar, make it so much better, and making this web code into universal code. At least right now it's in this experimental phase and we really think that collaboration is key and this is worth investigating. So maybe next year I'm going to have an actual talk where I'm going to tell you, ha, this is actually working. Ha ha, I was right. We'll see about that, but probably it's going to be. But what I think is that once we get there, if we get there, basically that's what truly Invisible will look like. You will only write your code once, you will write in your browser and then magically the code will work on all the platforms. And yeah. Thank you so much for listening to me. These are a bunch of things. That's me. Thank you.
Implementing Web APIs and Compatibility
We're currently implementing a web storage API and have plans to work on other web APIs. Our intention is to enable developers to take their web code and make it work in React Native. This is the opposite of React Native web, where React Native code is taken to the web. React Native web is a great solution for expanding a React Native app to the web. As for the reasons to use RN web web APIs versus something like Lonic, I'm not sure.
So we have a lot of questions coming in. We'll start with the most exciting. What web APIs are you most looking forward to when using React Native? I think that right now what we're looking for, we already started implementing the next one. And we want to implement it one more properly is on storage. So we're implementing a web storage API. So that's probably the first one we're going to do next. We do have an issue open on the OrangeKit repo where we're trying to shortlist the ones that we're planning to work on. And if you want to work yourself on one, you can leave a comment and they're like, hey, I want to work on this. We do have, for example, Matt Harget that already announced that he wants to work on the ones around multimedia for VR. So yeah, it's very exciting that as soon as we started delivering more on that, other people started jumping in. So we can split the work and everyone can work in parallel. So right now we're focused on storage, next.
Perfect. Thank you. And another question, does this mean your web code needs to be written using React Native web or similar? Okay, so the the over-intention is literally that you take your web code and that works in React Native. So in a way it's kind of like the 180 of React Native web. React Native web is like you write your React Native code and you take it to the web. So like you write your view text and does get ported to React Native web to web via React Native web. This approach is kind of like the 180 of that. Like you have your web code and so you write your div, span, p, and those work in React Native. So yeah, it's kind of like the opposite but not in like throwing shade on React Native web. It's an awesome project and if you have a React Native app and you're trying to expand to web that's probably the right solution for you. It's not just what we need internally. Thank you and we've only got five minutes. I'm gonna have to try to rush through as many as I can but does this mean that web codes need to... Oh sorry. I just said that one. Okay. What are the reasons to use something like RN web web APIs versus something like... is it Lonic? Honestly, I don't know.
Exploring Ionic and Universal Components
Ionic is a great project, but we chose to focus on React Native as it aligns with what we know and have been doing. We believe in the concept of universal components but emphasize the importance of platform-tailored UIs. The UI should reflect the OS it's in to provide a natural experience for the user.
Iconic? Yeah. So Ionic, I think it's a great project. I think we didn't explore that option. We are just like... we are focusing on what we have control over and what we know. So React, we use those a lot. So I don't even know if Ionic supports desktop platforms. Maybe they do, but like for us it was more natural to like... okay, let's build on top of what we know, what we've been doing so far. Let's keep the direction.
So I think Ionic is a very valid product. It's not just like what we are confident we can quickly work on. So we just kept staying React Native with this web APIs approach. I love it and another one which has five likes. You are sharing business logic. What do you think about universal components and UI rendering? Oh boy, this is gonna get me cancelled on Twitter, isn't it? No no no. So I'm gonna say I, for example, love Tamaguy. I love Nate. He's been doing some great and very smart stuff there. We do have our own design system libraries that we are aiming to get to the universal point. I still think that we need to separate having universal components from a universal API. The UI should be a reflection of the OS it's in. It should feel natural to the customer. So like if you're on Android, you don't want an app that looks like iOS. You want an app that looks like Android. So even if like you're using the same button from the same design library, you need to keep in mind that your user is on their platform. So you want to platform tailor your UIs, even if your components are universal. Thank you. That was a nice dodge, like literally dodging. Yeah.
React Native Usage and Peculiar Cases
At React Native Europe, we talked about how we use React Native for Copilot AI in various platforms. It's a peculiar use case, but we use it a lot. Watch Kader Fossani's talk from React Native Europe to learn more about our different use cases.
I love how everyone caught that as well. Love the self-awareness. Yeah. So, can you share any fresh cases where you used React Native? I'm gonna reply, of course it's Microsoft, it's big, I do not necessarily know everything that's going on. At React Native Europe, we talked about the fact that for Copilot AI in the various platforms, we do use React Native in certain ways. It's a very peculiar use case, but we do use it a lot. I would recommend watching this talk by my manager, Kader Fossani, from React Native Europe to learn more about all the different ways we've been using it because there are a lot. We're not just doing an entire talk, just like, hey, here's the entire catalog. So yeah, there's a lot of those.