 So, I guess React Native is fairly popular, to give you an idea, React Native lets you build mobile apps using only JavaScript, right? The native SDKs that you do actually require you to write your code in Java, for example in Android, Objective-C with iOS, whereas here React Native lets you build your applications only in JavaScript and it lets you use the same design philosophy that React embodies. Didn't Sencha, PhoneGap, Ionic and a bunch of other frameworks say that it is the same? There's a stark difference though, React Native is native. So how many of you guys have used Sencha, PhoneGap, Ionic for that matter? You know that it's nothing but a web view and you have your web app loaded there, right? React Native is unlike any of these frameworks, it actually runs your code natively. To give you an idea, what happens is that you have the JavaScript engine that's running and there's a JavaScript native bridge. So whenever there's any event that the JavaScript engine needs to listen upon, it goes why the bridge passes as a message onto the JavaScript engine. The JavaScript engine also executes code, passes on a message, why the bridge back to native. So this communication is what facilitates React Native. So why React Native, okay? So with React Native, given the fact that we actually use JavaScript and React, which is a fairly popular framework these days, all our front-end developers would become mobile developers, right? Mobile development is a fairly niche skill set, if you'd see, right? If you guys have been looking at the trends over the last couple of years, mobile developers are the ones who are most sought after, with front-end developers also being in the mix, right? You can now have your front-end devs also work on mobile development and you bring the same fundamentals that React embodies onto building native apps. It's developer-friendly. So I think we had to talk about Gradle and slow build times and you guys know anytime you make a change, you'd have to build, compile, and run, right? Especially this becomes difficult when you're sitting with your designers for this thing called as pixel perfection, right? How many of you guys do that? So you'd be sitting there, they'd ask you to change this color, shift these by a few pixels, you know, wait for the entire cycle. Instant runs come in but still things like that have not really helped us, right? So that's like a real pain. So this is where this comes into the picture. I'm actually going to show you a demo a little later. The idea is you just double-tap R, right? Because it's integrated on the fly, you have your entire view rendered straight away. That's how awesome it is. The next part, it builds fast, really, really fast. So the leftover there, you see the amount of code I've written to actually get this screen. So this is, I've just taken a snapshot of a set of Twitter feed and I'm just reading it off a file and you can see I'm just composing the entire view. Is it fairly visible for you guys? So the idea is that I have a component called as AndroidCon within which I'm rendering a view which renders a list view and then I'm rendering each row of the list view as a tweet. So this is the demo I'll be showing you in some time as well. Now the other part of this, this just works across Android and iOS. I take the same code, I copy pasted it onto the iOS.js file and ran it and this is what I got. I literally did not change a single line of code. So you can see that this directly is the reflection of what's there on Android that happens on iOS as well. So you can actually share code between iOS and Android. And finally, I think this is like the most important thing, it's instant app updates. How many of you have faced this issue wherein you've actually had a bug in production and you then had to make a release back to the store? How long does it take for you to actually get that bundle pushed? I mean, how long does it take for you to actually get your APK pushed? You have your entire regression that cycle then finally wait for three hours for the Play Store to update and then finally wait for your users to upgrade, which you know in a place like India isn't that feasible, right? So with React Native, you actually get to do instant app updates. Now this is something that though it's been talked about, not a lot of folks actually do instant app updates in production. So we've been doing this for about a year and a half. So the idea is that there's a JS bundle, right? Which is your entire set of JS code that's run on run to render your views. Now imagine if I could replace that file, it's nothing but me reading a file on the device, right? So I'm replacing the file. So what we do, we have a server on our end, which actually points to what's the latest version of that JS bundle for a given app version. And anytime there's a new update or even if there's a downgrade, it will actually download the fresh JS bundle. And the next time you launch a new react activity, it would be loading the fresh, the latest JS bundle. So you can see that every one of your active users will actually get to see the latest code in production, right? So that's how fast this is. The Play Store has not had an issue with this. And the app store as well clearly states that this is permitted. You can go look up their agreement. Okay. So we did speak about why react native makes sense from a developer standpoint, right? But if you were to go and actually pitch this with react native, there are some caveats as well that comes across the, you know, learning curve, et cetera, I'll be talking about that as well. But if there is a reason for business to actually want this, these are it. Firstly, product can iterate and push out features a lot, a lot faster. So you know that if you have a two or a three or a four week release cycle, your features get rolled out in those release trains, right? We know that we would not let them roll out a feature in between a release cycle because you know, if users want to grade, et cetera. Now with this, you can actually forget about the fact that users want to create. And secondly, you can actually have alternate trains that keep pushing out code. So what I mean to say is that from the time you've actually completed a feature till the time it reaches the customer's hand, you know, of course, after your testing, et cetera, the time would be matter of a few hours. As opposed to a week or two or more, depending on your release cycles. So the other thing is you can make your business guys happy. So I always have this requirement that comes about just for for a sale. Mario, can you just add a small little timer on top of the list page? You know, we want to run this entire deals campaign. I'm like, I'm really sorry, I'll have to wait for probably another three weeks to get it live. Oh, no, I have a sale the next week, right? So it's impossible for us to actually get these features out there with native DevLap with react native. I could just tell them, give me a day. I'll actually have it live, right? So you can just think about how easily your business can grow as well. We're actually adopting to this thing, specifically the Instant App updates. You can fix bugs really fast. What did he mention this? Your users needn't update that app, right? You do know that we all face this problem of fragmented versions across. See, this is somehow very weird paradox for me with iOS users, because we've noticed that 90% of our iOS users update that app within a week of us releasing the newest version, as opposed to what happens on Android, right? On Android, I think we probably touch about 30% with two weeks of us releasing the app. And I'm just talking about active users. You don't know that there are legacy users who come in a little later, but we still see a huge fragmentation of versions out there. So this actually ensures that you have feature parity when it comes to users not upgrading their app. And finally, it's a lesser cost of development, given that you can actually turn out Android and iOS, right? You'd be able to actually do more with less. So how did we go about doing this? Like I mentioned, we did this about a year and a half. So to give you a little backstory, you know, Christopher Shadow at Facebook, he goes by the Twitter handle, B, J, E, X. I'm not really getting, I don't know how to pronounce it right. I think it's supposed to be view or something. So they were announcing a react native for iOS. So we had Sunil and Param who were working at Minthra and we went ahead and we nagged them and literally asked them for access to the react native code base. So we kind of got access roughly around the same time it was released in production, but we had an idea of what was happening. So we were trying to build something on the lines of what react native was doing internally as well. And then once react native came on, we picked it on. It was very much, you know, alpha or to say beta software, but we were willing to take the risk. So what we did, we had to convince our CTO, right? Given that you're taking such a risky proposition when react native, even after about a year and a half still has not penetrated into large applications, we had to really take that leap of faith trying to explain to him that it's a risky affair, but we'd still like to go that path and we did that and it has helped us, right? So how we started off was actually taking one platform at a time. In this case, it was iOS. We were building this thing called as the feed. If you were to open the Minthra app and you had to see what you see on the homepage, it's called the feed. That was the company we were trying to build. So while it was not slotted for a release on iOS, we had the development on Android. So we thought it's a good time to actually start, you know, experimenting with react native with the feed. So we started building that and what we did was we took one of our smart engineers and we put them on it and we asked him to just keep working on it. So we went ahead, built the first prototype and dog fooded it internally. Okay. That's another important thing. When you're releasing features, have a means of being able to push it out to your internal users first, right? Probably they might not come by an alpha or a beta channel with JS bundle of dates, right? With react native, you can actually say a control set of your audience receives this and you know, other set of your audience will actually see the one that's in production. So we were able to do that. We dog fooded it, then slowly released it to production. And once we actually saw that things were working fine, got it out to a larger set of users. And finally, metrics ensure that you measure everything. Right. Performance is a key aspect. Stability is another key aspect and show that you're actually looking at your crash logs, you measure view load times, et cetera, to ensure that you're actually not sacrificing on Perf. So once we had all of this sorted, we took another step and we said, we'll build all our features with react native. So nothing, none of these come without any learnings, right? So I'm going to talk to you about a few learnings, a few things that we had in place that helped us actually take the leap forward a little easier if you'd actually say. So the way you structure your app is fairly important. So I think you've, we've had talks yesterday as well about actually separating your networking layer and various other third parties away from your, uh, a fair code, right? So what do you do? You keep a presentation layer separate and you actually write components that you can access. The next thing that we did was we did not directly make a switch and said, we'll build everything again in react native. So we built our app in a way that you could actually shift out, uh, you can use native for a few screens, react native for a few screens. So our shell is still native. I mean, and we can move about between the react native and native as we want. The other thing was what we did, uh, since we have a lot of our perf metrics, networking clients, caching, image, hotel, libraries, et cetera, already built, we decided we'll extend upon them. So react native provides this thing called as a native module. So what it does is bridges the gap between native and JavaScript. So you can actually use your native module in react native, provided you have a few methods exposed that you can call upon. Okay. So there's a little bit of a syntax, uh, it's a fairly easy syntax to follow to write, but it eventually runs your native code natively. And so we did this. So we were able to leverage our innate native libraries on native code base. And, uh, that actually helped us get this a lot easier. The second thing is called routing, right? How do you guys actually move from one activity to another? You create an intent and then you say start activity, right, or probably some of you guys use fragments and use fragment transactions, right? The only problem is that, uh, I think, uh, if I have one screen, a, and there's a screen, B screen, a should not know it's opening screen, B. What I mean to say is that it was called a screen activity, screen, sorry, activity, a dot Java and activity B dot Java activity, a dot Java need not know it's opening activity, B dot Java, right? Because to actually save the kind of transitions you could have is you could have native to react, right? Native to native react to react and so on and so forth. So your transitions between activities can happen anyway. So what you do is you actually delegate that responsibility of routing as to opening another screen to a central thing called as a router, right? This is a concept that's there, uh, with server-side development and with the single page applications, et cetera. This is a fairly important thing that we learned. We did this early on, so it helped us a lot. So what we do is every single page of our application is located using a URL, right? URL is a fairly, uh, well-accepted, uh, entities in the entire internet world. So for example, if I wanted to open a search listing, I had a slash Nike, for example, that would open my search listing page. If I wanted to open a style ID, a product detail, I'd say slash style slash style ID. That's it from one screen to another. Screen A does not know it's actually opening screen B, the, uh, the actual file directly. It just knows that it requires to open a certain entity. So in my routing table, I can decide to say, okay, slash style was actually pointing to a native screen today. I can move it to a react screen, right? If you're even having multiple implementations of your product detail page, if you're doing an AB for that matter, these kind of things actually come in handy, right? This also helps you with deep links, push notifications, and a bunch of other things. If you actually have a URL to actually, uh, delimit every single page. Finally, build all your features, hence forth with react native. That's something that we did. So once we knew react native worked for us, right, with the first iteration of our feed, we said, okay, for now on every feature that we build on the iOS platform would be on react native. That's a similar step you're taking with Android, Android having launched a little later than iOS for react native. It's the same step we are taking now with that. And finally, release fast, right? I think web developers have this, uh, innate happiness that comes in that the moment they actually have a feature out there, you built a feature, you fixed a bug within a couple of hours, you have it out there, right? I'm sure if each one of us were able to build a feature, fix a bug, and we were able to get it out there in a couple of hours, the kind of elation that we'd have by doing so is this immense, right? So that's something that we can actually benefit out of. And this is another big learning that we had. So because react native is a fairly growing library, it's a glowing, growing framework. There's a lot of things that keep changing. The react native core team changes and releases a new version of react native every two weeks. So we got into this mess where we were fairly, you know, satisfied and happy with what was happening on iOS. So we had zero dot 18 of react native, if I'm not mistaken, running for us, you were building features constantly, but we did not choose to upgrade react native. You know, it just slipped our minds completely. And then there was this need for us to fix a couple of bugs. And then we saw, oh, shit, it's fixed in react native 24. But no, I have to actually go and migrate. It's going to take me a lot of time. So we decided we can't keep leaving the elephant in the room as it is. We had to do something about it. So we spent an entire sprint, right? It's the entire three week cycle where every single one of our developers was sitting and just getting the entire react native version of greedy. So we had to move change syntax across the app. They had moved from ES five to ES six in JavaScript. And hence that became a little bit of a nightmare for us. So my advice is that with every release that you make, always try to point if not to the latest, at least one version behind the latest that's marked as a release from the react native repository. For that matter, I think this would hold you good for any dependency that you use. It's easier for us to actually progress. If you are actually moving every one of your dependencies forward, rather than the same or this version of the dependency works. Let me keep quiet about it. No, easier for you to move forward, right? So even if you are writing open source code, you definitely keep writing enhancements over it. You would not want your users using older versions and complaining about it. So it's always a good practice to upgrade. Finally, get everyone involved. So this is something we learned a little early on. So at Mintero, we actually look at mobile development a little differently from other companies. So we've gone through this phase of saying we'll have smaller teams which look after certain features. And then we got we went through this phase of actually saying we had an Android and an iOS team. Now we actually start looking at everyone as a mobile developer. So what I mean by that is get everybody working on it. So whether you're a native developer or you're a code JavaScript engineer, try to get everybody involved and try to start getting them working on react native, right? Because for a mobile developer for a native developer, you will appreciate react native a lot more because you understand what's happening over there. After all the activity after all JavaScript, sorry, Java or all languages and ways in which you can actually present something to a user on the screen, right? So the way you can do it with react native is also something you'll appreciate. Get everyone involved. Don't you know, say that I'll actually carve out a team and say they are only react native or I'll just say these guys do only Android for that matter again, everybody together and work on it. You'll actually see merits of it. And there are some caveats. Firstly, you might need to write your own bridge components. So while react native as the framework itself gives you a lot of your sd or your uikid or your Android SDK related components that you require, there are cases where you'd have to build your own. So this happened to us when we were actually building the YouTube client. We needed the YouTube client to showcase videos on our application. So we found that there was no YouTube player out there. So we went ahead built it. There are a couple of other libraries we had to build like this. There are views et cetera that are not available externally stuff that you'd have built yourself. You would have to actually go ahead and build bridge components for this. And you'll end up writing Raco modules over your native components. Like I mentioned earlier is more of a plus more than a caveat as I would say because you get to leverage what you already have from a native standpoint over there. The other thing is about tracking crashes. Unlike native crashes which actually gets symbolicated and they show up as separate crashes per line. Even if there was a file which was crashing in 10 different places fabric or bugs and so whatever crash reporting tool that you use will actually segregate them as individual crashes. This is not the case with the react native crash because what happened is a central react exception manager which catches the crash and then just sends it from there. So you'd need some form of meta information or whatever to be able to segregate these crashes. So we are ending up moving to something called a sentry which is a JavaScript error tracking tool. So we intend to actually send our crash reports there. The other thing is about using source maps because your JS bundle is actually a minified version of your JavaScript code. You'd not be able to actually go back and figure out which line was this exception being occurred at. Have source maps so you can actually track back the original line. And sometimes react native crashes are hard to debug. We have not had too much of a problem with this thankfully but there were crashes that we took about a month or so to actually get at. A reason being there would be crashes which happen at the react native library level and there are some crashes that happen at your code level. So it's slightly difficult to segregate that. The community is getting better at it. We had this difficulty like I said because we were starting off a year and a half when things were fairly immature. Now the community is a lot more mature and this was something that you should probably not face as much as we did. Another important aspect is app size. Unlike iOS, Android doesn't ship with a JavaScript engine. So with iOS 5, they have been shipping JavaScript core with iOS but Android does not ship a version of WebKit that you could actually use. So this actually will increase your app size by about 3 to 4 MB. But the upside of it is that your code because you're writing everything in JavaScript would actually be a lot lesser in size. So it's a trade-off. The other thing that we did was to actually use ABI splits. How many of you guys use ABI based APK splits? That's a very, very nice thing to do because if you're using a lot of native libraries, you end up actually packaging. If you have an x86 device, why would you have the ARM or the ARM v7 variant of the native library? Why would you actually send that to your user? It's better to actually send the native library for that specific ABI alone. So when you do ABI splits, you'd easily save up even on your current APK about 3 MB of space. So that's like something that you'd have to do with React Native. Otherwise, you'll end up bloating your app size. We actually got to do ABI splits a lot before we moved to React Native. So we didn't feel the pinch as much when we actually had to move here. So I'm actually going to now shoot out a few demos. Basically, it's the same application that we were looking at then. So this is my code. Just go through this basic set of imports. This is your main component. And I have a constructor here wherein I'm actually creating a list view data source. I'm going to use a list view to populate a set of tweets. I'm just setting up my data source here by saying populate it with this set of data. I'm not really making an external request. I'm reading off of a file. And this is how I render it. I'm just saying there's a view block. I have some text which says welcome to DroidCon. There's a list view which I point to the same data source. And I say there's a render row function which gets called for every row. This is a render row function. I actually fetch the user object. Then I say there's a view. There's an image and this text. So this looks a lot like React itself for you. Barring the components that you use. If you guys are coming from a React while you understand you'd probably use divs or paragraph tags, etc. But these are core native components that we are actually using here. The other wonderful thing is about the way you actually have styles. We are used to actually writing styles in line or probably setting them in code. You actually can use a style sheet directly and it works. I'm going to just fire this up. So there's a React Native CLI which has become fairly popular these days. Using it would probably get you on board to React Native a lot faster. Wasn't the case a couple of months ago. You'd actually have to go through a lot of setup. But the React Native CLI, you can just look it up. It's fairly easy to start a new project and get running with it. So I'm just going to say React Native and Droid. So I already have my server running here. So this is called the JavaScript server. Basically what this does, it serves your JS bundle that's required for your application to run. So this is what you use during development. So like I said, you have a JS bundle which needs to be loaded for you to be able to display anything on the screen, right? Any view, any rendering that you do has to happen that way. By actually letting your debug applications pull off of a local server, you're able to do things like code updates as you're developing. So let's just see if this ran. Yep, it did. So here you have it running, okay? So let me actually change a couple of things to show you how things work. So I have hot reloading enabled, which means the React Native server is actually watching this file and changes will actually quickly reflect over there. Probably let's just say the welcome text comes red, there. You sort of become red over there, okay? That was instantaneous. Another way for me to explicitly reload is to hit double R. It refresh the JS bundle again and update. Fine, let me do another thing, okay? So I have the same code here on iOS. You can see there's practically nothing that's different here between the Android and the iOS source code. So I'm just gonna run this on iOS now. So the CLI actually takes care of, you know, compilation for you and actually launches the respective simulators and emulators. So it's the same thing over here, as you can see. It says welcome to DroidCon, same set of things. Let's do the same part about changing the color over here. So here on iOS, we use Command R, Android, it's double R. You can actually see that it worked across. Let's try to get a little more, let's try to do a little more. So what I'm going to do is let's say that clicking on a specific tweet will actually throw up in a toast. So let me go here, wrap this around with a touchable highlight. A touchable highlight is a component that basically lets you touch and highlight the item. Of course, I'll have a non-click listener, et cetera. So I save this, it's reloaded, clicking this actually tells you I clicked a specific item over there. You can see the toast there, right? So remember I had to, let me just go ahead and show you how debugging as well works here. So let's say I did not have my toast alert imported. So you see that there's a huge red screen that fills up over here and tells you the entire trace, telling you that, you know, this was the thing that was not imported. I can't find this variable, hence it's crashing. So I'll just go ahead and import it again and reload. That's how easily you can actually work. Just imagine now your development workflow, you sit with your designer, you're just making these changes and they're like, okay, mode of your pixels, you're changing this color. It all happens instantaneously. Just imagine how much of time you can save by just doing this, right? Next I'll actually move on to iOS as well and just show you the same thing that I'm doing there. I'll just copy paste this same code. We wrap this around here again. So it's gonna fail. Why toast Android is an Android specific component, right? It's not available on iOS. So I actually would probably have to use a different construct. So what shall I use? So Android, iOS comes with something called as an alert. So it's here, I've imported it already. Let me just go ahead and change this. So you can see there's a native alert view that got rendered over here, right? So I also wanted to pay some attention to the way these files are. So basically I have a set of files here. I have a data.json, which is actually my data source for the entire view. I have an index.android.js. Notice the suffix here. And I have an index.ios.js. So what happens over here is when I'm actually bundling, I mean, I'm getting my JS bundle rendered. I mean, when the bundling is happening, the bundler actually takes care of creating the bundle for you for a specific platform. It will include Android specific code, all files which had a .android.js, and all which did not have any suffix for the Android bundle, and similarly for your iOS bundle. So I think you're getting an idea of how you can actually facilitate code sharing. So basically what happens, you'll build your views in such a way that there are components, and these components are shareable to some extent. If there's at any point that a need for you to actually separate out from the UX or the UI or using components on Android and iOS, you'll separate it out by actually saying a .android.js or a .ios.js. You can see that you can actually get a lot of your core business logic, all these pieces sorted out separately. You have native modules, which actually listen on the same set of syntax, and effectively your presentation layer would slightly change with regards to Android and iOS, and there you can actually share a ton of code between Android and iOS. So that's the approach we are looking at, and that we've seen work for us. Facebook also had a post about this and how they built their AdWords Manager. That's a similar exercise they undertook. For them, probably they didn't care much about the UI. I'm just guessing here, because they were not looking at your native components for Android and iOS, but a lot of us care a lot about using material design on Android and following the native HIG on iOS. This will help you do that a lot better. Let's get back to the slides. So where are we with React Native? More than 60% of our Minthras, Minthras iOS app is on React Native. The day we decided, the day we found React Native to work for us, we've actually moved every single feature that we build on iOS with React Native. The homepage of the Android app currently, the latest version out there is on React Native. 100% of our users are actually seeing the homepage on React Native. We're rewriting other parts of our app, things like the product list page, product detail page, stuff that was previously available in web views like the checkout returns page, et cetera. We're actually rewriting a lot of them in React Native. We're actually looking at a paradigm wherein within our, you know, we have a building a framework of sorts wherein we actually have other teams being able to build in apps into our app. This was slightly something that was a little bit of a difficulty when it comes to native apps because you'd have to package the entire app as one, right? So if you actually had to build a new feature, you'd have to get your developer on board and work with them. Here we are looking at building a set of frameworks that are available where people can just build using our custom components, build their own app, and then host it here. So these are teams within Minterra that we're exposing it to. Probably we'll look at that party as well in the future. We push out weekly sometimes, you know, more than that as well. We push out updates that frequently. There have been times where we've done about two, three updates in a day as well. We're all humans. After all, we do make errors once in a while. So it makes it really easy for us to push out features. We have this wonderful system called as rollouts that an engineer by the name of Mukesh worked at Minterra. So what we do is along with the JS bundle, so you can actually roll out this bundle to a controlled audience. So like Play Store has stage rollouts, we have a similar concept called as rollouts for the bundle as well. So we also have internal users receiving the latest set of bundle and developers receiving bleeding edge bundles, et cetera, all of that sorted out. So we actually get our bundled reaching out to the entire audience internally first. And then, I mean, our Minterra folk internally first, and then we are actually taking it forward externally. There as well, we can roll out slowly to controlled environment. And our developers are cross-platform and that's like a big win for us. Okay, I think it's not gonna be complete if I do not talk about where our place is. You should not be looking at using React Native. For one, React Native is not a golden bullet for everyone's problem, right? There are certain apps which you probably would be better off just writing it with native. Anything that requires a lot of hardware interaction, should be written in native is my opinion. For example, if you're building a video editing application or audio editing application, rather than sitting and exporting every component that you need to, you'd be better off actually writing it with React Native, right? That's one of those takeaways that I'd like you to get. Large enterprise applications, stuff which is UI heavy, things that change a lot more frequently, right? These are places where React Native will help you a lot more. And finally, if you're a JavaScript developer or if you're an Android, DevO wants to write iOS, iOS DevO wants to write. Android React Native is the way to go for you. You don't really have to write a lot of native SDK code over there, right? So just keep this in mind when you're starting off your journey with React Native. Think about the kind of application you're building. See if there are real innate benefits that you get out of it, and then move on, right? We also do, all of us also think about whether we wanted to move to a Xamarin or a PhoneGap or a Titanium as well, right? There are a lot of pros and cons to both approaches. Think about it wisely. If it makes sense for you, if it really fits the kind of advantages it has, definitely go ahead and build it. And the last point is, I mean, something that I'm slicing up on again here, if you're a JavaScript developer or an Android developer wants to do iOS and vice versa, please use React Native. You'll figure out natively eventually. So yeah, that's about it. Do you guys have any questions for me? Okay, yeah. So are there any plans of open sourcing the rollout stool you mentioned, or are there any good alternatives in the market, I mean in the store right now? Okay, so we do intend to open source our rollouts. Mukesh, if you're listening, please do it soon. There are alternatives out there. There is a Microsoft code push and a couple of others which exist. But in our case, we had built our rollout system a lot earlier than when Microsoft was out there. And I feel a lot more comfortable having this code in-house. Hey, yep. So have you used some animations in React Native? Yes, we have. And it works smoothly or? So there's a caveat to how you use it. So there are some animations that actually offload your JavaScript thread. And there's an animation library that was released with React Native wherein you're telling them beforehand what are the animations you want to work, you want to actually apply. So it gets applied on the native side of things directly. So in a chunk, when you're starting off with your animation, you just send the message over to native. It then runs it innately rather than having a back and forth. And is it possible to know on which client the JavaScript is running at runtime? Yeah, yeah. Meaning which, whether you're running iOS or Android, right? For example, I build a component, GenericToast. And at runtime on iOS, it will show the dialogue. And on Android, it will show a toast. You can do that. I'd suggest two approaches. One, call this generictoast.android.iOS, generictoast.iOS.js. That's one approach. And other ways to actually look up the kind of platform you're running on and then write a file's condition for your course. I like the latter because you get clean separation of code. Okay, thanks. Hey, great talk. Thanks. So how fast they are in upgrading all the APIs, like matching APIs to an Android native? For example, we have this to you, but what about like RecyclerView or something? So like, I'm thinking like every Android API has some kind of like binding on React Native. And also what about like caching, like everybody sees like Picasso Blight or something like that for image caching, like so something like that already available in React or like whatever we are using in daily life, third-party libraries or Android APIs, we like to solve them automatically right now out of the box, yeah. So firstly, to start off with, there is no RecyclerView component that's available with React Native, right? But there's a slightly different approach that's taken as a list view where you render stuff and then whenever you're off the screen, you actually purge your view. Unlike RecyclerView, where you keep recycling the same view over and over again. That's a slightly different approach for performance reasons that's there. That being a slight aside, there are most of the libraries, most of your Android components are available either in their direct form or in a form that can be used across Android and iOS. Coming to your second part, they already bundled Fresco with it, right? Like UIL and Glide, Fresco is a fairly advanced image loading library we had actually moved to Fresco even before we did React Native on Android. So that helps you a lot from that perspective, caching, lower memory usage, et cetera. Other libraries have been ported. If you haven't found one, you can easily write a Bridge component. Bridge component probably requires about two, just two Java classes and you should be ready to go. Hi. Is there any difference in app start times between the native app and the React app? Yes, there is. I must admit there is. So what happens is that you're actually loading your JS bundle that takes a little amount of time. There are ways to mitigate this. One, once you've minified your bundle, you'll notice that the time taken to load it is a lot lesser. Secondly, what you can do is we've been exploring ways of actually sharing this, the React instance across. See a lot of us might not be starting off with React Native, a pure React Native application. We'd rather end up having a mix of native and React Native. That's where this becomes a lot more important. If you're doing a pure React Native application, it's only the first time load alone that's likely to be laid, which of course is being worked upon. And from then on, every other screen would work really fast. But if you have a combination of native and React Native, you'll find that if you're actually killing your activities, every time you open a new React Native screen, the bundle loading time adds to it, right? So we are looking at a shared React instance manager which would share the bundle across different activities. That way you would actually reduce your load times. Hi. So as you said, that we can use both native and React Native together, right? So as a native Android developer, I'm already comfortable with Android Studio and working on it for like, you know. So how does it work? Like is it native inside, I mean, native using inside React Native framework or React Native inside the native framework or can we use Android Studio interchangeably and you know? And what about like Windows? I mean, can we also get a Windows file along with Android and iOS? Okay. So firstly, React Native itself runs inside native. So React Native is not a framework that runs natively in sense like, it's not like Xamarin to put it simply, right? So what happens, you have, like I mentioned, there's a bridge, you have messages that you pass across and it works that way. So there's a React activity onto which you load a React screen. So React Native is running inside native to answer your first question. Second one about this running on Windows, right? There is a project that's there for React Native Windows. I'm not sure how far that project has gone. Microsoft announced support for it sometime back. Last I checked, there were a couple of commits but I haven't really tried it out. Next, you can use Android Studio as well to develop JS code, there's no real harm. It gives you good syntax highlighting. I mean, IntelliJ does a beautiful job of that. Hi. Hey. You said you have releases, it has releases every two weeks. So it is advantages or disadvantages? Because as a developer, I have to work continuously, I have to check if there's anything new is there, I have to update it. So it's continuous work. I cannot. So every two weeks you're talking about a React Native updates or a native updates specifically? React Native update, React Native. React Native, okay. So one thing is that between native releases only we upgrade the React Native library, right? That's one. So API is changing would not be much of an issue. Between two versions, we try to do a weekly release not even a bi-weekly, not even once in two weeks we try to do a weekly release. So what we do, we have people working on various bug fixes, new features, et cetera. Once things get merged in, we just release. So it's not like there's an additional responsibility on a developer to meet a specific timeline. Rather, if you actually have it in, we are able to push it into your release. Bug fixes, of course, you have to take care. And secondly, the kind of pushes that we do between releases is careful. We don't really push in really large features unless explicitly required. But most of these are tiny of features we know which will not change, right? And moreover, to answer your question a little more broadly, this is a matter of discipline, right? So how you actually have structured your team and the way you're planning out your releases you'd be able to ensure that people don't get fatigued. Yeah. Hi. Hi. Yeah. Sorry. So I understand that you are using React Native and I think so you're using a web view for checkout. Yes. Yeah, so you're using all these three technologies together in an application. How do you test that application end to end? Okay. So if you want to say simulate a real user experience, how do you do that? You have some scripts in place or you do it like manually, how do you do that? Or do you have some integration with some circles here or something like that? For that? Sorry, with what? Some integration tools? Okay. So firstly, we do both, we do both automation scripts as well as we do manual testing. So the end thing that you're talking about is primary integration or an instrumentation test that you'd like to call where you're actually testing your flow end to end. So we have a QA who have QAs who have written scripts on Appium, Robotium which actually run these for some of these the rest are manually tested, right? So and of course you can write your own UTs as well for individual components of your screen. Last question. Hi, we have a farm management solution wherein most of our apps works offline. So in that case, we have a smart chat application wherein we use Ionic as a platform and for storing the data we use Firebase. So there we were facing offline saving. So with React Native, can we go for offline apps? Yeah, so with React Native, nothing changes from a native paradigm. For example, if I was able to do offline with native, I'll still be able to because I'm not downloading a file of my server to actually run it on the client, right? There is a bundle residing on my application itself which is run at runtime. Hence, I can do anything and everything that I was doing with native. So offline to answer your question, there is not gonna be a problem at all. Okay, thank you. I'm afraid we're running out of time. We can't accept any more questions. Mario's gonna be here though. So if you have questions, you can always meet him outside or during the break and I'm sure he'll be happy to answer all. Thanks Mario. Awesome, thank you guys. And so if you're not able to catch me as well, there are a bunch of other Mintra engineers out there. You can reach out to us. We are really happy to talk to you about React Native and our journey. Thank you so much.