Mobile application development has been a big deal for several years now. When we talk about it, we are not talking about anything new.

Technologies, tools, frameworks, services and pretty much everything related to this subject are getting better and better every day. It is a great time to be a mobile developer because the most popular frameworks for mobile are so advanced.

But even with the overwhelming amount of documentation, examples, and guides, I frequently hear questions and/or comments regarding mobile development from both experienced developers (with no experience in mobile) and junior developers. There are still some misconceptions about the common terms and tools, and where to begin.

With that being said, here is a summary of what I’ll be covering in this post:

What Are We Discussing?

We are going to be doing a short review of each of the most popular and promising technologies used today in order to build mobile apps. These are:

• Ionic
• React Native
• NativeScript
• Xamarin
• Pure native development

I’ll summarize how each of these work, what the pros and cons of each are, and why each one could work for you given your previous experience and requirements.

The Goal

First off, my intention is not to declare a winner amongst these technologies. My goal is to help you know how each works and what you need to begin using each. Ideally, I want to encourage you to give each a try and then you can build your own opinion.

 

Ionic

I’m starting with Ionic because if you have done web development (HTML, CSS and JavaScript) this will be the most organic option for you. This is because Ionic relies on these tools directly.

Ionic is built on top of Angular; the great JavaScript framework built by Google. Angular 2 uses TypeScript and Ionic 2 does the same. These two things (and Apache Cordova, which we are going to be talking about below) are probably the most important things you need to learn to start building apps with Ionic.

Ionic is an hybrid-development framework, which means you are not going to be developing fully native apps. You are going to be creating hybrid applications.

The main thing you need to know about hybrid apps is their UI (the part the user interacts with) runs into a WebView – a kind of browser which runs in fullscreen mode. There is more behind what a WebView is, but that’s beyond the scope of this post. What I want to point out is Ionic apps run in a single threaded WebView. Then Cordova creates a bridge, which lets you consume native API’s and interact with the hardware of the device to do things like use the camera to take photos, make your device vibrate, deal with push notifications and so on.

The good thing about Ionic is it implements the core principle of HTML5 framework which is: write once, run everywhere. This means with the same code base you can run your app on all platforms supported by Apache Cordova.

The bad thing is hybrid apps don’t provide the same user experience because they use a single thread and user interactions have to pass different  extra layers to get to the hardware and native API’s. Most hybrid apps have problems like scrolling on large lists of data or supporting complex animations, especially on old devices using old WebViews.

The Good:

• Learning curve: Fast if you already know basic web development.
• Code reusability: Almost all of your code will work for both platforms (iOS and Android).
• Documentation and community: Official documentation is really good and the community is very big. You can find examples and help very easily on the web.
• Native plugins availability: Apache Cordova is one of the oldest players in the hybrid-platform market so there is already plugins for pretty much everything you need to do on the native side. It’s actually really easy to build your own plugins, but you will need to know some Objective-C/Swift and Java.

The Not So Good:

• Performance: Hybrid apps generally don’t provide a real native experience. Complex animations and big amounts of content could be a deal breaker.

React Native

React Native is the new bad boy in town. It’s built by the giant Facebook. It was announced two years ago and since then the excitement has grown like crazy.

Unlike Ionic and other hybrid-platform options, with React Native you can create truly native apps. It’s a JavaScript based framework, which uses native UI components in combination with their Virtual DOM concept and an extremely efficient algorithm called diff, which lets them refresh the UI with the least amount of steps possible.

Another difference between React Native and Ionic is there is no guarantee you will be able to reuse your whole code to make your app run in all supported platforms (iOS and Android). Sometimes you will need to write specific platform code. But, don’t worry, React Native has great support to do these kinds of things (as I explained here before). There is also a chance that you will need to write native code to support your own functionalities at native level and speed up your app. Unlike Ionic and all the hybrid options, the React philosophy is: learn once, write anywhere.

If you check on the internet you will see a lot of people saying React Native’s learning curve is easy, but I have to disagree a little bit. This is because people with little mobile development experience won’t understand some of the basics.

If you don’t have any experience with React (and keep in mind that React covers only the presentation layer) you are going to need to learn how to handle the state of the app, how to notify and propagate events, how to navigate between views and so on. That is when something like Redux joins the party. There are other options for Redux, but that’s the most popular option.

Finally, in case you don’t already know, you are going to need to learn ES6; not because you have to use it to write apps using React Native, but because almost all of the documentation and examples out there are written using ES6.

NOTE: Don’t be afraid to learn all the things mentioned above. It’s actually exciting to challenge yourself!

The Good:

• Performance: The combination of native UI components and the diff algorithm make the performance extremely good.
• Support and continuity: Facebook is behind it and pushing it really hard. Therefore, React and React Native are not going anywhere for now.
• Package size and startup time: Package size and startup time on a normal app are not a big deal. Check out the next section about NativeScript to see why we are mentioning this now.

The Not So Good:

• Maturity: Facebook only supported iOS at first. Later they started to support Android. When I was writing this post, I could find some components and functionalities supported for iOS, but not for Android.
• Documentation: Official documentation could be better.

NativeScript

NativeScript is also a cross-platform framework built by Telerik. With NativeScript you can create truly native apps. From the development experience perspective, it has several similarities with React Native. To define your UI you will be using XML files, where you will define NativeScript components that wrap native components. It also uses a very similar approach to React Native to apply platform-specific customizations.

On the other hand, it also shares something really important with Ionic – it supports TypeScript and Angular. This is optional because you can write your app using plain JavaScript, but if I were you, I would take advantage of the power of these two great tools. I guess you could say developing an app using NativeScript feels like Ionic, but the app itself feels like React Native, or better, just native.

Using NativeScript your JavaScript code runs into JavaScript engines (virtual machines), JavaScriptCore for iOS and V8 for Android. This strategy comes with a price on startup time and package size. Most complaints about NativeScript are about startup time, but their development team is doing a great effort to improve this. One of the nice things about NativeScript is they release new versions very often and the evolution of the framework is pretty fluid.

There are also plugins for most of the things you need to do at native level.

The Good:

• Documentation: Official documentation is really good and they also have some great tutorials to start using the framework.
• Performance: Due to the usage of native components and native UI, performance is really good.
• Support and continuity: A big and strong company backs it.
• Learning curve: Just like Ionic, the learning curve is fast if you already know basic web development.

The Not So Good:

• Package size and startup time: Package size and startup time are not that good because of the embed and usage of JavaScript engines to run JavaScript logic.
• Debugging: At the moment of writing this post, the debugging experience was not that impressive – but that’s something that the development team is working on.

Xamarin

Xamarin is a cross-platform development framework supported by Microsoft. It lets you create mobile applications using C# and F# and define your UI using XAML. Xamarin is the ideal option if you already are an experienced  .NET developer and you want to see results in the short term.

As you can imagine, because Microsoft backs Xamarin, besides iOS and Android, it also supports Universal Windows Platform (UWP).

The same way as React Native and NativeScript, in Xamarin you use common UI components, which wraps native components for each platform. The code itself gets compiled into binaries that will run natively on each platform. On Android it uses Just In Time (JIT) compilation. On iOS it uses Ahead Of Time (AOT) compilation.

One nice thing about Xamarin is it offers different ways or tools to build apps:

• Xamarin.Forms: Cross-platform development is recommended even if you are planning to support only one platform at the beginning of your project. Later it will be easier if you want to add more platforms.
• Xamarin.iOS: iOS development.
• Xamarin.Android: Android development.

The Good:

• Learning curve: If you already have experience with C# you won’t have problems. Even better if you also know XAML. For those who don’t have experience in these technologies, this could be opposite.
• Performance: Your code, besides being converted to specific platform binaries, gets optimized during this process so the final code is extremely efficient.
• Support and continuity: Once again, a big company is behind Xamarin.
• Documentation: Documentation, examples, and templates for new projects are really good.
• Maturity: It is the most mature of the cross-platform development options discussed here.

The Not So Good:

• Package size: Package size is quite a bit bigger than pure native apps because Xamarin uses some runtime libraries of its own.
• Reuse of knowledge: This is debatable, but some people would consider this as a con. Unlike other options discussed here, Xamarin doesn’t make use of industry standards like HTML and JavaScript. Some people consider this bad . Right now the whole industry is trying to get a universal language which lets us build apps to run on any device: phones, wearables, cars – you name it- and Javascript seems to be one of the strongest options.

Pure Native Development

Pure native development is the best way to get better user experience because you use the whole potential of the operating system and the device.

On the other hand, if you want to create an application to run on both iOS and Android it means it’s going to cost you double: you have to learn both official languages (Objective-C/Swift and Java/Kotlin), double tests, double maintenance, two repositories and so on.

Pure native development is good if you really want to make a career path as a native developer for one specific platform, but if that’s not the case, all the mentioned options here are good enough to replace this option and make you a more versatile developer.

Final Thoughts

We are definitely living in a great time to be a mobile developer. Available technologies are becoming good enough to compete and replace pure native development. The one thing that’s for sure is that the technology will get better and new technologies will come. My advice for you, before you pick one, is to research all your options, give each a try, and write a small “hello world” to see how comfortable you feel with them.

Once you have done that, try to review this list of topics/ideas before you make your final decision. This is my list, but you should make your own or modify this one, but remember these important points:

• Check who is behind the technology you are about to pick: It’s important to know who is behind it, how secure you feel about it, and what the future may be for the company/group regarding this technology.
• Check the community:  Community is easily 50% of the deal (or more). From the community you will get help, libraries, examples, guides, and so on. Check what channels they use to communicate. This is key.
• Check your requirements: hardware and software. For most of the options, if you want to compile for iOS, you will need a Mac computer. If you don’t have a Mac, check for online services to build your app remotely, like PhoneGap or AppBuilder.
• Make a list of your functional requirements: Check if you need things like maps, push notifications, storage on the device, etc. Once you have that list, check if the given technology has support for each item, or if there are good third party libraries available.
• Check rich components available: It’s well known that developers are not graphic designers. We are not good at making apps look nice, we are good at making them work. With that said, if you don’t have a graphic designer on your team it’s better to have an idea about how to make your app look good using the framework right out of the box.
• Payments: If you are going to do this on your own and you are actually thinking of submitting apps to stores, you will need to pay developer licenses at the very least. It’s not that expensive, but it’s important to be aware of. There is also a big chance that you want to use third-party services to support different functionalities, like push notifications, CDN’s or just host a Web API you are also building to use on your app.
• List: List what platforms you want to support and the minimum version of each of them you are willing to handle.
• And finally: Start to code and have fun!

—