Mobile development teams today most commonly use a silo approach to building mobile applications. Each mobile platform application is written in a separate programming language, using the platforms native tools. The three major platforms are iOS/Objective-C/XCODE, Android/Java/Android Studio, and Windows/C#/Visual Studio.
This has meant maintaining three code bases for the same platform, which is time intensive and costly. So the industry has looked into ways to solve this. In a previous post, I looked at how code reuse could be done at a programming language level. In this post I will discuss probably the four most talked about or researched approaches to achieve Hybrid Mobile Development. This doesn’t cover every approach available; We have a very talented industry which has found endless ways to solve the same problem.
Below is a list of the frameworks that we will cover and the different philosophy’s that drive how to produce Hybrid Applications.
Will look at these four hybrid frameworks
- Ionic 2 (Developed by Drifty Co.)
- Write once, deploy everywhere.
- React Native (Developed by Facebook Team)
- Learn once, write anywhere.
- NativeScript (Developed by Telerik Team)
- One Code base, native deploy everywhere.
- Xamarin (
DevelopedOwned by Microsoft)
- Cross platform mobile apps using C#
What the web says
A indicator of a technology relevance is the people who search for it. So I looked at Google trends and Github Pulse.
Google Trends - Last 12 Months - World Wide Interest In Order of Rank
- Ionic (More Interest in USA)
- Xarmin (World Wide Interest)
- React Native (More interest in China)
- NativeScript (More interest in the USA)
Github - April 2017 Pulse - In order of rank of # of Authors
- React Native
418 commits 119 authors 2982 watch 47,839 stars
Andriod : 60 commits 9 authors
iOS : 169 commits 26 authors
169 commits 26 authors 1733 watch 29,330 stars
75 commits 15 authors 602 watch 10,088 stars
For someone coming from the web, you can in theory write most of your mobile application using HTML5/CSS/JS. Some drawbacks is the interface isn’t native looking unless you mimic it with HTML. Another drawback is this probably isn’t the right choice for optimal performance. Don’t choose this if you know your going to build graphically intense apps.
For someone coming from React.js, you can easily ease into the framework and get all the benefits of native speed. However, it means learning React Native syntax and way of developing. Its an investment that assumes React Native can be relied on to do the rest with minimal effort from you. Facebook actively uses this, so its a testament that it works. Recall that Facebook tried to build a mobile application with HTML years back, but decided to go back to native because of performance. They have found a new way to accomplish cross platform and it seems to be working well for them.
Developers write their mobile applications in C# using Xamarin toolset. Xamarin allows you to write C# code which is converted into native Android code, iOS code and Windows code by default. What makes this approach unique, is they provide Forms that wrap Android UI and iOS UI and wrap all native API access. So even the UI is written C#. There is still separation of concerns where backend code is shared, but UI code are individual projects for each platform. This is because of each platform UI differences. You will still need a MAC to build iOS apps.
This is the only option I’ve added which requires a fee to be paid on your build. I love C#, and to be able to program in that language would be great. This approach is good for enterprises that want the weight of a big player behind them, and also need rapid development across platforms. If I were to go with this approach, I would seriously look at what other paid options I have.
I’ve shared some approaches to Hybrid Mobile development. So what should I use? React Native is very active on Github, and Facebook has invested greatly in it. The investment to learn there way may be a good choice. A simple fact is that native development provides the most flexibility to take advantage of native features. At the end of the day, make the best decision based on you and your teams skillset. I don’t think any one way is wrong. The next step for me is to try a approach, and decide to continue based on challenges faced.