In this episode, Robin and Mazen chat with RN release team members Lorenzo Sciandra from Microsoft, and Riccardo Cipolleschi from Meta, about the fresh new RN version 0.72. If you're interested in what you should be looking for in this latest RN release, then this episode is exactly what you're looking for.
In this episode, Robin and Mazen, chat with RN core team members Lorenzo Sciandra from Microsoft, and Riccardo Cipolleschi from Meta, about the fresh new RN version 0.72. If you're interested in what you should be looking for in this latest RN release, then this episode is exactly what you're looking for.
This episode is brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.
Helpful Links:
Connect With Us!
Jed Bartausky:
Welcome to another episode of React Native Radio Podcast. Brought to you by waffles, because what better way to start your day than a carb loaded punch straight to your midsection. Episode 270, diving into React Native 0.72 with Lorenzo Sciandra and Riccardo Cipolleschi.
Mazen Chami:
So Robin, any chance you have like four, five grand laying around for the new Apple glasses, or whatever they're called?
Robin Heinze:
Apple Vision Pro. I think I'm going to skip this version, but I'm pretty sure someone on our team around here is probably going to go buy some and I'm very excited to see what they're like.
Mazen Chami:
Yeah, it was interesting to see it happen. They spent a lot of time on the video part of it and demoing it, and the dev kit part, which was interesting. I usually look out for the iOS versions because those are the ones that are more fun to me.
Robin Heinze:
Yeah, the iOS updates were pretty cool. Of course, we're talking about WWDC, the keynote, which I'm sure all of you listen to around here. It's practically required watching.
Mazen Chami:
We stop what we're doing and huddle and listen to it.
Robin Heinze:
It's true though. We all get in a room and watch it. But Vision Pro, lots of message updates. A triple guitar?
Mazen Chami:
Who knows who came up with that idea. Do our guests, who I'll introduce shortly, do any either of you have any opinions of how that went?
Lorenzo Sciandra:
So about the triple guitar, I'm going to put on my team for that. I'm really deep into post-production and stuff and I think there was some CGI involved in that. It didn't feel as heavy as it should be. I don't know about that, but no, overall I watched it all. Well, almost all, but yeah, I had a meeting. Sadly, we don't have that policy in here.
Riccardo Cipolleschi:
I enjoyed the keynote overall. Of course, I'm an iOS engineer so my heart is on the Apple side for a bit, but there is one thing that didn't digest really that much because they claim to be the first one doing the Vision Pro, or revolutionize the augmented reality space, which is, it's a lie. It's at least a couple of years that Meta is doing that.
Robin Heinze:
That's pretty classic Apple.
Mazen Chami:
Yeah, they've done that a couple times, I feel like.
Robin Heinze:
They're like, we're the first. No, definitely not the first.
Lorenzo Sciandra:
Android did that.
Robin Heinze:
Well, who can forget the original Google Glass?
Mazen Chami:
Yeah.
Robin Heinze:
What was that like 20 years ago now?
Riccardo Cipolleschi:
Something like that.
Robin Heinze:
We all know how that went.
Mazen Chami:
Android has had a bunch of stuff that iOS eventually comes out with. It's like revolutionary, but it's like Samsung or Android has had that for 10 years, has it been?
Robin Heinze:
But it was entertaining to say the least. I am excited about some of the message features and FaceTime voicemails are actually one of my favorite features from the release because we FaceTime grandparents a lot and they don't pick up, and it'd be fun to be able to leave messages.
Mazen Chami:
Well thanks to you, Robin, I downloaded the beta so probably after this I'll be playing around with it.
Robin Heinze:
Yes, if you're part of the Apple developer program, which all of you should be, if you're React Native engineers, you can download the beta release if you just go into your software updates tab.
Lorenzo Sciandra:
Yeah, I just hope that it didn't break anything like iOS 17 and Xcode 15. Every year the first day of beta, someone opens an issue in the React Native repo and just say, "It doesn't work with this." Like how?
Robin Heinze:
Of course it doesn't.
Lorenzo Sciandra:
It's been 24 hours.
Robin Heinze:
Give us a minute, please.
Mazen Chami:
Xcode hasn't finished downloading yet.
Robin Heinze:
Has it happened yet? Do you have any issues yet?
Lorenzo Sciandra:
I didn't want to check to be honest.
Mazen Chami:
I don't blame you.
Robin Heinze:
You don't want to know.
Riccardo Cipolleschi:
I downloaded that but I haven't had the time to try it out today, but I will do so tomorrow.
Mazen Chami:
Cool. As you may have noticed, I'm not Jamon. Jamon's on a plane currently returning from Render Atlanta. I'm Mazen. I live in Durham, North Carolina with my wife and baby boy. I'm a former pro soccer player and coach and a senior React Native engineer here at Infinite Red. I'm joined by my outstanding co-host Robin and our two very special guests who I'll introduce in a minute. Robin is the lead engineer here at Infinite Red. She's located west of Portland, Oregon with her husband and two kids, and has specialized in React Native for the past five years. Lorenzo Sciandra, who you probably know as Kelset, is a senior software engineer at Microsoft and has been a maintainer of React Native since 2018, version 57.4.
Robin Heinze:
That's a long time.
Mazen Chami:
That's a long time. And he lives in London, UK. Our other guest, Riccardo Cipolleschi, is a software engineer at Meta with a primary focus on iOS. Prior to that he was an iOS engineer at Bending Spoons, and he lives in London, as well.
Robin Heinze:
We are super excited to have you guys on. I think this is our first time having people from the React Native release team to talk about a release before and we're super excited.
Mazen Chami:
Hopefully we can keep this going because there's a lot of content that we want to cover and hopefully we can get through all of it here today.
Robin Heinze:
Yeah, we're going to try not to read the change log line by line, but we want to hit the exciting bullet points.
Lorenzo Sciandra:
All of those 1000 lines.
Mazen Chami:
Yeah, exactly. Of course, this episode is sponsored by Infinite Red. Infinite Red is a premier React Native design and development agency fully located remote in the US and Canada. If you're looking for a React Native expertise for your next React Native project, hit us up at infinite.red/reactnative. Don't forget to mention that you heard about us through the React Native Radio podcast.
Robin Heinze:
I like the forward slash. It made me feel like I was in like 1995 and they were reading out URLs like http colon forward slash forward slash.
Mazen Chami:
Could have done that. Well, https.
Robin Heinze:
Oh, yeah. Well they didn't have S back then, did they?
Mazen Chami:
Okay. Let's get into our topic for today, diving into React Native 0.72 with Lorenzo and Riccardo. Before we dive into the topic specifically, I'd like to hear from you guys, a lot of the listeners and developers out there probably have seen your avatars out there. You've closed their issues, I'm kidding. Or helped merge their PRS out there. Can you tell us a little bit about yourselves and how you got to where you are now?
Lorenzo Sciandra:
Sure. Hi everyone. I'm super happy to be back here. I think last time I was here it was super long time ago.
Robin Heinze:
I think it was probably before we took over the podcast, I'm guessing.
Lorenzo Sciandra:
Could be, yeah. Yeah, it's been so long. But yeah, hi everyone. I'm Lorenzo and yeah, I'm super happy to be here with you all today. To share a bit about myself, I started in React Native when I was in Italy right after university. I was working for a small consultancy and all of a sudden we had a client with a project that involved, bought a full stack backend, but also frontend mobile and they said, "How about you try and find something that works cross-platform?"
And I was about to go with Xamarin and luckily in the meeting where I presented my idea, someone very senior from the company side, how about React Native? And I was like, I had never heard of that, and from that moment onward that has basically been the thing that dragged me more and more and more into itself and I've been growing ever since, moving to London, changing from startups into consultancy, now at Microsoft, and now I'm basically, my full-time role is pretty much doing whatever is needed for React Native to be better. So yeah, it also involves being part of the release crew and helping, making sure that the new releases are good and stable.
Mazen Chami:
That's awesome.
Robin Heinze:
Awesome.
Riccardo Cipolleschi:
So about me, I used to work in Italy for a company called Bending Spoons when I did six years of only iOS development, nothing more than that. And moving to London, working for Meta, I wanted to expand a little bit my knowledge as a software engineer and I found in React, in the React org, and React Native specifically, like the best fit because as everyone know, it's not just iOS but there are plenty of other technology involved, and I really like the idea of working with different technology. At the same time I'm working with a team which is specifically heavily involved in the open source and part of our responsibility is doing releases. It's very fulfilling kind of task to release a new version of React Native and to interact with the community. So that's how I got here.
Robin Heinze:
That's awesome. Before we actually get into 72, I'd also like to hear just a TLDR about what goes into a release, or a release cycle. You're constantly doing work on React Native, but where do you decide, okay, this is where we're going to draw the line and do a release. What sort of phases does it go through before we as developers get to install it?
Lorenzo Sciandra:
So that's a great question to be honest. And the answer has not been the same throughout all the years of being a releaser. We actually now are in a place where I'm honestly excited by how we do releases, and it all starts with the release crew. The release crew is composed of two people from the Meta team and two people from the community. And these four people, once they get the baton from the previous release crew, that's when everything kicks off for a new miner, in this case 72. So for example, in this specific scenario what happened is that me, Riccardo, Mark from Shopify, and Luna, again from Meta, we got the role, the responsibility and now we are the people responsible for all the releases for all the miners that are part of the release support window, which means working on 72, but also working on 71 the current latest, and 70 and 69.
Once the crew gets formally in place, that's when they get basically the driving wheel. So it's up to them to define a good point for the cut. That usually means communicating internally with Meta and defining, okay, do we have all the features that we want and that we need? Is the main branch in shape, ready for providing a good commit for a branch cut? And then at that point, once we fully define, okay, it's going to happen on this day at this point, so basically that means we get a green light from Meta. At that point we create a branch and then we start the RC process. During the RC process, that's when we tried, with help for the community, to figure out all the problems and all the things that weren't detected while the code was only on main.
So we do these release candidates basically and we ask the community, the library maintainers, to try them out. That's where we figure out and find all the main bugs. We address them, we do new RCs, and then once we feel confident that we're good to go, we do what is called the golden release candidate. In this case for 72 we were hoping the 72 point, the RC three was going to be the golden one. Then of course, as it always happens when you actually say, okay, this is the golden one, a bunch more people try it out, things break, and then you need to do follow-ups.
Robin Heinze:
So it's not really golden. It's like bronze.
Lorenzo Sciandra:
Yeah, well I mean in retrospect, but no, we want to be optimistic. We're like, no, no, this is-
Robin Heinze:
Well, you have to call it golden so that people will try it.
Lorenzo Sciandra:
Exactly. Exactly. Exactly.
Robin Heinze:
Yeah.
Lorenzo Sciandra:
But let's not tell anyone about this. It's going to be our little secret. But no, once we get to the point where we do the golden people actually test it, things break, we fix those. At that point we give a grace period of, usually it's one or two weeks, for the proper latest RC to kind of sediment and people to do some more testing and report if the problems that they have surfaced are fixed, and then that's when we say, okay, now this RC, no one has been reporting new issues. Let's find the data that works for the release crew and let's aim to do 0.0 at the first available time. So in this scenario, our original deadline when we said RC three is the golden, I think 72.0 was planned to be the last week of May. Basically right after a chain react, then a few more issues bubbled up.
So right now, well at the time of the podcast being out and everyone listening, it means that we finally reached that day and if, fingers crossed, everything goes well, this means that it's around between the 15 and 20th of June. So that's pretty much what it goes into. So there are four people constantly working on them, getting all the feedback from the community, trying to figure out how to fix the problems, and then producing the new releases so that we can get this feedback loop constantly going to the point where we're like, okay, the signal is good. We feel confident in getting to 0.0.
Robin Heinze:
That's really interesting. Did the four of you on the release crew, is this your full-time job or are you doing this on top of what you normally do at Microsoft?
Lorenzo Sciandra:
I think when we make people sign their souls into being part of the release crew, no, we ask them to account at least four hours a week for doing release crew work. It's actually a bit more than that, usually, if something goes wrong or we need to backport certain fixes to all the releases, but in general it's not the only thing you do during your time in the release crew. Also because, especially for us in the community, our companies may not see as much value, like okay, I'm losing an engineer for an entire two months. So it's usually a balancing act and that's why we have four people. For the longest time it was me and Mike Rabowski, so even one or two people. But with having four, at least two people can always be around. So it's a balancing act basically. But yeah, I think four hours a week on average, that's probably still a good estimate.
Robin Heinze:
And you said you rely a lot on people in the community and library maintainers testing these RCs to sort of progress the release and polish it. Do you have a direct channel to these folks where you can ask them to test certain things or give them a heads up, this particular thing changed, can you test it, how do you ensure that it's been tested thoroughly enough?
Lorenzo Sciandra:
Another great question. It's an exercise of trust in a way. What we try to do is communicate as much to the general public as possible. So in the GitHub release for the pre-release, we always say, "Please test it. Here's the link, here's how you have to do it. This is where you report back." But also, for example, in some of the open source project that we as Microsoft own, we have CI that tests against nightlys and we also test against the RCs. So that's the first direct way of testing that at least the baseline works. And on top of that, especially for some key library maintainers, we have some direct communication channels where we say, "Hey, library maintainers, please test it." And usually that helps a lot, especially towards the starting part of the RC phase, because that's when library maintainers are most likely going to eat some problems and we then need to fix or address. So yeah, usually we try to get the library maintainers, especially for big libraries like Reanimated-
Robin Heinze:
I'm saying like React, Navigation, Reanimated, the ones that most of us have installed, you really, yeah, you really want to make sure they're solid.
Lorenzo Sciandra:
Yeah, we try to get them to test early and then to also test when we think it's good to go. And in this scenario specifically, there were a couple of things that now the libraries need to fix on their end. So that work is a constant back and forth to really try and make sure that at least when a new release comes out, people can upgrade because the libraries are already caught up, at least the main ones.
Mazen Chami:
I really like that because it's really closing the loop in on there having to be a lag. So let's say you release 72 then as a library maintainer, then I need to now come in, digest everything, test it, make up necessary updates, and then cut a new release. So not only is there the lag of the update, there's also the lag of your packages. So you guys working side by side with them I think is an amazing thing for the community in general. And if you are a library maintainer on the community, I'm sure they could also give some feedback too, even if they're not part of this group or whatnot, their feedback is also valuable because they might have a subset that you might not be targeting specifically in your testing, but they get to find out early and then kind of help prevent any issues down the line, especially. So I really like that.
Robin Heinze:
I mean it's really mutually beneficial too because if React Navigation isn't working with 72, people aren't going to upgrade to 72 until it is, and so the sooner you can get support from both sides. Yeah.
Lorenzo Sciandra:
Yeah, absolutely. And just to be clear, that's also why the first place where we look for feedback is the discussion, because those are open and any library maintainer can submit their feedback and everything. And also, this is a small teaser, we are going to publish an RFC soon-ish over the next couple of months. Basically we want to try to make the communication toward the library maintainers better and also provide them similarly to what we have, like the upgrade helper that kind of gives you a default, like the changes you need to do in your app. We want to have something similar for library maintainers. We want to have some more guidelines and also diffs for library maintainers, but it's still in the works, but we are in the very, let's say, experimental phase of trying to figure out how to do it, but over the next couple months an RC should come out, which will have a detail of, okay, library maintainers, we're going to try to make life easier for you all through these tools and automations.
Robin Heinze:
That's awesome. I mean I know the upgrade helper completely changed my upgrade experience, personally.
Mazen Chami:
Oh yeah, me too. Yeah.
Robin Heinze:
I'm sure whatever you come up with will be awesome. Let's actually talk about the meat of 72. It seems like the sort of headliners coming out of it are some Metro improvements including Symlinking, which I know we and a lot of people have been asking for Symlinking support in Metro for a long time. Can you talk a bit about the Metro updates that are coming through, what Symlink support is, why it's a big deal, and then maybe we can touch on a couple of the other Metro updates?
Riccardo Cipolleschi:
Okay. Yes, so Metro Symlink was the number one issue in the metro open source repository, so it's something that really requested by the community. I got some notes from the developer experience team in Meta because it's not directly my area of expertise, so I'm not going to say silly things, but basically to understand what Symlinks are and why it's such an important thing, we need to talk a little bit about what Metro does. I'm sure that most of the audience know that already, but for the people that are approaching the framework for the first time, Metro is basically the thing that package all the JavaScript files in your bundle, in your app, React Native approximately, and provides those files to the app itself. So it is the thing that packages all the JavaScript files and allow the Native side to interpret them and render your views and run your JavaScript logic.
To do that before 72, Metro needed all the proper path, let's say, to each actual file inside your application and eventually your node modules inside your libraries. Something that does not really work very well in some more advanced scenarios like Monorepo's software, node modules are not really on the same structure, but they have these Symlinks which is basically a folder which says that it contains the files, but the files is not really in that particular location on disk, but there is actually a link to another location on your disk saying that actually the file is there. So Metro was not able-
Robin Heinze:
It's like a shortcut.
Riccardo Cipolleschi:
Yeah. Metro was not able to follow this shortcut to the real path of the file. And solving this issue allows for these more advanced kind of scenarios where the file is not really there but you have a link to a file and Metro can now follow it. I've also some more low level details that the team share with me. I thought why it was so difficult to pull it out in the first place, and we have to wait so much time, but I don't know how much in the technical details we can go.
Robin Heinze:
I know there's a really fantastic talk by Alex Hunt, which he gave at App.js Conf, which we'll put in the show notes and that, I think, goes into a lot more detail about the Metro changes.
Riccardo Cipolleschi:
Yeah, Alex gave this talk. There are not a lot of details specifically on Symlinks on the technical side on the talk, but there is a lot of good content on other feature we are going to talk about in a few minutes.
Robin Heinze:
I know personally we ran into this issue, oh gosh, it was probably three years ago now, where we had a web and mobile Monorepo and we wanted to Symlink shared code. And what we ended up doing was basically keeping everything within the React Native app and then the web approximately, so Symlinked into the React Native app so that as far as Metro was concerned, they were all real files, and that was how we got around that. But Symlinking in Metro has been something that people have been talking about for a long time and it's really nice to see it finally land. There was a couple other Metro changes including package exports, which I think is primarily a feature that package maintainers will care about. I didn't know a ton about package exports because I don't make packages.
Riccardo Cipolleschi:
So again, the team shared some notes with me so I can try to shed some light here. Basically, as far as I understood, before this change, not all the package available on NPM could be used inside React Native because they were not compatible with how React Native handled packages, basically. This change increased the compatibility of React Native with all these JavaScript packages which were using those features that were not supported by Metro. Keep it simple. So now we can use packages that before were only working with Node or Webpack for example, and now can work without changes, also React Native.
Robin Heinze:
Cool.
Riccardo Cipolleschi:
One thing that the team highlighted and I need to stress a little bit here, is that these features are kind of in a beta experimental stage, so it's really important that everyone that is interested in using them, try them out and report if something is not working so that we can address them, address those issues and improve the experience for everyone.
Robin Heinze:
Definitely. I think that's going to be pretty clear in the announcement that they're beta features, but test them out, report back and it's still very exciting to see them. So yeah, the TLDR with the Metro improvements is go watch Alex Hunt's talk and it seems like in general there's a big focus on developer experience improvements and I think that applies in some other areas, as well. Mazen, I don't know if you want to go into the other developer experience improvements that were in the release.
Mazen Chami:
Yeah. Developer experience is something that I'm always stressing to our clients that hey, this is something that React Native is going to bring a lot of developer experience to the table to help me make your lives easier and we'd leverage other things like TypeScript and ESLint and all that kind of stuff just to make things very simple. Now I will say the one thing on here that I want to touch on probably first, even though it's potentially subtle, but now that you don't see that undefined as not a function, that red box, that very random and vague red box, now it says X is not a function, it's undefined and you get pointed towards it.
Robin Heinze:
It's such a subtle change and it's so, so impactful.
Mazen Chami:
Yeah. Yeah. I feel like it's huge. Yeah, Robin, you said it's so subtle, but at the same time it's going to help all the developers out there debugging and kind of get to the solution quicker. Another one that I saw in here was the invalid style properties no longer shows a red box. That might just seem trivial, but even-
Robin Heinze:
That's kind of the opposite effect. It's like it's not interfering with your workflow so much for errors that really don't break the approximately. It'll tell you, but it's not preventing you from continuing.
Mazen Chami:
Yeah. So most of these are just either removing stuff that's not relevant or slowing you down, and then giving you tools to speed things up. Other things like filtering out bytecode that isn't relevant for Hermes errors. I feel like for the main developer up front, that really necessarily doesn't really matter. That's all under the hood related stuff. React Native CLI error output improvements. Hey, we could all use that help to be able to debug our issues that kind of come out there.
Robin Heinze:
It's not showing you stuff that doesn't help you, and when you do need help, showing you stuff that's more helpful.
Mazen Chami:
And I know Riccardo, you had a point on the whole developer experience in general, right?
Riccardo Cipolleschi:
Yeah. Referring again to the Alex Hunt video and talk at App.js, Meta is doubling down a little bit on the developer experience for React Native. The team has grow last year and we are very invested in trying to improve the bugging experience of React Native, especially from the web perspective, and try to make it easier to work with our framework. We use a lot also the input from the community and we are collaborating with some partners to try and improve the old stack trace situation for example. So yeah, we really care about the developer experience, a great experience, and we are trying to make it better for everyone.
Mazen Chami:
And we do see that, and we do feel that as developers. There's a lot of stuff that's come a long way and just making our experience at the keyboard that much simpler.
Lorenzo Sciandra:
Yeah, and I mean also from the perspective of one of these partners being Microsoft, developer experience is paramount for us. We really need to be able to have hundreds if not thousands of engineers being able to use React Native and deliver quickly. So the developer experience is very, very important, especially because internally sometimes we need to compare React Native to other technologies, and so having a good developer experience is very important and we are happy also that most of these conversations, or at least a good portion of them, are happening in the open. There's a dedicated working group similarly to the new architecture one and some others that is dedicated to the developer experience. It's under the React Native community org. So if you want to check out some of the discussions that are happening between these partners, you can find the notes of the agenda of the meetings in there.
Robin Heinze:
At Chain React, there was a talk by, I think it was Kadi about building a five-star app, and this reminds me of that because it's like you can build all the cool features in the world, but if a developer has a bad experience when they have an error, that's all that they're going to remember. So the more you can improve that, minimize that negative experience, that's going to be more impactful than cool, shiny new features ultimately.
Mazen Chami:
Yeah. Lorenzo, you were joking about people opening an issue at the first day or release. This is another scenario where-
Robin Heinze:
People like to complain.
Mazen Chami:
... the developer has a, exactly. You're not going on there to give a positive review most of the time for the restaurant. You usually go on there to complain about hair in your food.
Robin Heinze:
Do you ever get issues where people are just like, I just opened this because I want to say how awesome you guys are?
Lorenzo Sciandra:
No, I've seen sometimes there is that month of maintainers, where maintainers are celebrated, and I see some of these smaller, more open source centered communities having all these screenshots of good things and I'm like crying in the corner. And by the way, this doesn't mean that now you need to come into the React Native issues and open ... We're trying to get the countdown, so it's okay, I know that you like our work.
Robin Heinze:
Don't open issues just say thank you.
Lorenzo Sciandra:
It's okay. We know you like it.
Robin Heinze:
Maybe just tweet about it once in a while.
Lorenzo Sciandra:
Yeah.
Robin Heinze:
So I want to talk about another pretty significant part of the release, which is the mitigation for the Android text input ANRs, which stands for application not responding or application not responsive. This seems like a pretty big deal, partly because you guys are doing backported releases, which I don't, have you guys ever done backported releases before?
Lorenzo Sciandra:
All the time.
Robin Heinze:
So just a quick summary. There's an issue around multi-line text inputs on specifically Samsung devices with Grammarly enabled, I think. So it's a really specific situation, but I mean there's lots of Samsung users out there and so it was actually impacting quite a lot of people. How did this issue get discovered? How did you find out the root cause, and then how did you decide that you needed to backport older releases?
Lorenzo Sciandra:
Yeah, I think that this problem specifically has been ever a true test of all the processes and all the work that we've done over the last couple of years in how to handle releases, how to handle problems from the community, because this was originally a problem reported from the community. We didn't pick it up at Microsoft, we didn't pick it up at Meta. And to be even more specific, it was only on Samsung devices with Android 13, with a very specific version of the Samsung device, it was like how do you even realize that that's where it comes from? But no, I mean of course you have crash reporting that literally tells you it's this very specific series of things, but it was so complicated to figure out even what was going on.
And that's why also, yes, 72 is going to be the first version to have it out the box for everything else. We had to add it as a patch release. The problem there was that because it was so specific and it required basically to have a physical device with that until we had the proper repro, until someone from the community opened the proper issue with an actual repro that was properly reproducible, you could take that code, go into a Samsung device and try it out. It was very, very hard to understand what was actually going wrong. But once we got that Meta was able to provide an engineer to kind of work on that full time. It was also very hard to properly fix. We had to do two full rounds of patch releases. The first one wasn't good enough in a way, so it was very intense and took a very long time to fully address. So first off, a shout-out to Nick Jarliman, which he is the engineer from Meta that did the work.
And also the way we decided to do the patch, basically it was a matter of looking at the data. We have a website called rn-versions.github.io, or something like that. We can put it in the show notes. But basically on that you can see that the daily tracking of all the downloads on MPM, and how they're split between versions. And with that tool, which funny enough, it was also made by the same guy, Nick Jarliman, we were able to decide, okay, what's the baseline? What do we define as a version that we need to backport this to, or what is not tall enough to go up on the ride? I think that what we ended up doing, especially for the first round was commit to 68, because back then when we first decided the first round of patches, it was still around 10 or 15% even.
Now, luckily the numbers are much more like 71 heavy. 71 has surpassed the 50% mark in terms of market share. So I don't think we would go out of the release window, which again is 71, 70, and 69 currently. But in general, we were trying to at least fix it for the majority of the developers. I think we were aiming at 90% of the user base or something like that. So that's where we tried to use the data. We were like, okay, these many versions we can do, also because it became a practical problems. Do we even have the ability to still test those older versions and ensure that fix doesn't break more stuff than it actually addresses? So it was a very hard balancing act of like, okay, how confident are we in doing this patch versus how many people will this affect? But in the end, I think that we were able also to provide it to enough people that once the full fix was out, as it usually happens for issues that are fixed, no one wrote a comment.
Robin Heinze:
You didn't hear anything,
Lorenzo Sciandra:
That's when you know. Exactly. That's when you know that something is fixed.
Robin Heinze:
Silence.
Lorenzo Sciandra:
When you post a comment saying, "Hey, we've done this release, can you tell us if it's working?" And no one replies for a month.
Robin Heinze:
No news is good news.
Lorenzo Sciandra:
Correct. Exactly. Exactly. Yeah.
Robin Heinze:
Was that the kind of thing that would bump you and your release crew over four hours a week to try and manage?
Riccardo Cipolleschi:
Definitely. When those kind of things happens, especially when they are of this magnitude, people jumps in. The team in Meta is also the team in, the React org team that take care of working on React Native, is also very responsive and very willing to help. As Lorenzo was saying, Nick is not part of the release crew, but he was a key player in fixing this problem, together also with Nicola Corti, which helped as well. They both jump in the problem, helping out us that we don't have a huge Android experience in this case while they have. So that's a great thing. A very good vibe of the team internally. But yeah, definitely for them it took a few days of work to manage, to find a fix, and these are the events that increased the number of hours that are required for our release and nobody can really account for them when it starts.
Lorenzo Sciandra:
These number of patches actually put the average of releases that we've done in 2023, at least as of last week to one per week as average, which is crazy. We've done so many releases this year.
Robin Heinze:
Because you did like four at the same time.
Lorenzo Sciandra:
Yeah, because we had to do so many backports to so many different miners. So yeah, basically anytime there was a new fix, we had to at least account for four releases and that means cherry-picking, testing and releasing, cherry-picking, testing, releasing, and that means also producing the change logs, producing the GitHub release notes. So there's a lot, not a lot, but there's always also a bit of overhead of the communication part of it, when you do so many, like kind of a heads-up. So yeah, definitely those weeks were a bit higher than the four hours.
Robin Heinze:
Well, we appreciate it for sure. I know we have a couple of our really large projects are still on 68, I think, because Upgrade.
Mazen Chami:
Why would you throw them under the bus, Robin?
Robin Heinze:
I will not name any names, and it's not for lack of trying, it's just a very difficult version to get past because of new architecture additions and so they're kind of stuck on 68 for a while, so I'm sure they appreciate it.
Mazen Chami:
Project I just kicked off, we're on 71 and I'm going to do 72. I have a branch for 72 going.
Lorenzo Sciandra:
Nice.
Mazen Chami:
Cool. The next section I kind of want to talk about, well the first part of it is the breaking changes part, and I think I want to bring a section of this to the top first, and this has to do with the package renames. So essentially we're turning React Native into a proper monorepo. And if you weren't at Chain React, so you probably didn't hear Lorenzo's talk.
Robin Heinze:
It's online now though. We'll put it in the show notes.
Mazen Chami:
It is. So hopefully everyone's listened to it, and I'm sure people would've listened to it before this. So I guess the main point for the listeners is if you check out the link that we're going to put in the show notes, if you are using any of these specific packages as a direct dependency, you have some breaking changes so you kind of need to make some updates. Everything now lives under the react-native/packages, so it's all housed there now. So be sure to make those changes.
Robin Heinze:
React Native itself, specifically. It used to be like React Native itself was sort of at the top and then the adjacent packages were nested underneath in the packages directory, which sounded like it got really complicated.
Mazen Chami:
I feel like they were scattered. Now everything is kind of being brought home and kind of organized better. So I guess for those who weren't fortunate to see your talk, Lorenzo, in person or haven't listened to the talk yet, can you give a summary on what these improvements are and from your perspective why this was necessary to do?
Lorenzo Sciandra:
Absolutely. And also it's great to hear you try to remember my talk because you got so many things right? I was like, yes.
Robin Heinze:
It was a really good talk.
Mazen Chami:
It was.
Lorenzo Sciandra:
Thank you. You're very kind. But yeah. Okay, so let's make it easy and understandable for people. So when you went into GitHub and opened the React Native repository, you basically see the shape of a standard library. So you see all the different files, all the different folders, and then there was also a packages folder, and that packages folder was a Monorepo. So at the same time, the repository was the node module of React Native and a Monorepo, and that is very, very non-standard and you should not try this at home, so please don't do it. It will just create a lot of pain for you. This also means that doing releases, for example, meant that whenever we were cutting a branch, we would actually kind of configuration-wide, eat out the Monorepo side so that only the node module part, the actual React Native stuff, would end up in the node module.
So as you can imagine, this wasn't ideal. That also meant that to do the release for the sub packages, it was very convoluted and it was usually manual only, and so only someone from Meta at the right level of authorization to do a new release for those packages. But some of those packages were also on versions that were completely random. I think one of the packages was on 3.2.1. It's like how do you even know which version of React Native can use that package? It's like pure madness. So what we did last year almost, it's been over a year now, we sat down and we were like, okay, this needs to change. We worked on an RFC. We created a graph where we were showing the entire mapping of like, okay, there's React Native and these are all the packages, these are all the versions, these are all the names.
We're like, okay, this needs to change and let's put it in a proper Monorepo, so let's put everything, so also React Native stuff, under the packages folder and let's rename everything to be consistent, and let's reversion everything so that everything is on the same version and scheme as React Native itself. So now if you are using React Native 72 and you're using React Native Gradle Plugin, that version of React Native Gradle Plugin will follow semver, so it will be 072 something, so you know which version matches which version of React Native.
To be clear though, we haven't ported back in any packages. We only reshuffled and cleaned up the room of what was already there.
Riccardo Cipolleschi:
I just wanted to add, and call out couple of things. That this Monorepo huge effort was started by Lorenzo, which drafted the initial RFC.
Robin Heinze:
There was a really cool graph involved, which we will link in the show notes because it is epic.
Riccardo Cipolleschi:
It was kickstarted by the community actually during the React Native EU last year in Wroclaw, I hope pronounce that correctly because the name I don't know how to pronounce. And they started working on moving the packages from giving the right names and refactor the package.json file. And then one of my colleague Rozlan drove it to conclusion by the end of last year. So it was a huge community effort, which had to end up in our field at Meta because of internal staff, which are using React Native, so we had to make sure that everything was working, but you just shout out to everyone involved because it was a huge effort and makes the life of everyone easier.
Lorenzo Sciandra:
Yeah, totally. And also to bring it back to where we want to be, it took so long, especially because there was so much work involved, and without Meta there wasn't going to be doable. We really needed Meta to buy into the idea and see the value in that, and 72 is going to be the first version post this change. So that's why we were saying earlier that breaking changes are going to be mostly just renaming of packages, but it's very unlikely that you're using them directly. So just keep an eye on upgrade helper. You should see all the changes that you need to do, unless you're doing something particularly complicated, but in which case you are a advanced user so you know how to deal with these things.
Robin Heinze:
Yes, we're unfortunately running short on time, so I'll try and wrap things up, but I want to hit the rest of the breaking changes really quick because we usually like to give people a heads-up. Minimum node version is now 16. The used version is 18, but the minimum version is 16. So if you're below that, you need to upgrade. Get item layout on Flat List now has a better typing. The arguments have better typing, so that might be a breaking change. And then a bunch of components were removed like Slider, DatePickerIOS, ProgressViewIOS, which are now being shifted to community libraries, or the support is being shifted to community libraries that most people are probably already using.
I just wanted to note that I think it's a huge indicator of how strong the community support and infrastructure has become that things can be removed from React Native Core because there's a community supported option that is so widespread and well maintained that there doesn't need to be a core version anymore and that could be removed. I'm really proud of how solid the community is, especially in terms of libraries. Yeah, it's looking really good. I think that hits everything unless if there's anything that we missed that you guys want to touch on, speak now or forever hold your peace.
Lorenzo Sciandra:
Well, very quickly, just to kind of plus one what you were just saying about the community, this release is over 1000 commits. It's 1100, which I think is one of the biggest that we've done in the recent memory, and it's also possible because of so many people from the community submitting PRs. So just wanted to close it off with a shout-out to all the people that submits PR because even if it may take some time to get them in, we're improving the flows, so hopefully they get faster in, and thank you so much.
Riccardo Cipolleschi:
Yeah, on top of that, as I said at Chain React during my talk, so a little bit of shameful self-promotion here.
Robin Heinze:
Not shameful at all.
Riccardo Cipolleschi:
You can find-
Mazen Chami:
Not at all.
Riccardo Cipolleschi:
You can find that on YouTube and on the Infinite Red channel. We actually need the community to report all the use cases that we don't have internally at Meta or even at Microsoft because there are so many ways to use React Native, we can't cover it all ourself, so we really need your contribution to make the framework better for everyone. And yeah, there are many ways in which you can help out there. In my talk, I explained some of those, but we are opening some other umbrella issues. Like this morning, one of my colleague open an umbrella issue to convert part of the code base from Java to Kotlin, so if you're an Android engineer, you want to-
Robin Heinze:
I was just going to say, just this morning we had a thread in our Slack, someone posted the tweet and we had three, four people saying, "Oh, I'm going to go grab one. I really want to learn more about Java and Kotlin syntax," and it's a really great opportunity to make a contribution. So I love seeing that. I love seeing people start to get more confident about diving into something that was previously maybe sort of intimidating and scary, and now it's getting to be less. So especially your talk was really fantastic and-
Riccardo Cipolleschi:
Thank you.
Robin Heinze:
... one of our developers, Frank, actually said, he's like, "I listened to Riccardo's talk and now I'm already working on contributing." So yeah, really great to see.
Mazen Chami:
It really helped inspire people that were there to want to help out, which is great because it was kind of bringing all this together about version 72. There were 66 contributors and over 1100 commits like you said, Lorenzo, that that's a lot. So there's a lot that goes into every release, but at the end of the day, we said these issues aren't open, but thank you and the team for all the effort that you put into every release, because it helps us out a lot. And yes, it's never a shameless plug when you mention your talk, Riccardo, so check-
Robin Heinze:
See, no, it's shameless. It's definitely not shameful.
Mazen Chami:
No.
Robin Heinze:
We encourage it.
Mazen Chami:
Yes. I encourage everyone to listen to Riccardo's talk because-
Robin Heinze:
We'll put both talks from Chain React in the show notes.
Mazen Chami:
And that talk is very helpful if you feel inspired and want to help out, because there's so much more out there that I'm sure you guys would want to cover and the help of everyone will definitely help us close that loop quicker. Well, if you'd like to nerd out more about React Native, check out Jamon's Twitch stream at rn.live, which I think he's planning on rebooting soon.
Robin Heinze:
He's been taking a extended break. It's okay. He's tired.
Mazen Chami:
You can also join our Slack community at community.infinite.red. We have almost 2000 React Native developers in there. Also, check out the Twitter community rntwitter.infinite.red. If you'd like to reach out to either one of us, I'm @mazenchami, Robin is @robin_heinze, Lorenzo is @Kelset, Riccardo is @CipolleschiR, and you can find React Native Radio @ReactNativeRdio. Thanks to our guests, Riccardo and Lorenzo, thank you for joining us. This was nice to get to chat with you guys and hopefully we can have you on more often.
Riccardo Cipolleschi:
Thank you for having.
Lorenzo Sciandra:
Thank you for having us. It was great.
Riccardo Cipolleschi:
As always, thanks to our producer and editor, Todd Werth, our assistant editor and episode release coordinator, Jed Bartausky, our designer Justin Huskey and our guest coordinator, Derek Greenberg. Thanks to our sponsor, Infinite Red, check us out at infinite.red/reactnative. Special thanks to all of you listening today. Make sure to subscribe. We are React Native Radio. Robin, do you have a mom joke to close this off?
Robin Heinze:
I do. So this is courtesy of Carlin. He's one of our dad and mom joke captains over here at Infinite Red, but dogs can't operate MRI machines. I don't know if you knew that, but cats can.
Mazen Chami:
Thank you, everybody.
Lorenzo Sciandra:
And upgrade your React Native apps.
Robin Heinze:
Listen to Lorenzo.
Lorenzo Sciandra:
Yes.
Robin Heinze:
All right.
Lorenzo Sciandra:
Bye, everyone.