54: Hybrid vs. Native Apps
Published December 1, 2020Run time: 00:13:00
One of the first development decisions you’ll make when building an app is whether to build on a native platform or a hybrid platform. In this episode, Tim gets into best use cases for hybrid and native apps, along with each platform’s limitations, so you can decide the best approach for your project.
In this episode, you will learn:
- The languages used to write native apps and hybrid apps
- Use cases for using a hybrid platform
- The quirks and limitations of hybrid apps
- Use cases for building apps natively
- The downfalls of building native apps
This episode is brought to you by The Jed Mahonis Group, where we make sense of mobile app development with our non-technical approach to building custom mobile software solutions. Learn more at https://jmg.mn.
Recorded November 19, 2020 | Edited by Jordan Daoust | Produced by Jenny Karkowski
Show Notes:
Episode Transcript:
Tim Bornholdt 0:00
Welcome to Constant Variables, a podcast where we take a non-technical look at all things technical. I'm Tim Bornholdt. Let's get nerdy.
Today on the show, we are talking about one of the first big decisions you'll make when building an app. Do you build a hybrid app? Or do you build a native app? A little context, we at The Jed Mahonis Group typically use native frameworks when we're building apps. We only build native apps, so we might be a little bit biased as we're describing this. But there are times where it does make sense to build an app on a hybrid platform. We're not naive, we know that there's different constraints for different cases. So in this episode, we'll talk about hybrid platforms and native platforms and give you pros and cons of both, so that you can decide the best approach for your project.
So first, what is a native app? Native apps are apps written using the tools and frameworks provided by the platform vendor. So if we're talking about an iOS app, this is typically written using Xcode as the tool that writes the code, and then either Objective C, which is kind of an older language, or Swift, which is the more modern language provided by Apple. If we're talking about Android apps, we're talking about using Android Studio to write the code and then either Java for, again, older apps, or Kotlin, which is the newer language provided by Google.
So that's what a native app is, what is a hybrid app? Well a hybrid app is where you write the code in one language, and then you can compile it to native code, which will run on multiple different platforms. So for example, let's talk about Xamarin. So if you're using Xamarin, you would write the code using C sharp, and then access libraries provided by Microsoft. And once the code is written, you can say, Make this code an iOS app or make this code an Android app.
There's a few use cases for building on a hybrid platform. So first of all, you probably are going to use that for building out an MVP, if you want to just test out an idea and see if it works. Most of the time, these tools are a lot more comfortable for, say, web developers to come and pick up instead of having to learn how to do, you know, true native app development. As a result, you can get to market faster with some of these tools. There's also a lower cost up front, because you're kind of writing the code one time and just shooting it out everywhere. And as a result, it also means that it's a shorter development time, because usually when you're doing native development, you kind of have one platform leapfrogging the other. So you're kind of trailblazing with one platform, then having the other one come back and pick up the pieces and have kind of a clear trail for it. This is what we typically do with our apps.
Now some downfalls of going the hybrid way are it tends to be a poorer user experience. There's something about hybrid apps that users might not necessarily be able to articulate, but there's little quirks and weird things about them. Next, another downfall is scale. So if your company outgrows the limitations that a hybrid platform gives you, then you'll have to start from scratch anyway, building out native apps. Hybrid apps also have more restrictions around what types of specific device functionality they use, such as GPS location, getting at your contact list. It's a little bit harder to get at those with a hybrid app. It's not impossible, and there are ways to do it. But you're kind of more limited and you're kind of put into a box with what you can do with that information.
The last big downfall is that you're basically tied to whichever platform you go for. So if let's say you pick React Native as your hybrid platform of choice, if a new operating system comes out from Apple or Google and they have new functionalities to the devices that you want to use, you have to wait for React Native to implement that in its own code. You can't just go and implement them right away. You have to wait for React Native to implement it on their end, which then in turn, you can implement it on your end.
There's a few different hybrid platforms out there that all have kind of different pros and cons, depending on what type of development team you're working with. React Native is probably one of the most popular ones, especially if you have a development team that's based off the web. React Native is written in JavaScript. So it's a lot easier for someone who's a web developer to pick it up and kind of get started right away. Xamarin, which we also talked about, is another very popular one. It's pioneered by Microsoft. Ionic is another one. I'm not as familiar with Ionic. But I know a lot of shops come to us and say, Do you work in Ionic? And we say, No. And finally, Flutter is an option that Google is heavily pushing as its way of kind of having one platform that you write for and then it can compile natively for iOS and Android. Again, it's still a hybrid approach, there's still all the downfalls of having that. But Flutter is kind of unique in that way, in that it actually spits out the code that then you could work on natively if you chose to, but you probably wouldn't, because it kind of defeats the purpose of having a hybrid app in the first place.
Now, some use cases for building apps natively. There's a lot of pros. You get a better user experience. Everything kind of works the way that you expect it to, because it's, again, dealing with the system provided tools and features that are given to you. There's also faster performance. The way that a lot of these hybrid apps work is you have a little bit of a layer in between what the code you're writing is and the operating system. So that little layer is just more work that the computer, the phone, has to do in order to actually make your app work. As a result, it makes your app go slower, because it has to have more time and more memory to get things done. These days, the platform's are actually getting pretty good. And the performance for most part is pretty similar. The only differences that you'll see are when it's really intensive, when you're doing some really intensive processing. So let's say, you have a map feature in your app. Performance with maps is still something that is pretty poor on a hybrid solution versus a native solution.
Security wise, building natively is much better, because again, you don't have code in between you and the phone. You don't have to kind of translate things. And that translation opens up a lot of holes that you as a developer, as that developer, aren't going to be able to patch because it's like you're writing code that Microsoft is translating for Apple, and that whole Microsoft layer in the middle, that's the part that could have the security vulnerabilities in it.
Offline mode is another big reason you might want to build natively. A lot of hybrid apps do have the capability of storing information offline and holding on to it. But it's a lot easier to do with a native solution than it is with a hybrid solution. So that's just another thing to think about especially if you're doing one of those frameworks that does require access to the internet. I think Ionic is that way, don't quote me on that. But I believe you do need to have some kind of constant internet connection in order to get some value out of it. So that's just another feature and another check in the box of a native app. You don't have to worry about that.
And finally, flexibility, let's say iOS 15 comes out next year with some fancy new feature that you really want to implement in your app. You can do it right away, you can download the SDK as soon as Apple announces it, and you can get going right away. If you are a hybrid app developer, you need to wait for that new fancy feature to be implemented by React Native or Xamarin or Ionic. And then you can come back and implement it into your app. You don't have to worry about that middleman when you're talking about building native apps.
Now, that doesn't mean that it's all, you know, blue skies, and no rain at all. There are some downfalls to building native apps. Cost is absolutely the biggest one. It's not easy to build native apps. There is a lot of work that goes into managing memory and everything else that goes along with the experience that one would expect with a native app. And also, you have to be supporting two platforms. When you're building hybrid apps, you can really do one platform, you write your code one time, and it works on multiple platforms. But with a native app, you need to specifically have someone focusing on iOS, and someone specifically focusing on Android. So that's two different developers as opposed to the one. So obviously, it's going to cost more. And as a result, sometimes it does take longer to build out because you do need to focus on those things.
That's actually, another good use case for native apps is accessibility, if that's a concern of yours, which it absolutely should be. Sometimes the accessibility features of a React Native app or any other kind of hybrid app, they don't take into account some of the natively provided accessibility features. So sometimes you're kind of out on a lurch when you're dealing with a React app, you have to do a lot more work platform specific, and it ends up kind of being a wash, as opposed to just doing it in the quote unquote, right way in the first place.
So some final thoughts. Again, like I said at the outset, I'm pretty biased towards wanting to build native solutions. If your idea is easy, very simple, something like a tool that just kind of displays some data, like if you just have a table with some information on it, and you're just inputting things in there. Those are the best kind of apps that would be best served for a hybrid solution. But the more complex your app gets, and the more sort of nuanced features that you put into it, you're going to really want to focus on a native experience. Again, it costs more up front and it takes a little bit longer to get done. But it's kind of one of those things where do you want to do it the right way? Or do you want to just get something out there, prove out a concept and kind of iterate on top of it?
There's really many, many ways to go. I know lots of successful apps that are built on hybrid platforms. There's all kinds of big articles out there that you can read of, you know, for example, a few years ago, Facebook, who actually owns React Native, ported everything over to React Native, and then decided to change back to native apps, because it just ended up not working for them. Now, Facebook does a lot of weird creepy things inside their app, so take that for what it's worth. But there was one recently from Airbnb, where they said that they were going to be not contributing to React Native anymore, and they were going to switch everything natively.
So you kind of have to talk with your development team and see which approach makes the most sense for you, and what kind of game are you playing too. If you're trying to play a short game of just kind of get something out there, flip it, see what happens and move on from there, then maybe you're better off with a hybrid app. Does your development team know C sharp better than they know Objective C? Well, then they probably would be more apt to going to Xamarin. It's all kind of developer preference. And like we say, you know, with the old, when you take a math test, for example, and your teacher makes you show your work, it's kind of the same way. The reason that they ask you to show your work is because they want to see how you arrived at the solution. And developers can arrive from the same solution at the end of the day, it's an app, right? But how you get to that solution can be very telling as to what type of developer you are.
So take it for what it's worth. You pretty much are going to be stuck to what your development team wants to do. For example, if you really wanted to work with us, and you said we have to have a hybrid app solution for you, we would probably try to either talk you out of it or refer you to one of our friends that does do that kind of stuff, because we don't. So you're kind of stuck with what your developers tell you to do. But these are just some thoughts that you can use if you want to try to figure out which approach here is going to be right for your team.
Show notes for this episode can be found at constantvariables.co. You can get in touch with us by emailing Hello@constant variables.co. I'm @Tim Bornholdt on Twitter and the show is @CV_podcast. Today's episode was produced by Jenny Karkowski and edited by the zany Jordan Daoust. If you have one quick minutes before you leave, we'd really love it if you left a review for us on the Apple Podcast app. It shouldn't take much time at all. And it seriously helps us find new people for our show. So just head to constantvariables.co/review and we will link you right there.
This episode was brought to you by The Jed Mahonis Group. If you're looking for a technical team who can help make sense of mobile software development, give us a shout at jmg.mn.