Raising the Bar: Our Journey Making React Native a Preferred Choice

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.