Native vs Hybrid Apps: When to use & What’s Next in Mobile App Dev With Simon Reggiani

Transcript

Ledge: Simon, great to have you here. I wondered if you’d give a couple-of-minute introduction of you and your work.

Simon: Sure. First, thanks for having me. I guess I can start with a bit of background about me and what I’ve been doing so far. As you can probably hear from my accent, I’m originally from France. I did my masters there and worked as a Java enterprise dev for a few years which was kind of boring ─ hence, me moving to Canada and finding jobs in startups, mostly Android development. I was an Android dev for about six years in Vancouver including, in 2016, as a senior Android at Slack working on a few features including the calls feature.

I decided to leave Slack to join some friends doing rideshare platform called “Poparide” and the idea was to do the IOS and the Android app as well.

That’s my skill set. I have been working for them since then and I’m also doing some freelancing on the side; and, recently ─ about three months ago, I started a new project for this company called “Bungalow.” They’re doing some real estate startup in San Francisco and they needed an app. They wanted someone to build in React Native and I said, “Sure. Let’s do it” because I added iOS to my skills and, now, I need to add something else.

After a year of doing IOS and Android, I started to understand the need for a cross platform. I said, “Yes, let’s do this.” It’s really a fun challenge. It is a challenge coming from Android and IOS, from native word to something like JavaScript and learn everything around that.

Again, I get to learn npm and gs. The last time I did gs was ten years ago and js now is probably different than ten years ago.

Learning that, learning TypeScript, learning React Native, learning Redux is a completely different paradigm. I find React Native compared to native stuff and all the community around React phenomenal. There’s a lot of amazing ─ libraries like Redux and stuff like that that helps tremendously streamline your development.

Ledge: So you’ve been on all the different technologies for native. You’ve got Objective C, Swift, Java [crosstalk] cross platform, React Native. Obviously, there are entries in that space like Ionic, PhoneGap, etc.

Maybe for business people or technology or startups who are thinking, should I do two native apps? Should I do one cross-platform? how do you figure that out? What’s the core difference from the engineering standpoint on all those options?

People say, “I want an app.” When you’re building a business, you want to do apps. Of course, you want to do apps.

What’s the difference? Why would you choose one of those things versus the other? And even if you went native, which one would you choose?

There a lot of questions there.

Simon: That’s a very good question. I think the answer is “it depends.” It’s going to depend on a lot of things but one will be budget, obviously, and the quality that you want from the apps.

So if you know that’s going to be really heavy like native stuff like using the camera and things like that, then, you should probably go native right away.

But React Native offers a really good compromise and a way to build two apps with one code and it works for most of the apps. And the app I’m working for right now for Bungalow is a fairly simple REST-based clients and just a lot of API codes and lists and detail screens. It’s fairly simple so I think that was the perfect target for this kind of solution.

And React Native, compared to what you mentioned, Cordovan, PhoneGap, and Ionic ─ I think as an end user, you would probably feel that PhoneGap and Ionic apps are kind of different in that they’re not as responsive and it feels weird. It’s just like a perception. It’s really interesting because you use apps everyday and most of them are native.

And then, as soon as you don’t have the same effects and things like that, then it fails off and you can tell.

Now that you have React Native as a solution, I think that should be the one that you should use for cross platform because those are going to build NativeUI and a native look and feel.

The other question is if you already have an app as a business, if you want to use React Native. You already have a native app.

Did I want to use React Native for part of the app?

It’s kind of hard to have a mix of native and React Native in an app. And if you have developers who have the native experience, then you might as well just go for native.

As a freelancer, I’ve seen a lot of clients asking for React Native because they understand that it’s going to cut their cost probably not by two because it’s not as simple but maybe 1.5. You can build an app much faster, I think, for two platforms

Ledge: Tell me about Kotlin and Swift versus the older technologies. If you’re going the native route, there’s a lot of talk about Kotlin. What’s your experience as an engineer there? Obviously, Swift is gaining in popularity a lot. I don’t see anybody jump off right away with Objective-C anymore.

What are the differences? What should people attention to?

Simon: What’s going to be a simple answer is that both of them are amazing. Go for it. Don’t think about it. If it been there for a bit longer than Kotlin and it’s definitely everywhere now and everybody is using Swift.

Kotlin ─ personally, it took me a couple of years almost to kick my own butt and say, “Okay, now, let’s do it. I need to start using this thing.” After two days, I said, “Okay, why did I not use it before?”

The compatibility with the rest of pure code in Java is really good. Kotlin and Java is better than Swift Objective-C. I found that if you have a mix of Objective-C and Swift, it would be more clanky than Java and Kotlin.

Just for simple things like having these collection methods with Kotlin and Swift like that filter and all that, you can turn a full loop that was ten lines of code into one line of code combining those things.

You could use streams like Java ─ eight streams, something like that ─ but it’s not as great as Kotlin.

Yes, go for it.

Ledge: Great! Let me summarize. If you are a startup that wants to use a great deal of RESTful services that you’re listing and you’re drawing a lot on your backend and you don’t need a lot of the local camera or other native capabilities, your recommendation would, then, be at this point React Native?

Simon: Yes. There are other things to think about like what kind of developers you have in your staff. Are they familiar with JavaScript? Are they familiar with native?

I think if you have mostly JavaScript web devs, then it would make sense to try to use React Native with the caveat of ─ I just want to say that you will have to know native stuff. So as soon as you start to import some native plug-ins for React Native ─ for example, if you want to use the camera or even like the gallery photo picture image picker or something, you will have to use a native library and you will have to know about xCode and Androids and their corresponding package managers and everything.

I think it feels like it’s easier if you come from native and go to React Native because you only have to learn JavaScript and that ecosystem. But if you come from JS, it will be a challenge but it’s doable.

Ledge: Do you find that developers who are React web app first have some struggles moving to React Native on mobile? What would those be?

Simon: I think so and I think it’s harder that way than if you come from native because you’re familiar with Xcode; you’re familiar with how to release an app on the App Store.

We don’t think about it but it’s probably a good percentage of your development cycle and it’s a pain especially Apple. Apple’s release process is insane with all these provisioning and certificate and all that stuff.

If you come from JS, it’s like “Oh, yes, just deploy your docker and it’s done and there’s no upgrade and review.” So I feel like it’s easier if you come from native but you have to start learning something at some point so it’s not impossible, for sure.

Ledge: And how much code can you reuse between a React web app and a React native app? We that asked that question a lot.

Simon: That’s a good question. I think there are some people trying to answer that question. I think, for now, it’s very hard to share codes between web and mobile. But I think there are people trying to have some wrappers around the UI because it’s the same principle.

In the end, the least of the tree, the low-level components are different on mobile and web. So those are different. And if you manage to build some sort of wrap around it, you could potentially share the UI code between web and mobile.

Ledge: What’s your feeling about progressive web apps?

Simon: Good question! I’ve been specializing myself in mobile for seven years now and I feel like for the sake of my employment and job, I feel like I need to push for native or React Native solutions.

I think there’s a need for that, too. They feel good, too. So I think there’s room for everything. I don’t know much about it.

Ledge: What are the things that you think are next and what’s missing in native and sort of hybrid native or cross platform? What are the things that, as a developer, you hope that Apple and Google and the other ecosystems and communities will start to build and support? What’s next?

Simon: Some people would say it’s already now happening like Flutter. It’s the same paradigm. It’s a cross platform. You write it once, but built two platforms.

I feel like there are still some issues like the language is really hard. It doesn’t sound really appealing to me. And the community is probably not as big as React Native.

So I think, for now, I feel like the future is React Native. I don’t see anything coming that will replace that ─ just for the community that’s behind it and how fast you can build with all those libraries.

I wish there was a Kotlin-based cross platform solution. There might be, at some point. I think Jake Wharton is working on something now. The idea is to build something to be able to write Kotlin for desktop, Android, IoS, for everything.

Maybe that’s the future and we hope that’s going to happen at some point because Kotlin is way better than JS or Typescript or all the stuff.

Ledge: Cool! Thanks so much for your insights, Simon. I really appreciate it. Good to have you!

Simon: Thanks for having me.