Ionic vs. React vs. Native apps.

There is a spectrum on how users engage on mobile, from a mobile responsive website to native apps that run on your phone. For most cases native apps are the better choice, and by this I mean an app that you get from the app store (with a .ipa extension for iOS and a .apk for Android). But there are a number of ways to build a .ipa or an .apk file. The most common methods are to build a ‘traditional’ native app using Apple/Google’s language and build tools, ‘wrap’ a website as an app using a hybrid framework or to use a framework somewhere in between, like React Native.

One of the most common conversations that I have with someone wanting to build a new app is what framework they should build it in. Should they go with a Cordova wrapper like Ionic, Expo.io or Xamarin, a framework like React Native or just build native for iOS and Android. At Playlogix our preferred options are Ionic, React Native or “Full Native” as we typically try to run on a Java & Javascript stack to make hiring developers easier for our clients. There are a bunch of pros and cons to each option though and this is normally how my (non-technical) conversation goes:

TLDR; It depends on budget, team experience and business stage.

Ionic 2

This is a Cordova wrapper where you write Typescript (a flavour of JavaScript) in Angular 2+ and then ‘wrap’ it in the Cordova shell which is then deployed into the various different platform formats from iOS and Android to Blackberry.

Pros:

• It’s build once, deploy everywhere. So you only have 1 JavaScript codebase that is easy for pretty much any developer to work on.
• Using the Ionic Creator (their drag and drop interface builder) is super easy for the standard pages and their default styles and templates look great.
• Can be super fast to build a form-based or static page app. Changes only need to be made once and then deployed to multiple platforms.

Cons:

• It’s hard to not make the app slow and clunky. Although easy to build, it’s essentially a website running in a browser running in a Cordova shell. So, even simple stuff has a lot going on and it gets bugged down fast.
• It’s really bad at dealing with long lists - add some images and it becomes a nightmare. Most other “semi-complex” items can become much harder to do than they should be.
• Being a single code base, the apps have to look identical, so no optimizing for iOS and Material design between platforms.
• Not very backwards compatible. [Recommended min Android version is 4.4.4 but it can be stretched to 4.2]

We typically recommend it when… you are just wanting to get a very simple app out fast on a low budget to test core business assumptions. Have a small (or no) dev team to take it on afterwards and are not needing any on device hardware (like intensive CPU usage, camera for AR, accelerometer, etc.) as your primary functionality.

We built: Lets Talk Xhosa

React Native

Built and developed by Facebook, this uses a version of React.js that deploys directly to an app binary (the lowest level native app format). So while you write you’re code in React, it is deployed and runs like a native app (it generates a binary file on build) and not inside a browser as a wrapper does.

Pros:

• You can build all of your apps in the same language (React.js) which allows you to be able to reuse a number of components. This also means that a single developer can maintain all of your apps and often means that changes can be done quite easily as the codebases will be quite similar. All this saves time and money.
• It has near native performance and is generally pretty easy to write fast responsive apps.
• You have multiple codebases which allows you to modify the designs and styles for iOS and Material design patterns giving a more natural feel to users.

Cons:

• You still have multiple codebases. So if your designs are widely different then you’re going to have a lot less code reuse and will lose a lot of the benefits.
• Not that backwards compatible for older Android devices which can be a problem depending on your target market. (like 3rd world students) [Currently supports down to 4.1 (API 16)]

We typically recommend it when… you have a relatively complex app (beyond an MVP) but are still iterating on features and functionality quite a lot while only having a small team to maintain it. If you design for maximum code reuse then you can get up to a 90% code reusability when you port to the second platform (and save loads of time/money). Another big plus is if you are using React for your web app then you can reuse components and save even more time.

We built: Flow Living | Some1 Visitor

Native iOS and Android

We typically build in Swift for iOS and Java/XML for Android.

Pros:

• Best app performance.
• Great build tools and support libraries make it as fast or faster than building each app in React Native per platform.
• Great backwards compatibility and device support. (Note that Android is still a pain as it’s so fragmented — but it’s still easier.)
• In app payments and integration into the platform services are easier.

Cons:

• You have 2 completely different code bases in 2 completely different languages and keeping feature parity becomes hard.
• It’s a lot easier to make the apps styled differently as most native libraries leverage native templates and style guides — so you need to make sure your designers know the difference otherwise it requires a lot of customization.

We typically recommend it when… you have a big budget and great performance and user experience is most important. Also, if you have a big team to maintain the apps going forward or have already done a fair amount of iterating on previous designs and have a good idea of what the app is going to need to do.

We built: Shyft | EM Guidance

There is no one-size fits all and ultimately the decision is going to depend on your stage of business and what customer need you’re actually hoping the app will addresses. Budget, complexity and support are probably the biggest factors in making that decision. It’s not a matter of right or wrong, but more one of what’s the best fit for where you are.

Remember that often you don’t need an app for an early prototype (or to cover both platforms) unless people need it on the move and the easiest way to save money on tech development is to build less and focus more.

‍