Our big reaction to React Native
Rob and Jay get into the technical weeds with our good friend and senior developer, Jake Hendley. Jake gives us a tour of our favorite mobile app framework, React Native, sharing wisdom about where it fits best and how to choose the right framework for your next project.
Hosted By
Rob Hallmanaging director
Jay Cosgrovesenior product manager
Special Guest
Jake Hendleysenior developer
Episode TranscriptRob Hall: This is the experience lab, the official podcast of digital scientists from Atlanta, Georgia. We’re an experienced lab that explores and builds digital products. My name is Rob Hall, and I’m the Senior Director of Product at DS.
Jay Cosgrove: And in the Jay Cosgrove senior product manager.
Rob Hall: Thanks for listening.
Rob Hall: So the other day I was drinking a blueberry tart. Have you guys ever had tarts before? Are you into those?
Jay Cosgrove: I have no clue what you’re talking about right now.
Rob Hall: It’s beer Jay.
Jake Hendley: It’s like a sour.
Rob Hall: Oh, yeah. A blueberry tart. Sour. Yes.
Jay Cosgrove: Sour okay.
Rob Hall: Yeah yeah yeah.
Jay Cosgrove: I do like sours. But I’ve never had that.
Jake Hendley: Tart means like, super sour.
Rob Hall: It was very sour. But but kind of in a good way. It’s hard to explain. Like, it wasn’t so sour that it was like eating Sour Patch Kids.
Jay Cosgrove: Well, I’m glad you differentiate that.
Jake Hendley: Right?
Rob Hall: Yeah.
Jake Hendley: Not as bad as like a like a goze.
Jay Cosgrove: What is that?
Jake Hendley: Have you ever had a goze?
Rob Hall: I don’t know, if I have.
Jake Hendley: Goze. It’s like this old Austrian or German or something recipe for the most sour thing that you’ve ever had in your life that is carbonated and has alcohol in it. But they call it a beer. I don’t know if that’s really true. But it’s like drinking Sour Patch Kids.
Rob Hall: Yeah, that sounds terrible.
Jake Hendley: Or salt water with lemon in it? Yeah.
Jay Cosgrove: That’s awful.
Jake Hendley: People love it.
Rob Hall: Well, joining us today on the podcast is our wonderful colleague, Jake Henley.
Jake Hendley: Hello, everybody.
Rob Hall: Jake is one of our senior developers here at Digital scientists. And and today, we’re gonna have a conversation about a number of things, not the least of which might include some references to craft beer, which we have a mutual appreciation of. But the primary reason we’re here today is to talk about our experiences using certain mobile frameworks in building mobile applications, in particular, the React Native framework. So we get we get asked certain questions pretty often about whether or not we do native development. And by native development, we’re typically referring to iOS or Android, what is the real story when we’re speaking of native development? And and so there’s been this evolving trend over the years to say I can create native apps that are truly native, but without knowing swift or Objective C, or Java on the Google side, Jake, can can you define Really? What is React Native? And Where’d it come from? How does it work? And is it fair to say that, that we’re creating truly native apps by using it?
Jake Hendley: So React Native is a pretty awesome framework from Facebook, they started working on it like five or six years ago. And it’s generally, like you said, it’s a JavaScript framework that allows you to build native apps using the prolific language of JavaScript, which, you know, most people know, at the end of the day, React Native is just react. So another product from Facebook is react, which is a JavaScript framework for user interfaces, what they’ve done with React Native is, well, a couple things. Generally, they’ve changed the kind of target of development from what everybody knows and loves HTML to native platforms. Generally, iOS vs. Java, Android.
Rob Hall: It’s a JavaScript framework. Are we really building native apps with it?
Jake Hendley: Yeah, absolutely. Again, I guess a good distinction to make here is where it came from Facebook obviously had react first, which was this game changing framework for building UI’s. And they wanted to be able to apply that to the native, right. So normally, UI’s from react would be compiling on HTML, or shipped as HTML, building, you know, websites and all that. With React Native, they implemented a different view layer, if you will, that allowed, like the same react, we know and love to control native UI elements on both Android and iOS. So you can kind of think of it as with normal web development, obviously, you’re rendering Dibs and HTML, you know, paragraph tags, all that with React Native, you’re rendering views and texts primarily. And under the hood, those are actually proxy down to truly native UI components. So it’s not a hybrid app. It’s not some kind of weird offshoot, it’s directly native application that just runs in JavaScript land.
Jay Cosgrove: That’s awesome. You mentioned something interesting there. You mentioned hybrid apps. And I think right at the front of this, it would be cool to define. Maybe the three distinctions, or at least that’s how they lay out in my mind is you have truly native apps, and then you have kind of React Native, which was what we’re talking about today. But the precursor to those were sometimes called hybrids, right?
Rob Hall: And we used to, we used to do a lot of actual hybrid work right.
Jake Hendley: Before we switched to React Native. We were doing a lot of stuff with Apache Cordova and a framework called ionic. So I can start there. So a hybrid app is an application that’s kind of shoehorning web technologies into the native world. So what that means is, back in the day, Cordova came out and allowed you to ship HTML as a native app. And all that would do under the hood is pretty much render that HTML in a web browser without any of the Chrome, Chrome being like the URL bar or the back button or any of that. They really just took an HTML page, dropped it in a web browser and said, hey, look, it’s native, even though it’s really not. So before Hybrid’s, obviously, there was native, you know, Objective C, Java, or the two languages are the two big platforms decided on and that’s what they ran with. And then Cordova came out, see, what was it, PhoneGap came out first, which was a an Adobe product, which was then open sourced and donated to the Apache Software Foundation, which came became Apache Cordova. And then a few others came out as competitors around the same time, mostly because people were trying to monetize the idea of hybrid frameworks. So you had a thing called titanium, which charged license fees, and then another one called Xamarin, which is for like the dotnet, C sharp crowd. And then PhoneGap has another pro level or thing it’s called PhoneGap build or something like that, where they were trying to get subscription tacked on to the hybrid framework. But then React Native jumps on the scene and it was awesome. It was so much better than all that other stuff. Except everything was broken in the beginning, like React Native was absolutely terrible. Until version, zero dot 40. You pretty, in the beginning, you had to be a native developer to use React Native.
Rob Hall: So lots of promise, but not a lot of proof.
Jake Hendley: Exactly. So React Native is five or six years old, I’d say about three years ago, maybe a little bit more, it got to the point where you didn’t have to be super versed in native development in the native ecosystems in order to build React Native apps, meaning like, you still had to know, Apple’s Xcode and Android Studio back then. But you didn’t have to be able to build an app and solve like the red screens of deaths that come up a million times.
Jay Cosgrove: We’ve seen those screens, those are fun.
Jay Cosgrove: Yeah. So you obviously defined what hybrid is, but what was like some of the immediate pluses, if you will, that, that we saw by by switching to React Native.
Jake Hendley: The number one plus for switching was being able to use react, which in my mind is a fantastic framework. The other would be performance and the general differences in the ecosystem. So with Cordova, you’re you’re leveraging these crazy plugin systems and compilation that shipping these different web views. And the deployments are crazy. I mean, it’s just it’s kind of a mess. Ionic made that much better ionic is built on top of Cordova. And they like initially used Angular as the front end view engine. And they re streamlined a lot of the build processes and command line tools. And so we use that which was definitely better than switching to React Native. It was like night and day, all of a sudden, it was very clear that we’re no longer building in web technologies. We’re building a native technologies just in a language and framework that we’re highly familiar with and very adept at.
Jay Cosgrov: You’re saying all the way down to just like UI interaction, you could tell?
Jake Hendley: Yeah, absolutely. Again, the big distinction there being I don’t want to get too nerdy here. Even with ionic, you’re still rendering divs, right, you’re running an HTML, and then hoping that it renders properly in a WebView, which it does, for the most part. But with React Native, you’re rendering what’s called a view, which intelligently proxies down to like the UI view on iOS and the equivalent on Android. So it’s truly native UI and rendering performance touch events, like everything’s better.
Rob Hall: It’s not a rendered web page. That’s trying to pretend to be a UI element.
Jake Hendley
Correct, yeah.
Rob Hall: Jake, if I, if I’m a developer, why would I want to choose React Native over purely native development? If I if I have this? If I have a native skillset? Why would I Why would I want to go with React Native over over just building something in Swift?
Jake Hendley: Sure. So I think that comes down to a few other questions about the project and about your team and everything else. And in the context of the question you just asked, like, if you’re a native developer building for the iOS ecosystem, you know, swift you haven’t experienced there, and you’re not building for Android, then absolutely use swift to stay in that ecosystem. You know, clarifying. If you never have plans to build your Android, then there’s really no reason to jump out of iOS ecosystem. But the big draw comes when you want iOS and Android. That’s a big one. Then I would say React Native all day, or if you have future plans to build Android may be something to consider.
Jay Cosgrove: Yeah, I mean, it seems like managing it from a single codebase would I mean is we’ve seen it just so much easier, especially when you get into the maintenance side of things. And when you factor in turnover of your team, or what we call a bus rate, or vacation rate, whatever you want to call it, you know, who’s out? how’s it gonna affect us actually getting to things if an issue were to come up?
Jake Hendley: Yeah, absolutely. And the team is the last one, if you have like a massive team that where you’ve got five guys that know Java, five guys that know swift, and you’ve got budget and runway timeframe lines up, I mean, you may want to choose native. But if you don’t have a very highly specific team in that fashion, even if you do, I still say at least look into React Native. But React Native is great because of the low barrier to entry. Again, it’s JavaScript, its react, languages and frameworks that people know. And the barrier to entry behind actually getting up to speed, say, Junior mid level developer coming in, and being able to contribute to the application is much lower than it would be in either the iOS or Android ecosystems, in my opinion.
Rob Hall: So so the ramp time, you know, if you have a fairly new developer on the team, you can get them integrated a lot faster.
Jake Hendley: Right yeah.
Jay Cosgrove: Any minuses that we should consider of going with React Native?
Jake Hendley: I mean, there’s a few different disadvantages there. And again, a lot of it is project centric. So if you’re going to build like a new Clash of Clans game, like an immersive 3d application, or some kind of AR VR application than React Native is definitely not the way to go. Because it does, it is abstracted from the lower level, just enough to where you can’t really hit those performance things. I mean, React Native is fantastic for business logic driven applications. And but if you want real time video processing, or you want to leverage something like the core ml, stuff that iOS is got on device, where you can actually run machine learning models on the device itself, then you probably want to go native there. And again, if you’re only targeting the apple ecosystem, and you have those devs. With that experience, you can do that. But I mean, there’s still a compelling case to use React Native for anything that doesn’t require those highly performant, or device specific functionalities. So for instance, if you’re, if you’re building a, if you’re building that AR VR app where you know, like, you can, your kid can hold it point at the cabinets and draw on it. So instead of them actually drawing on the cabinets with a crayon, you got an app for that. And that’s all the app is then you should go native. But if you want to build like a little thing, where parents can share their kids drawing on the cabinets, then all the business logic around that interaction can be React Native can be reused across iOS and Android, and can be built out by people who aren’t necessarily like your super senior engineer that’s leveraging that core ml, to build out this awesome interaction for the kid. The login screen can be created outside of that in React Native and still work very well.
Rob Hall: One of the criticisms that I’ve heard of React Native is that the compiled apps, what actually runs on your device, can be a little clunky, and maybe more resource intensive than is really necessary. For example, like I’ve even heard that Facebook has migrated away from using React Native in certain cases, like, I think their messenger app doesn’t use it anymore. Why is that? And is that a problem inherent to, to the framework itself? Is that a thing that’s really a showstopper?
Jake Hendley: It’s definitely not a showstopper. I mean, we’ve had some issues like that were terrible Android devices running React Native apps would drain battery at a faster rate, in some cases, and there are like at massive organizations, other compelling reasons to not be React Native, Airbnb has moved away from it. Facebook may be moving away from it. But contextually those are companies with 1000s and 1000s of developers and the knowledge share that they have is just phenomenal. And the budget, obviously, but specifically to compiled apps, taking more resources. I mean, I’d say that makes sense in some cases, because you can kind of think about it, like React Native is native with a couple caveats, right? If you need to do native stuff, you have to interact with a React Native bridge, it is a compiled JavaScript being shipped. So you’re relying on a connection layer between React Native and the underlying native language which, you know, iOS, swift or Objective C.
Unknown Speaker: Sure. So there’s, there’s essentially a translation layer that’s required to make the connection from the JavaScript that you’re writing and the lower level SDKs on the platform itself.
Jake Hendley: Sure. I don’t think that would lead to too many performance –
Rob Hall: In terms of like the size of the app. adds overhead, it adds overhead,
Jake Hendley: You’d be surprised they’re acting it out, they’re actually very, very small. Even in comparison to swift app, swift apps are generally larger, especially Java, or generally, that really comes down to what libraries and SDKs, you’re including, if you pull in Google’s entire library of SDKs, and to your Android app, then all those libraries is going to be 10 100 times larger than whatever your React Native app compiled down to in terms of size. The other issue there is the, I guess, the runtime itself. So while it is native code running on a new device, the React Native application itself gets run primarily in the JavaScript core, which is JavaScript engine that’s on device, which then communicates with the native layer for UI and various other things like that. And there are some issues are some differences in JavaScript core, then what you would have with, say, Chrome. But even in that case, Facebook is facebook has made massive strides, actually, they wrote an entire JavaScript engine called Hermes, that they ship with React Native Now by default for Android devices, because they had so much trouble with Android, JavaScript runtimes. They just rebuilt one and are now shipping at a standard.
Rob Hall: From your perspective, as a developer, do you enjoy working with React Native? Is there? Is there another framework that that you’re like, that’s actually more fun to use?
Jake Hendley: I mean, from a developer’s perspective, React Native is the most fun to use framework, you’re gonna run into issues no matter what, as a developer, but even debugging, and just the general flow of the code and the massive community of make building apps and React Native, a really good experience.
Jay Cosgrove: All right, Jake, you got to give us one story, cuz I know you’re a resident React Native guy here, one story of a fun challenge while building an app for one of our clients.
Rob Hall: And you can make it as technically nerdy as possible.
Jake Hendley: Alright, one story about a client. So there was a client called go, I can say the names of the clients right?
Rob Hall: No.
Jay Cosgrove: Wrong!
Jake Hendley: So there was a client called GoFan, we actually built a number of apps for we had a really good relationship with those guys. We initially built some like a ticketing app, that was, hey, it kind of ties in here. The first one we built was in ionic, and it went over really well. So that was a ticket purchasing app more or less. The second one was, the problem they were trying to solve is they wanted people standing at sporting events to be able to scan digital tickets of event goers with the application. And they also had these things called Honeywell scanners and all that. So.
Jay Cosgrove: Oh, yes, I remember testing on those things.
Rob Hall: Yes, the legendary ticket scanner.
Jay Cosgrove: Those beeps ringing in my memory, in my dreams at night.
Jake Hendley: Yep, and if it’s the wrong ticket, you know. But so that was a super challenging app to build for a couple reasons. One was, it had to function in two capacities, it needed to scan tickets with the camera on device, like QR code reader style, which I think a lot of people are familiar with. And two, it needed to be compatible with an iPod, the iPod could then be slid into a physical Honeywell scanning device and connect the application through probably saying these are QR code readers a shiny red laser, think about going to the grocery store, it’s pretty much that. And so that was very interesting, because it was the first time we actually got to dig into the React Native bridge. And the React Native bridge is again, the communication channel between React Native Land and native native land. And it’s the ability for you to write custom Objective C or swift or Java, and then expose that functionality that you wrote natively to your React Native application. And so that’s what we did, we leveraged the Honeywell had a nice SDK and Objective C. So we wrote some code around that that would forward various QR codes, battery levels, device statuses, all this stuff to our React Native app, and we could manage that stuff. When we initially started the project we were using the React Native bridge is I guess you’d call it method delegation where you write a object in Objective C and put a method on it. And then you tell, pull in a header and export the module. And you pretty much expose that objects method to React Native, then there was an addition, or there was a decision to refactor that. So we changed that to leverage React Native bridges, a venting system, which provided us with a much more seamless communication between the React Native app and native because JavaScript is a very event driven language. And this just turned all of our custom code into an event emitter, which would just fire off events. And we can consume it in JavaScript just like we do everything else. I click events and all that stuff, except this time, these are custom events coming from this hardware device. It’s like QR codes scanned. And here’s a QR code. So we could check that against our tickets to make sure you know, nobody’s trying to sneak into the event with their ticket, or they haven’t already redeemed it, or all that kind of stuff. So that was a very fun.
Rob Hall: Next question, I want to dig into a little bit from a solution architecture point of view. If if I’m a customer, and I know I’m going to have a mobile app, how should I approach assessing whether or not React Native is right for my project?
Jake Hendley: The first question to ask is, am I only targeting the apple ecosystem? So if you have no plans to build an Android app, and you really want to leverage different devices in the apple ecosystem, like a watch and a iOS device, and then like TV OS, that’s probably something you should consider going native for. I mean, it’s pretty much just a list of reasons not to go with React Native, and that list is very short. So performance requirements, if you need highly performance stuff, or you’re leveraging core ml or building kind of AR augmented reality stuff, you probably don’t want –
Rob Hall: 3D games, right?
Jake Hendley: Yeah, exactly. 3d games, it’s probably not best for that. It also depends on your team. So if you have a bunch of people familiar with web technologies on your team, and you don’t want to go out and hire native devs, or you don’t want to ramp up your in house, folks, then you probably want to go React Native because again, the barrier to entry and learning curve on that is much, much lower than, say figuring out how to build a kotlin application. But at the end of the day, building React Native because React Native is awesome.
Rob Hall: From a developer’s perspective, Jake, if if I know a little JavaScript, and I’m familiar with HTML and CSS, how can I get started learning React Native, what’s the best way to learn?
Jake Hendley: The first step would be to learn react. So if you don’t know react, and jumping right into React Native is doable, but it’s probably not what you want to do, because going into React Native does add the additional complexities of the native ecosystems. And I mean, it’s just generally it’s harder to build apps, native apps than it is to build web apps. So they’re just a larger overhead there and say, you know, react, how would you get started building React Native. Honestly starting on the docks, React Native has amazing docks, they’ve got a great community. There’s a ton of existing libraries and tutorials out there that can just get you up and up and running extremely quickly.
Jay Cosgrove: Jake, would you mind doing us the favor of explaining a little bit of your background.
Rob Hall: As long as it doesn’t violate your witness protection program contract.
Jake Hendley: I plead the fifth on that. And obviously, this background is the one that the witness protection people built for me. So, been a developer for eight years now, took a less traditional route, went from Mountain guide to developer via boot camp, and then taught myself a little bit before that, and really just learned on my feet for my career. Now, over the past seven years, I think this most recent app we built was at number 11, or 12, depending on how you count them. And that’s 11 and 12. native apps. That’s been fun.
Rob Hall: Did you say you were a mountain guide?
Jake Hendley
Yep. I never told you this Rob?
Rob Hall: I knew you were into climbing but –
Jake Hendley
So yeah, before all this it was a I did a few outdoor courses, lived out of my truck in Utah and Wyoming I say mountain guide, but I really mean like Sherpa who doesn’t shower and gets paid your money to hike with older individuals up small hills.
Jay Cosgrove: Sounds like the life Why would you trade that then?
Rob Hall: Especially the not showering part?
Jake Hendley: Yeah, well, it’s kind of hard to continue, I fell off that mountain like 10 years ago and broke my back, shattered my leg and all that so,. I just kind of decided it wasn’t a sustainable career.
Rob Hall: We’re glad you’re still with us.
Jay Cosgrove: So, are there any like tips or tricks that you’ve learned that you would want to share with maybe developers out there that are just getting their hands dirty with React Native.
Jake Hendley: So first off, I would say leverage as much existing technology as possible when you’re first getting started. So there are a lot of libraries out there for React Native that take a lot of the burden off, there’s one called native bass and another one called React Native elements that allow you to kind of drop in pre built components without having to get into the nitty gritty of like, what does this touchable opacity do? Instead, you can just say, here’s a button from one of these libraries. And secondly, I would say keep in mind that sense it’s react, you can leverage any non UI library that react leverages, so whether that’s Redux or rematch or any of that. Also, you should definitely use a state management library like Redux or mob x and probably rematch on top of that. But yeah, just getting started, make sure you read all the docs and keep your stuff up to date.
Rob Hall: Thank you for listening to the experience lab from Digital scientists. To learn more about our team and the great work we do or even hire us, visit our website at Digital scientists.com
Rob Hall: This is the experience lab, the official podcast of digital scientists from Atlanta, Georgia. We’re an experienced lab that explores and builds digital products. My name is Rob Hall, and I’m the Senior Director of Product at DS.
Jay Cosgrove: And in the Jay Cosgrove senior product manager.
Rob Hall: Thanks for listening.
Rob Hall: So the other day I was drinking a blueberry tart. Have you guys ever had tarts before? Are you into those?
Jay Cosgrove: I have no clue what you’re talking about right now.
Rob Hall: It’s beer Jay.
Jake Hendley: It’s like a sour.
Rob Hall: Oh, yeah. A blueberry tart. Sour. Yes.
Jay Cosgrove: Sour okay.
Rob Hall: Yeah yeah yeah.
Jay Cosgrove: I do like sours. But I’ve never had that.
Jake Hendley: Tart means like, super sour.
Rob Hall: It was very sour. But but kind of in a good way. It’s hard to explain. Like, it wasn’t so sour that it was like eating Sour Patch Kids.
Jay Cosgrove: Well, I’m glad you differentiate that.
Jake Hendley: Right?
Rob Hall: Yeah.
Jake Hendley: Not as bad as like a like a goze.
Jay Cosgrove: What is that?
Jake Hendley: Have you ever had a goze?
Rob Hall: I don’t know, if I have.
Jake Hendley: Goze. It’s like this old Austrian or German or something recipe for the most sour thing that you’ve ever had in your life that is carbonated and has alcohol in it. But they call it a beer. I don’t know if that’s really true. But it’s like drinking Sour Patch Kids.
Rob Hall: Yeah, that sounds terrible.
Jake Hendley: Or salt water with lemon in it? Yeah.
Jay Cosgrove: That’s awful.
Jake Hendley: People love it.
Rob Hall: Well, joining us today on the podcast is our wonderful colleague, Jake Henley.
Jake Hendley: Hello, everybody.
Rob Hall: Jake is one of our senior developers here at Digital scientists. And and today, we’re gonna have a conversation about a number of things, not the least of which might include some references to craft beer, which we have a mutual appreciation of. But the primary reason we’re here today is to talk about our experiences using certain mobile frameworks in building mobile applications, in particular, the React Native framework. So we get we get asked certain questions pretty often about whether or not we do native development. And by native development, we’re typically referring to iOS or Android, what is the real story when we’re speaking of native development? And and so there’s been this evolving trend over the years to say I can create native apps that are truly native, but without knowing swift or Objective C, or Java on the Google side, Jake, can can you define Really? What is React Native? And Where’d it come from? How does it work? And is it fair to say that, that we’re creating truly native apps by using it?
Jake Hendley: So React Native is a pretty awesome framework from Facebook, they started working on it like five or six years ago. And it’s generally, like you said, it’s a JavaScript framework that allows you to build native apps using the prolific language of JavaScript, which, you know, most people know, at the end of the day, React Native is just react. So another product from Facebook is react, which is a JavaScript framework for user interfaces, what they’ve done with React Native is, well, a couple things. Generally, they’ve changed the kind of target of development from what everybody knows and loves HTML to native platforms. Generally, iOS vs. Java, Android.
Rob Hall: It’s a JavaScript framework. Are we really building native apps with it?
Jake Hendley: Yeah, absolutely. Again, I guess a good distinction to make here is where it came from Facebook obviously had react first, which was this game changing framework for building UI’s. And they wanted to be able to apply that to the native, right. So normally, UI’s from react would be compiling on HTML, or shipped as HTML, building, you know, websites and all that. With React Native, they implemented a different view layer, if you will, that allowed, like the same react, we know and love to control native UI elements on both Android and iOS. So you can kind of think of it as with normal web development, obviously, you’re rendering Dibs and HTML, you know, paragraph tags, all that with React Native, you’re rendering views and texts primarily. And under the hood, those are actually proxy down to truly native UI components. So it’s not a hybrid app. It’s not some kind of weird offshoot, it’s directly native application that just runs in JavaScript land.
Jay Cosgrove: That’s awesome. You mentioned something interesting there. You mentioned hybrid apps. And I think right at the front of this, it would be cool to define. Maybe the three distinctions, or at least that’s how they lay out in my mind is you have truly native apps, and then you have kind of React Native, which was what we’re talking about today. But the precursor to those were sometimes called hybrids, right?
Rob Hall: And we used to, we used to do a lot of actual hybrid work right.
Jake Hendley: Before we switched to React Native. We were doing a lot of stuff with Apache Cordova and a framework called ionic. So I can start there. So a hybrid app is an application that’s kind of shoehorning web technologies into the native world. So what that means is, back in the day, Cordova came out and allowed you to ship HTML as a native app. And all that would do under the hood is pretty much render that HTML in a web browser without any of the Chrome, Chrome being like the URL bar or the back button or any of that. They really just took an HTML page, dropped it in a web browser and said, hey, look, it’s native, even though it’s really not. So before Hybrid’s, obviously, there was native, you know, Objective C, Java, or the two languages are the two big platforms decided on and that’s what they ran with. And then Cordova came out, see, what was it, PhoneGap came out first, which was a an Adobe product, which was then open sourced and donated to the Apache Software Foundation, which came became Apache Cordova. And then a few others came out as competitors around the same time, mostly because people were trying to monetize the idea of hybrid frameworks. So you had a thing called titanium, which charged license fees, and then another one called Xamarin, which is for like the dotnet, C sharp crowd. And then PhoneGap has another pro level or thing it’s called PhoneGap build or something like that, where they were trying to get subscription tacked on to the hybrid framework. But then React Native jumps on the scene and it was awesome. It was so much better than all that other stuff. Except everything was broken in the beginning, like React Native was absolutely terrible. Until version, zero dot 40. You pretty, in the beginning, you had to be a native developer to use React Native.
Rob Hall: So lots of promise, but not a lot of proof.
Jake Hendley: Exactly. So React Native is five or six years old, I’d say about three years ago, maybe a little bit more, it got to the point where you didn’t have to be super versed in native development in the native ecosystems in order to build React Native apps, meaning like, you still had to know, Apple’s Xcode and Android Studio back then. But you didn’t have to be able to build an app and solve like the red screens of deaths that come up a million times.
Jay Cosgrove: We’ve seen those screens, those are fun.
Jay Cosgrove: Yeah. So you obviously defined what hybrid is, but what was like some of the immediate pluses, if you will, that, that we saw by by switching to React Native.
Jake Hendley: The number one plus for switching was being able to use react, which in my mind is a fantastic framework. The other would be performance and the general differences in the ecosystem. So with Cordova, you’re you’re leveraging these crazy plugin systems and compilation that shipping these different web views. And the deployments are crazy. I mean, it’s just it’s kind of a mess. Ionic made that much better ionic is built on top of Cordova. And they like initially used Angular as the front end view engine. And they re streamlined a lot of the build processes and command line tools. And so we use that which was definitely better than switching to React Native. It was like night and day, all of a sudden, it was very clear that we’re no longer building in web technologies. We’re building a native technologies just in a language and framework that we’re highly familiar with and very adept at.
Jay Cosgrov: You’re saying all the way down to just like UI interaction, you could tell?
Jake Hendley: Yeah, absolutely. Again, the big distinction there being I don’t want to get too nerdy here. Even with ionic, you’re still rendering divs, right, you’re running an HTML, and then hoping that it renders properly in a WebView, which it does, for the most part. But with React Native, you’re rendering what’s called a view, which intelligently proxies down to like the UI view on iOS and the equivalent on Android. So it’s truly native UI and rendering performance touch events, like everything’s better.
Rob Hall: It’s not a rendered web page. That’s trying to pretend to be a UI element.
Jake Hendley
Correct, yeah.
Rob Hall: Jake, if I, if I’m a developer, why would I want to choose React Native over purely native development? If I if I have this? If I have a native skillset? Why would I Why would I want to go with React Native over over just building something in Swift?
Jake Hendley: Sure. So I think that comes down to a few other questions about the project and about your team and everything else. And in the context of the question you just asked, like, if you’re a native developer building for the iOS ecosystem, you know, swift you haven’t experienced there, and you’re not building for Android, then absolutely use swift to stay in that ecosystem. You know, clarifying. If you never have plans to build your Android, then there’s really no reason to jump out of iOS ecosystem. But the big draw comes when you want iOS and Android. That’s a big one. Then I would say React Native all day, or if you have future plans to build Android may be something to consider.
Jay Cosgrove: Yeah, I mean, it seems like managing it from a single codebase would I mean is we’ve seen it just so much easier, especially when you get into the maintenance side of things. And when you factor in turnover of your team, or what we call a bus rate, or vacation rate, whatever you want to call it, you know, who’s out? how’s it gonna affect us actually getting to things if an issue were to come up?
Jake Hendley: Yeah, absolutely. And the team is the last one, if you have like a massive team that where you’ve got five guys that know Java, five guys that know swift, and you’ve got budget and runway timeframe lines up, I mean, you may want to choose native. But if you don’t have a very highly specific team in that fashion, even if you do, I still say at least look into React Native. But React Native is great because of the low barrier to entry. Again, it’s JavaScript, its react, languages and frameworks that people know. And the barrier to entry behind actually getting up to speed, say, Junior mid level developer coming in, and being able to contribute to the application is much lower than it would be in either the iOS or Android ecosystems, in my opinion.
Rob Hall: So so the ramp time, you know, if you have a fairly new developer on the team, you can get them integrated a lot faster.
Jake Hendley: Right yeah.
Jay Cosgrove: Any minuses that we should consider of going with React Native?
Jake Hendley: I mean, there’s a few different disadvantages there. And again, a lot of it is project centric. So if you’re going to build like a new Clash of Clans game, like an immersive 3d application, or some kind of AR VR application than React Native is definitely not the way to go. Because it does, it is abstracted from the lower level, just enough to where you can’t really hit those performance things. I mean, React Native is fantastic for business logic driven applications. And but if you want real time video processing, or you want to leverage something like the core ml, stuff that iOS is got on device, where you can actually run machine learning models on the device itself, then you probably want to go native there. And again, if you’re only targeting the apple ecosystem, and you have those devs. With that experience, you can do that. But I mean, there’s still a compelling case to use React Native for anything that doesn’t require those highly performant, or device specific functionalities. So for instance, if you’re, if you’re building a, if you’re building that AR VR app where you know, like, you can, your kid can hold it point at the cabinets and draw on it. So instead of them actually drawing on the cabinets with a crayon, you got an app for that. And that’s all the app is then you should go native. But if you want to build like a little thing, where parents can share their kids drawing on the cabinets, then all the business logic around that interaction can be React Native can be reused across iOS and Android, and can be built out by people who aren’t necessarily like your super senior engineer that’s leveraging that core ml, to build out this awesome interaction for the kid. The login screen can be created outside of that in React Native and still work very well.
Rob Hall: One of the criticisms that I’ve heard of React Native is that the compiled apps, what actually runs on your device, can be a little clunky, and maybe more resource intensive than is really necessary. For example, like I’ve even heard that Facebook has migrated away from using React Native in certain cases, like, I think their messenger app doesn’t use it anymore. Why is that? And is that a problem inherent to, to the framework itself? Is that a thing that’s really a showstopper?
Jake Hendley: It’s definitely not a showstopper. I mean, we’ve had some issues like that were terrible Android devices running React Native apps would drain battery at a faster rate, in some cases, and there are like at massive organizations, other compelling reasons to not be React Native, Airbnb has moved away from it. Facebook may be moving away from it. But contextually those are companies with 1000s and 1000s of developers and the knowledge share that they have is just phenomenal. And the budget, obviously, but specifically to compiled apps, taking more resources. I mean, I’d say that makes sense in some cases, because you can kind of think about it, like React Native is native with a couple caveats, right? If you need to do native stuff, you have to interact with a React Native bridge, it is a compiled JavaScript being shipped. So you’re relying on a connection layer between React Native and the underlying native language which, you know, iOS, swift or Objective C.
Unknown Speaker: Sure. So there’s, there’s essentially a translation layer that’s required to make the connection from the JavaScript that you’re writing and the lower level SDKs on the platform itself.
Jake Hendley: Sure. I don’t think that would lead to too many performance –
Rob Hall: In terms of like the size of the app. adds overhead, it adds overhead,
Jake Hendley: You’d be surprised they’re acting it out, they’re actually very, very small. Even in comparison to swift app, swift apps are generally larger, especially Java, or generally, that really comes down to what libraries and SDKs, you’re including, if you pull in Google’s entire library of SDKs, and to your Android app, then all those libraries is going to be 10 100 times larger than whatever your React Native app compiled down to in terms of size. The other issue there is the, I guess, the runtime itself. So while it is native code running on a new device, the React Native application itself gets run primarily in the JavaScript core, which is JavaScript engine that’s on device, which then communicates with the native layer for UI and various other things like that. And there are some issues are some differences in JavaScript core, then what you would have with, say, Chrome. But even in that case, Facebook is facebook has made massive strides, actually, they wrote an entire JavaScript engine called Hermes, that they ship with React Native Now by default for Android devices, because they had so much trouble with Android, JavaScript runtimes. They just rebuilt one and are now shipping at a standard.
Rob Hall: From your perspective, as a developer, do you enjoy working with React Native? Is there? Is there another framework that that you’re like, that’s actually more fun to use?
Jake Hendley: I mean, from a developer’s perspective, React Native is the most fun to use framework, you’re gonna run into issues no matter what, as a developer, but even debugging, and just the general flow of the code and the massive community of make building apps and React Native, a really good experience.
Jay Cosgrove: All right, Jake, you got to give us one story, cuz I know you’re a resident React Native guy here, one story of a fun challenge while building an app for one of our clients.
Rob Hall: And you can make it as technically nerdy as possible.
Jake Hendley: Alright, one story about a client. So there was a client called go, I can say the names of the clients right?
Rob Hall: No.
Jay Cosgrove: Wrong!
Jake Hendley: So there was a client called GoFan, we actually built a number of apps for we had a really good relationship with those guys. We initially built some like a ticketing app, that was, hey, it kind of ties in here. The first one we built was in ionic, and it went over really well. So that was a ticket purchasing app more or less. The second one was, the problem they were trying to solve is they wanted people standing at sporting events to be able to scan digital tickets of event goers with the application. And they also had these things called Honeywell scanners and all that. So.
Jay Cosgrove: Oh, yes, I remember testing on those things.
Rob Hall: Yes, the legendary ticket scanner.
Jay Cosgrove: Those beeps ringing in my memory, in my dreams at night.
Jake Hendley: Yep, and if it’s the wrong ticket, you know. But so that was a super challenging app to build for a couple reasons. One was, it had to function in two capacities, it needed to scan tickets with the camera on device, like QR code reader style, which I think a lot of people are familiar with. And two, it needed to be compatible with an iPod, the iPod could then be slid into a physical Honeywell scanning device and connect the application through probably saying these are QR code readers a shiny red laser, think about going to the grocery store, it’s pretty much that. And so that was very interesting, because it was the first time we actually got to dig into the React Native bridge. And the React Native bridge is again, the communication channel between React Native Land and native native land. And it’s the ability for you to write custom Objective C or swift or Java, and then expose that functionality that you wrote natively to your React Native application. And so that’s what we did, we leveraged the Honeywell had a nice SDK and Objective C. So we wrote some code around that that would forward various QR codes, battery levels, device statuses, all this stuff to our React Native app, and we could manage that stuff. When we initially started the project we were using the React Native bridge is I guess you’d call it method delegation where you write a object in Objective C and put a method on it. And then you tell, pull in a header and export the module. And you pretty much expose that objects method to React Native, then there was an addition, or there was a decision to refactor that. So we changed that to leverage React Native bridges, a venting system, which provided us with a much more seamless communication between the React Native app and native because JavaScript is a very event driven language. And this just turned all of our custom code into an event emitter, which would just fire off events. And we can consume it in JavaScript just like we do everything else. I click events and all that stuff, except this time, these are custom events coming from this hardware device. It’s like QR codes scanned. And here’s a QR code. So we could check that against our tickets to make sure you know, nobody’s trying to sneak into the event with their ticket, or they haven’t already redeemed it, or all that kind of stuff. So that was a very fun.
Rob Hall: Next question, I want to dig into a little bit from a solution architecture point of view. If if I’m a customer, and I know I’m going to have a mobile app, how should I approach assessing whether or not React Native is right for my project?
Jake Hendley: The first question to ask is, am I only targeting the apple ecosystem? So if you have no plans to build an Android app, and you really want to leverage different devices in the apple ecosystem, like a watch and a iOS device, and then like TV OS, that’s probably something you should consider going native for. I mean, it’s pretty much just a list of reasons not to go with React Native, and that list is very short. So performance requirements, if you need highly performance stuff, or you’re leveraging core ml or building kind of AR augmented reality stuff, you probably don’t want –
Rob Hall: 3D games, right?
Jake Hendley: Yeah, exactly. 3d games, it’s probably not best for that. It also depends on your team. So if you have a bunch of people familiar with web technologies on your team, and you don’t want to go out and hire native devs, or you don’t want to ramp up your in house, folks, then you probably want to go React Native because again, the barrier to entry and learning curve on that is much, much lower than, say figuring out how to build a kotlin application. But at the end of the day, building React Native because React Native is awesome.
Rob Hall: From a developer’s perspective, Jake, if if I know a little JavaScript, and I’m familiar with HTML and CSS, how can I get started learning React Native, what’s the best way to learn?
Jake Hendley: The first step would be to learn react. So if you don’t know react, and jumping right into React Native is doable, but it’s probably not what you want to do, because going into React Native does add the additional complexities of the native ecosystems. And I mean, it’s just generally it’s harder to build apps, native apps than it is to build web apps. So they’re just a larger overhead there and say, you know, react, how would you get started building React Native. Honestly starting on the docks, React Native has amazing docks, they’ve got a great community. There’s a ton of existing libraries and tutorials out there that can just get you up and up and running extremely quickly.
Jay Cosgrove: Jake, would you mind doing us the favor of explaining a little bit of your background.
Rob Hall: As long as it doesn’t violate your witness protection program contract.
Jake Hendley: I plead the fifth on that. And obviously, this background is the one that the witness protection people built for me. So, been a developer for eight years now, took a less traditional route, went from Mountain guide to developer via boot camp, and then taught myself a little bit before that, and really just learned on my feet for my career. Now, over the past seven years, I think this most recent app we built was at number 11, or 12, depending on how you count them. And that’s 11 and 12. native apps. That’s been fun.
Rob Hall: Did you say you were a mountain guide?
Jake Hendley
Yep. I never told you this Rob?
Rob Hall: I knew you were into climbing but –
Jake Hendley
So yeah, before all this it was a I did a few outdoor courses, lived out of my truck in Utah and Wyoming I say mountain guide, but I really mean like Sherpa who doesn’t shower and gets paid your money to hike with older individuals up small hills.
Jay Cosgrove: Sounds like the life Why would you trade that then?
Rob Hall: Especially the not showering part?
Jake Hendley: Yeah, well, it’s kind of hard to continue, I fell off that mountain like 10 years ago and broke my back, shattered my leg and all that so,. I just kind of decided it wasn’t a sustainable career.
Rob Hall: We’re glad you’re still with us.
Jay Cosgrove: So, are there any like tips or tricks that you’ve learned that you would want to share with maybe developers out there that are just getting their hands dirty with React Native.
Jake Hendley: So first off, I would say leverage as much existing technology as possible when you’re first getting started. So there are a lot of libraries out there for React Native that take a lot of the burden off, there’s one called native bass and another one called React Native elements that allow you to kind of drop in pre built components without having to get into the nitty gritty of like, what does this touchable opacity do? Instead, you can just say, here’s a button from one of these libraries. And secondly, I would say keep in mind that sense it’s react, you can leverage any non UI library that react leverages, so whether that’s Redux or rematch or any of that. Also, you should definitely use a state management library like Redux or mob x and probably rematch on top of that. But yeah, just getting started, make sure you read all the docs and keep your stuff up to date.
Rob Hall: Thank you for listening to the experience lab from Digital scientists. To learn more about our team and the great work we do or even hire us, visit our website at Digital scientists.com
