Build Faster and Scale Smarter With Rock

00:00 So we figured that up to 90% of those builds on CI that are running this Xcode build running the gradal wrapper for 30 minutes per pipeline are unnecessary. Reactive enterprise framework is a modular system. You can extend its capabilities with plugins with platforms you can replace bundlers. So we added this to just this one pipeline that does the smoke test suite.

00:26 We were able to shave off that build time for cached builds from 35 minutes to around 3 4 minutes. For me as a developer, that's sort of a lifecher in the situations where you want to check out a branch somebody else is working on and you you want to like do a real quick review. You don't have to wait for your build.

00:46 You don't have to set up everything locally. You download this thing from cache. Yeah, exactly. And the and the best thing is that you don't even need to build locally and you don't need to install the native dependency tooling. React Universe on Air, your go-to podcast for all things crossplatform. Hello everyone.

01:06 My name is Ola. I'll be your host for today. I'm a React Native developer at Col and I'm joined by Wauash and Mihao. Do you want to do some introductions? Starting with Wau. Hey everyone, I'm Wukash. Uh I also host this podcast sometimes, but here today I'm in the dual role. I'm going to ask me how some questions as well, but also I have firsthand experience with React Native Enterprise Framework for one of our clients.

01:35 So I'm going to talk about that. All right. And hi, I'm PHO, principal engineer at Colac. I'm responsible for our open source projects efforts uh parts of our R&D and uh as a part of that uh recently I'm focusing on a uh new project called React Native Enterprise Framework uh which is the most boring name for a project.

01:56 Uh but we couldn't figure out a better one yet. Uh if you want to help us out figure out a better naming uh my DMs are open anywhere. We'll talk about the name in a second. Yes, I disagree. This is a great name, React Native Enterprise Framework. Like, it's really uh descriptive to the point. Yeah. Yeah.

02:17 Yeah. Yeah. I mean, it's it's it's it says what it says and it's just boring, right? But, uh maybe it's the right name. Yeah. Maybe it's good. Maybe we're done with all the fancy names. Yeah, naming is hard. It is, right? It is. It is. And caching and we're doing both with this project. So, nice. Okay.

02:37 And uh that's exactly what we're going to be talking about today. We're going to be talking about uh React Native Enterprise Framework. So in Polish we say NF like when we talk with each other, but in English I guess somebody would try to rally. Yeah. Yeah. That's how people will pronounce it. So as uh Wukash already said, he's in the dual role here.

02:59 He he'll start out as a guest, but he told me that he has lots of questions. So So he'll be also asking questions. But let's start with uh me asking you questions. So we're going to uh kick kick off this podcast with um with a practical example. So we're kicking it off with the example of the project that Wukash is working on.

03:18 Uh we can say the name of the real project. So we're just going to call it project A. And let's imagine it's a it's a reactive application that sells computers and computer parts. So it has some specific limitations and specific features that it has to have. Um, and it's a big it's a big application.

03:38 It has a robust repo like robust a lot of files. Lots lots of files. So, gosh, can you tell us a little bit about the uh pain points that you have as a as a team leader as a developer in such a big repo for Sure. So like you said, we have a big project and it sells computer parts apparently and like we have a lot of targets in that project and we have a lot of like different variants of that project.

04:07 A lot of variants of like the outcome application. Can you give us some examples like what variants do you have? Do you have like I don't know TVs, cars or No, no, no. So we have only iOS and Android but for we have our generic app and then we have branded apps. So we have several different versions of the same app and they differ in size not only by team but also by uh by some functionality.

04:36 Mhm. And we have the generic version that is um that has a basically everything and it's not branded. So in this kind of project we we have struggled with uh with testing. So we have a a bunch of uh automation tests written for it. But in order to run all of them, it would be it wouldn't be a good idea to run all of them on each PR.

05:04 And we wanted to bring some confidence to the project so that on each PR we can run some maybe smaller test of smoke of um smoke suit test of testing. Yeah. Yeah. But ideally, if you if you have a lot of tests, it would be ideal to be able to run all the tests and be like be confident in the PR that you're not breaking anything.

05:26 Well, that depends, right? So, that's like the the comparison like sorry, the compromise between like the confidence and the time it takes to test. So, we don't want to block everyone on each small PR uh for hours to to have all of the tests run. So we figure out that we have those like let's say 10 tests that we want to run on each PR and we want to run them only on that uh generic build let's say.

05:57 Okay. So this still blocked us for 1 hour before the outcome of the testing reached the the pipeline again. So even if you had like approves on your PR and everything, you still had to wait for an hour before. Oh yeah. Because like you you want to have the confidence that your app is not breaking critical user paths.

06:16 Okay. So you wanted to to wait for the outcome of the testing. So we looked at it and around half of that time, so 35 minutes for iOS and a little bit less for Android was spent on building on native building of the application. That's a lot of time for the build. That's so actually that's the question to me.

06:39 How is this a lot of time or this is standard for native building? Yeah. So for a medium to big size project I would say it's a typical time that is spent on some medium to large workers on CI. So, it's a typical problem, but like from the point of view of the developer, it's a lot of time that they have to wait every time they want to merge some PR.

07:05 Yeah. And I knew that Miho is cooking something uh under the curtain uh for some time now. Cooking under the curtain. That's not very smart. You could make the curtain burn or something. Don't do that. Okay. So, cooking under the behind the behind. Yeah. and that he's working on something something very secretive, but I I knew what it was.

07:29 I pitched it to the client that maybe we can integrate this like freshly baked project into our So, let me like interject real quick. I I want to give context to our listeners how it happens that Miho is cooking something and then you kind of know but it's secret. Uh at COAC, we have an R&D department and Miho is in charge of that.

07:50 So uh there are there are some developers who work on R&D full-time on open source stuff and just Miho knows everything about it and it's um you like you communicate inside the company some of it right? Oh yeah like some secrets are very secretive and no one knows about them but I guess this one wasn't as secretive as some other ones.

08:14 So a bunch of people knew what Miho was doing and not only Miho like a a few other folks as well. So I approached uh our client pitching this idea. This is an like in order to unblock this effort for smoke test suit, we need to cut down the build times. We need to like shave off some time from there.

08:38 And we could integrate this React Native Enterprise Framework. It was back in January when I when we started thinking about this and uh I said probably it's going to be like around two months before it's open sourced. But what's nice about me starting doing that with some other uh developers on the project and Mihow doing the the actual work on the framework itself is that we could collaborate then.

09:05 So I took what React Native Enterprise project was at that time. I tried to integrate it. I hit some roadblocks. I hit some issues. I talked with Miho every day. And then we would solve problems either in my understanding of my project and implementation or in React Native Enterprise Framework itself.

09:30 Do you have some examples of something that like stuck out to you that was an interesting issue that the both of you hashed out? Do you remember how we found out that our project was on that one particular React Native version that used something strange, some strange name for like an iOS variable or something?

09:51 Do you remember that? I think I would need some some more pointers. Uh but wait, I I believe you. I I believe you that happened. What we basically did is we updated our project like either we downgraded just one version or or upgraded our project because it was only this one patch version of React Native that had this issue.

10:16 Yeah. Unless you're you're talking about the um like messed up scripts in the in the uh Xcode Yeah. um environment and um Xcode React Native or React Native Xcode uh shell script. Yeah, something like that. And yeah, so so there was uh there was a a change in the core that um basically changed the way that the bundle command is executed and how it's how it has the options uh from the command line passed to it.

10:50 and it didn't take into account some let's say exotic setups in the community in the community CLI and al also in expo so and also in repack. So what we did and what expo did and what exact did is uh we added some some extra uh not very obtrusive but still not very nice code into into that script and uh and that was the the workaround.

11:19 So it's it's a nice thing about React Native that we can adjust those things. Um definitely although we should definitely uh upstream those changes in the core of the of the React Native. Yeah. I was going to ask if the those changes stayed for like the next versions as well. Yeah. Yeah. Yeah. Yeah. So, so they are there um still and we just haven't prioritized upstreaming that for for the rest of the user because because it's like we actually looked at what Expo did.

11:54 They patched that to unblock themselves. Um and uh and figured okay, let's let's do that for now. uh sooner or later we're going to uh just propagate this this change uh which will likely require some some more work uh because it's it's likely affecting some internal testing and maybe maybe some scripts that uh Meta is writing internally to uh verify some some things in React Native whether they're breaking or not.

12:24 Okay. So, uh, everyone who's listening, if you have some troubles with your exotic built setup on iOS, there's a chance, uh, that you'll probably need to look for the same fix that Miho found. I think we can like move on. So, so your collaboration was successful like you, uh, you you knew that the secret project was going on.

12:44 You reached out to your client, you start integrating it, you ironed out some details, and then you did integrate into your computer selling computer parts selling app. Yes. You integrated RNF. Yeah. And then what happened? Tell tell us the success story. Yeah. So that's a P, right? So we added this to just this one pipeline that uh does the smoke test suite.

13:08 We were able to shave off that build time um for cached builds from 35 minutes to around 3 4 minutes. Uh because you you still need you still need some like glue actions. I mean from 30 minutes to three that's amazing. Yeah. Yeah, definitely. And also what's uh what's important is you still need to bundle your JS and to resign the the bundle basically.

13:39 So that takes around 3 4 minutes for both platforms. So yeah like we shave off like half of the time of that pipeline which was wasted on building. So right now this PC was successful. This pipeline is running. Now what we want to do is extend this to production pipelines as well because definitely we have a lot of savings to do there and our pipelines are basically ready for that and to unblock sorry enable developers to use this locally because like I played around with it.

14:12 it works locally but for now without this P it wasn't really a time to start discussion with the clients if we want to change everyone's dev environment to use this like new uh experimental not published yet library so I think that's that's the time now to to open up that discussion and I think you mentioned something uh what slipped in slipped in there is that you use it on one pipeline which is possible because uh incremental adoption is possible with R&F.

14:45 I think it's an important feature and um maybe if if we want to talk about RNF, I would love to start with incremental adoption because there's a lot of thought that went into that. Could you um could you tell us more about that? Miho, I can start with uh with the incremental adoption mindset. So now first maybe let's uh let's go back into what the the whole React Native Enterprise framework actually is.

15:15 So essentially from a developer point of view it's a set of tools that you can use in your uh React Native project to build mobile or TV or desktop applications. Okay. So let's get the name also out there because like the first time I heard enterprise framework I thought that it's paid because it's enterprise but that's not the goal of the names.

15:42 You said it's the tooling for React Native developers but it's called enterprise because it's for bigger apps right? Yes. Yes. Exactly. It's uh it's an open source project at this point is completely free. It runs on your machines uh either locally or in some CI environment that you have. And uh it's it's always going to be uh this way.

16:05 We're not focusing on uh providing you servers or any kind of compute. Um and and this is because um because of this enterprise part of this framework. Um so at Cosak we are working with a variety of different clients like they're building mobile apps uh TV apps web apps and uh and they're using uh React Native to uh speed up their work to ship faster and to often like unblock themselves or jump into new technology stack.

16:44 So, it's not only new apps or old apps that were React Native and are now bigger React Native apps. It's often that they're native iOS or Android apps that are adopting React Native. And what we notice is that they're all pretty similar in terms of how they approach owning their tech stack uh developing software.

17:11 they they typically uh want to have as much control over um over this tech stack. uh whether they're using uh a a UI library like React or React Native or some back-end technology, they usually already have some DevOps team that is handling their like internal cloud or has uh AWS or uh Google cloud or some some Cloudflare setups etc etc.

17:41 Uh so the these are the enterprises that we work with. They they are already established businesses often times uh multi-billion dollar businesses. So they're like it's a good business with not that great uh engineering culture or engineering capacity or sometimes with with tech depth because they exist for like 10 years and they are just trying to live with what they inherited.

18:06 Yes. Which is perfectly normal. Uh it's a it's a normal thing that the code we write today is going to be a little or more or less obsolete in a year, two or five or 10 years from now. Uh 5 to 10 is is like it's pretty pretty sure uh we're we're going to deal with with legacy code and we'll we'll need to go through extra hoops to uh to to develop in that.

18:35 So seeing seeing like all of those uh different problems that we were solving in a unique way often uh for for each and every uh client of ours we noticed that there are those similar u environments that um they operate with and we also noticed that uh we're solving the same problems over and over again.

19:00 these problems were like building a lot of custom internal tooling that were they were not able to open source uh and they were building that on top of React Native community CLI uh and just to give you some extra context most of our clients are not using um Expo CLI for example they use Expo modules lots of libraries from from that ecosystem But often times they're not able for various reasons uh better or worse adopt uh this particular framework.

19:38 So they work with whatever burr based setup React Native comes up with and it happens to come up. Can we mention real quick that React Native community CLI that's something that you worked on also? The committee CLI is a is a project that was like ripped off the core of the React Native uh where it was the React Native CLI uh back in like before 2019 or so and uh and it and the React Native CLI has actually came from a third-party library or project called RNPM or React Native Package Manager which was developed by uh Mike Graovski which is RCTO and co-founder.

20:24 So we went from some CLI some community line interface which was the only like sane interface for for react native back then it started in the open source moved to the core moved back to the core and moved back to the community in form of community CLI and now a lot of those commu community CLI modules because it's a model repo of different helpers and packages moved back to the to the core of React Native.

20:54 So we're like swinging back to the core, making core leaner and of the core, etc., etc. And uh during that time in the React Native community together with with the core team with Meta, we figured that uh it it would be great if we had a better contract between what the core team is focusing on in terms of what is React Native at the core and what is React Native at the tooling and user experience level.

21:27 And from there uh the RFC for React Native frameworks came out where the only say in the framework at the time was Expo and the alternative that users had was the community CLI which was like not very fully fledged. Yeah. It's not entirely comparable to Expo. Yeah. So it's Yeah. Yeah. It's it it definitely isn't.

21:58 Uh however, what's great about Expo there and their transition um through the last couple of years is that they instead of going sideways to the React Native uh or or even the community CLI, they made their tooling a lot more compatible with uh with what's you know not Expo CLI with what's the community CLI.

22:23 So, so today you can use expo modules uh you can use uh expo updates and uh and a lot of other like different packages help helpers that they expose in a typical React Native community CLI project. So we have this landscape of large enterprises, a lot of legacy code and most of them are using community CLI which is not a framework.

22:54 It's a very basic tooling on top of React Native and it doesn't have a really good road map ahead of itself. Uh because now that and it's missing some key points. So that's why people are building on top of it. They have their own DevOps teams and they're trying to build their own solution and that's what you notice that they're sort of building the same thing in different companies.

23:16 Yes. Yes. More more or less. And uh they fail most of the time the doing so. uh and and that's why they uh they reach out to to expert companies like call stack to help them figure out those intricacies with the react native tooling which is complex because it crosses the boundaries of JavaScript uh iOS tooling Android windows you know different different TVs some other platforms that are um coming up in the in the future so it's a it's a really really complex um ecosystem and we as the community uh React Native community we as Costack uh we just don't want React Native to be hard to use and the only ways to use React Native at the time were either Expo and if you can't go with Expo you're you're you know you you need to use this uh not very you're stuck with your own custom abstractions and utilities on top of CLI.

24:18 Oh gosh, were you using Expo in your project? No, we it's uh I have flashbacks from what Miho say uh about my project because it is a big project that was started years ago and even though it had a rewrite not that long ago, it still has some like legacy patterns and legacy code base and etc. So, and especially around those like pipelines, uh, we inherited those pipelines from previous projects.

24:50 So, we customized them, but it's still a lot of like interconnected web of like actions and outputs and caching and dependencies. So in order in that project to figure out your own caching, it's it's hard, right? It's great that Miho started standardizing that basically. So we don't have to uh keep up with our own custom implementation and maintain our own custom implementation.

25:26 It's better to use something standard and to have some knowledge build built around that in community and not like siloed in the projects themselves. You're listening to React Universe on air, your go-to podcast for all things crossplatform with React and React Native. Yeah. So, so like like Miho mentioned, you you touched on a lot of stuff and we kind of did the basics of RNF.

25:51 You were talking about caching and cloud builds. I mentioned uh incremental adoption but what Miha what would now you we've done like a little intro what would be the next thing that you would like to explain about RNF yeah so so I would like to explain the the base thing actually because uh we're exploring the history uh of the you know last 10 years that took us into uh yeah brought us into into this uh this place.

26:19 So uh what we've seen uh at uh at our R&D department uh like last year late last year is that there is a good opportunity for a new framework which means an actual good experience for those big enterprise often legacy projects uh that the commit CLI is not able to fulfill because it's also quite you know bare bones and it's even more bare bones today.

26:52 Uh because of that uh React Native frameworks RFC, we wanted it to be to the to be very basic and and very simple. So it's basically good for internally testing React Native but not very good to ship your product to uh to the users. And uh what we what we focused on is that building infrastructure. So what enterprise framework is today is like two areas.

27:24 One is the CLI which is the interface into your application to building your application. The CLI allows you to start a dev server u open a connection to emulator or or simulator or an actual device. It allows you to build your project for a particular target of your device on on iOS or on Android. And uh and it allows you to do that in like debug mode and release mode and it also like give you gives you some some extra extra toolings and that on its own.

28:06 I want to interject real quick because I'm curious about the use case for uh um connecting to your emulator. what what's the what's the use case that um you can connect to your emulator with the tooling? I mean that's a you know that's a basic reactive start uh it's it's almost the same. So so you you have the dev server that uh opens up the connection to your um to your device and it listens to the to the changes.

28:31 we have the fast refresh or hot module replacement basically. And you know what what while building this uh this project and even though uh like I say we uh this is me uh Shimon Riptac and Mata Shimsky uh who were initially helping me with uh with that project we quickly realized and even though uh we were on the daily basis like maintaining the community CLI project and it was like in the maintenance mode we we haven't done proper feature development.

29:06 in a uh in a long time and we're like falling behind expo in terms of uh you know functionality or or developer experience. We realized that building a new command line interface from scratch that developers don't even have a good experience when building their app for release mode. So uh imagine or just try to remember when you today in a in a community CLI project when you want to build or run your app in the debug mode or configuration debug variant you can do that pretty easily with uh run iOS or run Android commands.

29:49 However, if it comes to building for for release when it's uh involves signing certificates uh or then you used fast lane. Uh yeah. So so so what we what we noticed there's there's no working uh commands in the today's CLI to do so. So what people are doing they're like basically always running either fastlane or running uh gradal wrapper uh for Android manually themselves or they they run Xcode build themselves.

30:27 So they essentially reverse engineer what we do in the community CLI. Uh and this is the the part of the project that is running on those pipelines that Wash mentioned. So the the CLI is like one part of the project that connects to our like configuration system which is meant to be independent of the interface that you're interacting with.

30:54 So we hope that our system can be interfaced through CLI or through a desktop application or through a web application at some point for example and that's the way that allows you uh that that's the part that allows you as a community project to adopt our like this new framework in like 10 minutes because it's very similar in terms of the capabilities that you can do uh it can do even more.

31:24 Some things are not implemented uh either yet or or we just dropped because uh dropped some some supporting uh support of some commands that were previously available in the community CLI. We haven't brought them in uh for for various reasons. And when having that you already will have a a better experience when not only building for like locally for debug but if you would like to produce an actual APK uh or uh or AAB for Android or or IPA signed builds it will help you do that and you will be able to to achieve that in with the same tooling instead of figuring now what's what the heck is Xcode note or or what's the gradal w thing that uh someone is calling in my project.

32:19 Uh so that's one thing and another thing is the part that wukash started with which is uh caching like something that we called remote build cache. Uh so essentially having a smart way to tell whether the native iOS or Android build that you've already done somewhere either locally or on your CI is necessary to be rebuilt once again.

32:51 And what's important to realize is that in React Native projects, we're building native apps. However, like 70 to 90% of the changes that we make on a daily basis and and those enterprise uh big bigger teams are making on a daily in the daily basis are in the JavaScript realm. So they're not even touching the native files that and mostly when they editing the native files is when they're like upgrading some libraries or upgrading React Native which is not happening very often uh or bumping the version of the of the project which is happen happening like once a week or once every two weeks that depends on um on the project.

33:38 So, so we figured that like up to 90% of those builds on CI that are running this Xcode build running the gradal wrapper uh for 30 minutes per pipeline are unnecessary if there was a reliable caching. Yeah, I have a I have an idea. So how about we count somehow the amount of computing power we save, the computing time, money and and then we add some trees counter on our website to say that we are like responsible company and we are saving the planet by reducing the need to build the native builds.

34:28 Like are you you just said that nine out of 10 builds are unnecessary and those take like I said 30 minutes for Android and 30 minutes for iOS. So we are saving 1 hour of pipeline compute time. Yes. And uh and that's one side of the coin. Uh another one is that once you have that compute available like the the rest of it you're going to use it.

34:52 So you know if you haven't run end to end tests before because they were taking too long time because of the builds now you're going to run them uh and you will likely use all the available compute that you have. So uh it's very tricky to uh to to make those assessments uh because yes we are saving some compute uh say maybe saving some trees but what we also want to do is we we want to not only save time this is the the boring part uh what we want you to do is to have more capabilities and more like speed as a as a business.

35:35 So this means yeah we have some free compute let's use it in a way that allow us to ship more often basically and yeah sorry to sorry to um destroy your point of view uh on on on saving trees. No worries that it's just it's just reality. Yeah. So so we we realized that yeah if we had this this smart caching that would be nice.

36:02 uh and what we seen and what we also did for our clients is that we were focusing on caching the build process. So for Xcode we were optimizing the inputs output so that it can have a more reliable cache uh when it's available. uh we're using Ccash uh which which was helping with the C++ parts um uh because we need to build them from scratch for for React Native and React Native itself could do a lot here to let's say expose readyto use binaries instead of building it from scratch all the time.

36:41 Evan Bacon has a great post on that and uh and Jamie Burch as well. You follow them on on Twitter about caching, not about uh RNF. Uh yes. Yes. About like more efficient build caching. Uh and we thought like, hey, what if we could skip the builds, you know, entirely because they don't need to happen.

37:07 That's a that's a bold thought in React Native world and it was actually inspired by you know another piece of u I mean we had this idea we we didn't we didn't know how to properly solve it. Uh we've seen Turbo Repo um doing uh doing some smart caching based on files input. We were thinking, hey, maybe we could do some some kind of file hashing and figure it figure out, you know, essentially the the the the one uh one hash like one number that would describe our state of the native project.

37:45 And what we realized is that hey, Expo already built that. There is a project from Kudo uh from from Expo that he I think I think they they mostly built that for the sake of uh safety of overthe-air updates and so so that you can be sure that the the updates update that you're targeting with your particular new JavaScript is compatible with with the native version uh that is already on the user device because there's going to be many.

38:17 Yeah, it's smart to check. Okay. So, this is actually part of Expo. It's not an optional thing. It's in Expo. Uh, yes. At the same time, it's a standalone package. It's called Expo/fingerprint. And at at first um site, we were, hey, this maybe could work, although it only supports iOS and Android. Uh, we'll need to support more platforms in the future, but let's give it a try.

38:45 and uh Mache actually uh from from our original team uh built a proof of concept that actually worked and and gave us with the fingerprinted caching. Yes. With with fingerprint and without uh patching it in in any way. So we were able to use a library and like wrap it in a experience that's easy to use from a GitHub actions uh perspective on on a on a GitHub actions runner.

39:17 Uh if you have the GitHub uh CI this is what we first start with. Uh so so with that we had a system that allowed us to tell build or not build. So you can think about it as React on the server. We're like on our pipelines that uh we we give you those GitHub actions that you can import in your workflow uh and just run them, you know, every time on every pull request and our uh this this job that you're importing is going to figure out whether to build or not to build the project.

39:55 But you can think about it, hey, it's always being built because the output is always going to be a artifact. It's going to happen in 30 minutes or sometimes even 30 seconds and that will happen for the development builds and also which is the tricky part for release and signed builds. So for end to end testing, you don't really need to sign builds.

40:19 you can you know sign your test application with debug uh key store on Android for uh for for for simplicity. But if you if you want to test on actual uh devices um we will need to like we we needed to support this uh um this scenario. Yeah, in the long run you want to like have this tool work for everything.

40:44 So you you have to like if you want people to use this tool for their development builds and for the production builds everything needs to work like you said let's stop let's stop messing around with Xcode and that just right tool and and and once we realize that this works and we were uh thankfully collaborating with some of our clients uh in in the very early stages of of development of that tool.

41:08 one of which were was that computer project from uh from Wash that he was involved with. We also uh even before that realized that once we you know we we have those builds right so they're already built. So why are we building locally even uh we could download those uh those builds that are compatible with with our uh local state uh of of the project and have this for free.

41:41 So at the at the beginning of like planning and that was like late in 2024 of of this project. We we thought that oh we've got to build some kind of server that will synchronize like download upload synchronize the the native artifacts uh which is those APKs uh AABs uh and and APAs and ABS yeah uh between the uh CI and and local environment but what we realize is that hey we don't need that complexity because if when the developer wants to run their app on Android device, they literally type run Android.

42:24 So we figured that before trying to build the project locally, let's check if there is a cache available in the GitHub project in your GitHub action. So uh if the developer has access to to that GitHub uh space, you can they can access that with a organizationwide token for example that they can get uh for themselves or uh or or or from from a or admin.

42:56 They can download those like the CLI can download those builds uh seamlessly like under the hood for them. For me as a developer, that's that's sort of a lifecher in the situations where you want to um check out a branch somebody else is working on and you you want to like do a real quick review. You don't have to wait for your build.

43:18 You don't have to set up everything locally. You download this thing from cache. Yeah, exactly. You're good to go. Exactly. And the and the best thing is that you don't even need to build locally and you don't need to install the uh native dependency tooling. For example, for iOS you before building you would need to install cocoa pots.

43:38 Uh this often takes few minutes uh in in bigger projects. Yeah. Yeah. And uh and with that system uh you can you can skip cocoa pots part alto together uh and you can switch between the branch as as long as the the build for that branch is already available but the second it's available uh you can do that and not only you can do that as a developer your QA engineer can do that as well and they can download this build for themselves push it into their devices and test right away even on your PR.

44:16 So this opens up those new experiences of collaboration between developers and quality engineers which is in in many companies it it's very much siloed. Developers are working you know in batches on their stuff. They're aware of some bugs uh not aware of of of of the rest. And then we have the QA part and uh and it goes in those those series like development QA development QA uh and what we uh what we learned uh for for many years in software development that uh uh we can produce software faster and more efficient with less bugs if we have tighter feedback loops.

45:02 So if we could collaborate with QA engineers that are seeing more than developers, uh they they they just have those talents for breaking our apps, which is which is amazing. Um uh but a bit painful for for developer as well. Uh if we if we can get them to collaborate, we can produce software of higher quality faster.

45:26 So, uh, with all those with those two pieces together, the the CLI and the remote caching system available on your CI and it's your CI. It's not some third party cloud. Uh, it's it's like you run GitHub actions, you can run this on GitHub actions. Yeah. And you own it, you control it, you're you're like you're in charge of it.

45:54 If if you run on Bit R, you can run it on Bit Rice. It's going to be a bit more complicated because we haven't built a a plug-in for Bit Rice yet, but we're working on making it uh universally available for for anyone uh in a in a way that that Turbo Repo, for example, is you you mentioned that you haven't built the plug-in yet.

46:15 So, that's like another small thing that the uh library is modular and you you build it with like modularity in in your mind. uh and it's made for incremental adoption. If you're using React Native Community CLI today or consider trying React Native in your existing iOS or Android project, chances are you'll enjoy the React Native enterprise framework.

46:40 We build it based on years of experience maintaining community CLI and supporting enterprises from Fortune 500, many of which already tried and adopted RNF and enjoy 20 times faster cloud builds most of the time. If you'd like to try it, go to rnf.dev and check the quick guide for your project. or you can book a meeting with me and our team will help you use its full potential in a week.

47:09 Back to the episode. We spent a lot of time talking about cloud builds, but I would love to touch upon working with brownfield because I think that's another big piece of the puzzle here. So, can you walk us through a little bit and let's start with project A. Was it a brownfield or was it like a pure react uh native app?

47:27 So, our project project is greenfield app. Okay. But uh as I recently had an episode about brownfield, each react native project is not really green field to the core, right? Because like you always have those like native uh you always have that native code. Yeah, at some point you'll end up having to check something on the native side.

47:51 also like even if you don't like modify the native modules in any way like you will in my project if I have four different um variants of the same application or five I still have a bunch of like code in the gradal file for Android to like stitch it all together and to give it a proper package name and to give it a proper icon and etc etc.

48:16 So like you always need to to have that in those kind of bigger uh enterprise projects. Yeah. But like regular blank fields as we know if somebody has their native app they want to add react native it's sort of you sort of have to start with some lessons articles reading stuff because it's not super easy.

48:37 And then there's RNF. So what changes here? Yeah. So what's again what we realized uh over the last couple of months uh actually is that the current way of uh because what we're talking about as a brownfield is actually in integrating react native app into in like in view for example in a existing native iOS or Android or whatever else application.

49:09 So, so this is what we typically mean by brownfield and current way of of doing that is very complex because it requires your project to change its structure to adopt react native dependencies that it depend on. uh specifically uh for iOS it requires you to adopt cocoa pots and most of the ecosystem you know moved to SPM for example to to swift package manager now so iOS developers especially hate adding like extra extra new tooling that's that's redundant which cocoa is for them and uh what we were doing at the same time with for for our uh our clients is that we've thought about a different way of doing it and uh we imagined that if we package like everything around React Native which is the whole React Native app together with uh the JavaScript bundle all the frameworks inside etc in a in a single executable in a single framework for example or or a library file we could import that in a native project and that would leave us without cocoa pots without the necessity to mess with that project structure.

50:30 We could just import React Native as any other library and instantiate it as a view. So, so we did that for a couple of our clients and uh and it it worked uh pretty pretty great. It has some some small tradeoffs that we're working um around on the as we go u with with some some packages that we were able to patch for example.

50:55 But in in majority of cases uh this is this is something that uh that works and that we decided to incorporate into the enterprise framework project in the form of plugins. So React Native Enterprise Framework is a is a modular system. You can extend its capabilities with with plugins with platforms.

51:20 You can replace bundlers. Um uh and currently we're we're supporting uh that you can use Metro or or Repack uh which is allowing you to use RSpack or Webpack. And we also allow you to build your own plugins. At the same time, we've built some either uh builtin or or or like ready to use ready to grab for your plugins in our monor repo.

51:46 And two of those plugins are the uh brownfield plugin for iOS and for Android that if you're using a React Native Enterprise framework in your project, you can add those plugins and they will expose a like new commands for packaging all of that React Native app that you building with Enterprise Framework in a single XC framework for iOS or something we call fat aer uh a library file for Android and then you can grab like drag and drop those frameworks into your native project and done you're you have you have React Native in your project now uh whether it's a fullyfledged application or it's some uh single screen or or particular widget that you would like to uh to use in some parts of uh of your native app.

52:48 And this is particularly exciting because React Native uh like recently turned 10 years and we're still pretty early in the adoption curve. But what we see is that more and more businesses are using React Native to ship uh mobile especially mobile native apps. But also what we've seen with with our other customers uh there's a lot of TV enterprises that are using React Native so that they can build once more or less and uh deploy their app on 10 different TV um operating systems which is which is amazing for them because with 20 people they can do what they did with 100 people few years ago.

53:35 This is this is the case of of our client. And if if for those of you who don't have the who are not lucky enough to work with TVs, there are so many operating systems. Uh Wukash had another podcast with uh was two guests. It was Mike and I don't remember his name. Chris Track. Yes, Chris. Mike and Chris.

53:56 And they were trying to actually count the OSS that they target with their apps. and they I I don't think they managed to actually count them at the end because there are so many. So a tool like RNF is is definitely awesome. So So at at this at this point, we're still like uh adding the support for like TV plugins, but that's not not the point.

54:20 So the point is that I want to I wanted to make is that we're early on the like adoption curve of React Native and we're approaching the the space where more and more companies will likely adopt React Native and those going to be new projects where they would just be able to use Expo for most of the time and that's going to be great.

54:54 Uh or or VIP go their app uh using Bolt or or something like this. Uh that's that's happening. That's going to happen. It is happening. Yeah, I know. And there are thousands of businesses that are today on native stacks on on using X like Swift UI or or Swift for iOS and and Jetpack Compose. And they would also like to ship some of parts of their applications to multiple platforms at the same time or uh just migrate their whole projects into into React Native.

55:31 So they could have all those benefits of you know web react web ecosystem and uh and ship to all those platforms uh with native apps. I have a question to you like you painted this picture uh where there is expo and expo is very good for new projects and for like uh most of the projects and then there are enterprise clients and like more complicated custom setups that would really benefit from R&F or react native enterprise framework.

56:03 M so what is your plan to position yourself like to position this library this framework uh for those people that are considering uh community CLI or React Native or like whatever tool meet their needs to go with RNF. Yeah. So currently the there are two kinds of uh users that we're particularly focusing on.

56:30 uh first one is the users of community CLI. So we want to give them a easy migration to a something that will will be able to soon call a official framework hopefully. So something that has a road map is actively developed and it's uh doubling down on developer experience. And the other kind of user is those companies that are on native stacks and want to adopt React Native because today adopting like migrating to React Native is a pain in the ass basically.

57:07 Uh it's it's very hard. So, so we we can't blame those iOS and and Android engineers that they don't want to do that for example and that they're forced to uh because it's hard and uh and in in many cases counterproductive at the same time companies are deciding to adopt React Native whether it's hard or not.

57:30 And uh where we are with our framework, we want to make this effort as easy for you as it's physically possible. And that's why we're we're focusing on on those two types of of users. Something that's uh for example, Expo is uh is not focusing on they they have, you know, a lot broader scope of their users that they want to track and and address.

57:57 And this is and this is great. and we're not targeting those users. If you can use Expo, uh you're starting new project or it's like very easy migration from community CLI. Uh maybe you're fine with uh with their uh third party cloud uh expo app services, go for it. If it makes uh your your app building process faster, uh saves you money or whatever, uh that's the right call to do.

58:25 Uh we're there for uh for those more complex cases and for for those that want to use React Native but don't know how because it's so so hard and they tried in the in the past, they tried recently. It's not very easy. So we're changing that. It really shows how passionate it you are about this framework.

58:52 like I I feel we could sit here and talk about it for I don't know 10 10 more hours. Uh I still feel that Wukash Wukash has a question about your relationship to Expo. Well, you mentioned Expo and like I feel like this is an elephant in the room in like the whole topic of React Native frameworks cuz Expo was the first one and is the only one like so far.

59:20 So far yeah. Yeah. Like my question is what does it mean to be framework? Is re React Native Enterprise Framework already living up to this name or do you still have some way to go and like what's the relationship between you and Expo and Meta going to look like like that was my part of my previous question as well but like more directly can you like speak about those aspects?

59:49 Uh yeah, of course. Uh so uh so so at this point uh React Native Enterprise Framework is not yet considered like a official uh framework like bless framework by the core team of React Native. Um but we're on our on our way to to get there and to get there we need to check like some some particular boxes that uh we figured as a community in the form of the frameworks RFC that we collaborated uh between call stack meta expo uh and and some some other parties as well.

60:27 So currently what we're what we're missing is uh the upgrading experience. So it's so it's easier although it's pretty easy at this point uh minus the third party dependencies which you mean upgrading upgrading react native versions. Yes. So so that's that that's one thing. Another thing is uh navigation the the frameworks uh RFC says that we should have some some navigation stack.

60:54 uh for now we're recommending our users to to use what whatever they used uh up until this point which is likely react navigation and and we we don't want to change that for example um and I I think like there is the the rest um and maybe some uh some some more developer experience like like better DX around uh publishing the apps to the to the app store.

61:27 Um which uh all of those things that we're not there yet uh they are on our road map and uh and we're uh we're working uh towards that that future so we can be recognized as a framework. So, for example, we're going to probably build some kind of uh either include the navigation like React navigation with um with some some native bottom tabs, native stacks, etc.

61:55 in our library template. We may explore filebased routing uh for example that would work with uh not only with Metro but also with uh uh with Webpack with Arispak. On top of that, we would like to build React server components uh because then we will be able to to integrate it. I would like to like do a quick plug about call stack because you're mentioning react navigation that's maintained by call stacker.

62:23 Hello Satia. Um yeah mentioning yeah you're mentioning native bottom tabs developed by Oscar Fashki from as well. So um there's really it feels like you're orchestrating you you are capable of orchestrating a great tool uh using a bunch of open source libraries and you have this insider like you can contact those developers very easily since we work at the same company.

62:50 So that makes it like can fasttrack a bunch of stuff probably. Yes. And this is a great thing about having a framework uh because like up to this point as maintainers of community CLI, we couldn't push our uh like recommended stacks uh or or or like tools that we use for almost any client uh to uh to the you know default template which is supposed to be as simple as possible in terms of maintenance efforts.

63:21 uh because we don't want to uh spend too much time doing so. But having a framework, we can have like more opinionated way of what it means to to develop a react native application. So we can stack up a lot of our and third party technology on top of that. something that uh we want to explore is uh is some is a different way of uh native modules system that would be web compon that that feels like a whole other topic.

63:54 I have like a really cool question. Do you see a future I'm only talking about explorations? Yeah, I know. Uh do you see a future where the React Native documentation where you have the environment set up uh we know there's React Native by React Native then there's Expo. Do you see a future where the next tab will be RNF?

64:10 Uh yes. Yes, definitely. Uh right before React Universe Con? Okay, we're going to like this year. Yeah, like this year. This is uh this is our target. So uh uh let's uh keep your fingers crossed uh and uh and yeah coming back to your expo being the only framework situation uh I think most of the developers out there feel that this is kind of weird situation right because I do I'm I'm one of those developers because the core team tells you I mean it started with with React right core team tells you yeah you should use a framework with React And you can use Nex.

64:53 js, Remix, maybe something else, but there are at least two. And with React Native, there was yeah, there's there there was the same same idea. You should use a framework with React Native. And you can go with Expo, which is amazing. And it's it's the only thing you can you get a recommendation from um from the core team.

65:15 Uh so so there's naturally a a space I think this was also a intention of the framework RFC to open some some ways for uh for other players to uh to enter this framework business. Let's say yeah a little bit of healthy competition is good for everybody when it's in the good spirits and we're all trying to build a better product.

65:37 We're all for that. Yeah. Uh so uh yeah we've been talking here about RNF. Uh we've mentioned we've talked a lot about cloud builds which is really cloud builds on your CI. It's a huge feature that's a feature that uh Wukash implemented in his project and he saw let's let's repeat that he saw like the build times falling from 30 minutes to 3 minutes.

66:02 Right. Yeah. Yeah. So like basically it's uh expected if the builds on average take 30 minutes, you should be able to uh to trim out that almost 30 minutes from your pipeline. There you go. Uh if you have a native app, there is a new approach to uh brownfield apps with React Native thanks to RNF. And uh this uh framework is built with modularity in mind and you can incrementally adopt it step by step piece by piece.

66:32 You can read much more about it uh in the documentation. React Native Enterprise Framework is open source. You can find it on GitHub. We'll post some links. Uh you can slide into me house DMs as well. He's open to your questions. Uh wukashim me as well. You can find me mostly on blue sky on GitHub because GitHub is trying to be social.

66:54 So you can invite me on GitHub as well. Um Miha Wukash I think you're active on Twitter and X formerly known as Twitter. Uh but Blue Sky as well will we'll add all the uh socials in the description of this episode. Um go out and try RNF for yourself and uh follow Costa as well. We have some nice social media presence on Twitter X Blue Sky LinkedIn uh wherever you are.

67:21 We're everywhere. You are. We're everywhere. We try to be. Yeah. Thanks. Thank you. Yeah. Thank you. Thank you very much, Wukash. Thank you, Ola. Yeah. Thank you guys for being here. Yeah. See you next time hopefully around the the conference. See you. Yep. Yeah. See you. [Music]