Cross-platform technologies
By Henrik Kirk
I have spent the summer looking at some of the different cross-platform technologies currently available when developing mobile applications. So first of all, let us look at why you should consider choosing a cross-platform technology instead of developing a native mobile application and utilizing all the new features available in the native frameworks.
Advantages of cross-platform development time and cost are probably the two main drivers that push companies and developers to consider cross-platform development. With a cross-platform framework in place, the business, for the most part, only has one code base to develop and one place to fix bugs, which could reduce development time, and thereby cost, significantly. Notice that some of the frameworks I highlight below are quite new, and therefore you may be forced to develop a plugin or rely on plugins with a small user base for some features on the mobile device.
If you can save time by serving the same applications to multiple operating systems, you can afford to push the applications to more operating systems than you normally would. And it becomes almost “free” to create an iOS application from an existing code base, you could broaden your potential user base.
When developing an app natively you normally have two or more teams working on each platform, who – in some way or another – synchronize their efforts, but even with careful planning, it would normally result in updates coming to one platform before another. So when should you tell your users about this new feature – when it hits a platform or when all platforms are up-to-date? In both scenarios, you end up with users who are frustrated about the chosen strategy.
Disadvantages of cross-platform
The obvious disadvantages of developing with a cross-platform framework/technology would be performance and UX look and feel. Each technology has different solutions to these problems, as we shall see in the following. Also, the cross-platform frameworks may struggle to keep up with the newest features released in the latest versions of operating systems. Depending on your project, there can be plenty of good reasons to consider a cross-platform technology and I have tried to include the most popular frameworks below.
Apache Cordova
This project, formerly known as PhoneGab, has been around since 2009, where it was developed on an iPhoneDevCamp and since then purchased by Adobe in 2011.
In Apache Cordova/PhoneGab you build your app in JavaScript, HTML, and CSS. The Apache Cordova framework packages the source files into an apk/ipa. The final mobile application is structured so it loads a native WebView which again loads your HTML5 application.
You can choose to go with multiple HTML files and navigate these as you would in a browser. This strategy has some disadvantages, so most users of Cordova end up developing a Single Page Application.
To get started with Cordova you need to have the Cordova CLI environment installed, this can be installed via NPM, after that you can create a project with:
$ cordova create hello com.example.hello HelloWorld
With the Cordova CLI, you can define platforms, eg. Android or iOS, build and run your application and of course also emulate/test your application without a physical device. Click here for details.
When developing a mobile phone application, you normally want to utilize the sensors on the device. To use these on Cordova, you need to install a plugin in your application, eg.:
$ cordova plugin search camera
One reason for using Cordova is if you or your organization has a web team, in which case it could be a very productive way of starting on your mobile project. The discussion of whether HTML5 is good enough for an entire mobile application I will save for another forum.
Regarding the UI experience, then building all your application HTML and CSS, you are dependent on WebView on the native application. For iOS, this means that you will depend on the Safari browser, which – according to Cordova – is because of Apple’s upgrade strategy. Android has been more troublesome, since each manufacturer tweaked the platform on their devices, in the latest releases Android has moved the WebView out of the OS and into a stand-alone application, which is updated by Play Store. Also, performance has changed a lot over the last 5 years. See this blog post for details.
Xamarin
Xamarin has been since 2012 and was since acquired by Microsoft in 2016. Xamarin started as a plugin for MonoDevelop for Mac, and you could only develop iOS applications. But version 2.0 was already released in 2013 and included their own IDE, Xamarin Studio and the ability to build to iOS, Android and Windows Phone. Xamarin apps are built in C# and you write your native application in C# and reuse your business login across all targeted platforms. The UI is then designed for each platform and uses the native UI components. Eg. to build and Android App, you create an Android project in your Solution and create layout files etc. as you would in a native Android app. The same for iOS, where you create a storyboard file in XCode and attach the resources.
In version 3.0, Xamarin.Forms were introduced, allowing you to build UI in Xamarin via a subset of components, which are then mapped to native components on each platform. To get started, you need to have Visual Studio 2015 Professional or later and also Xamarin.Android and/or Xamarin.iOS. Open Visual Studio and create a new project with either or both Xamarin.iOS and Xamarin.Android solution and follow the step to complete the creation of the solution, after this you are ready to create your application. Click here for the complete guide to getting started with Zamarin.
The best performance test for native vs. Xamarin.ios/android vs. Xamarin.Forms I could find, can be found here. The conclusion in the post is that native is faster but Xamarin.iOS/Android is close behind.
React Native
React Native was introduced in 2015 by Facebook and is built on React, which is Facebook’s web framework. This differs from Cordova by not using HTML5 but only JavaScript.
The layout is done in JSX, which is a way of writing XML directly in JavaScript and the Javascript is part of the newer EC6 standard. Styling your app is done in specific style properties, and matches (in most cases) the CSS class names and layout is done with Flexbox, which works the same way in CSS as in React Native.
Since React Native builds on React, there is no way around knowing a bit of React, but if you haven’t used React for web programming, you can still start creating apps in React Native.
If you like programming with types, it is also possible to use a Typescript compiler to the build process and thereby getting some compile time safety. This process is a bit cumbersome, but there are guides from both Facebook and Microsoft. Here is one example.
Getting started with React Native also includes a bit of work. See Facebook’s guide for details.
Flutter
Flutter is developed by Google and differs from the other technologies by not using the native widgets including the WebView. Flutter is also the newest cross-platform technology I have investigated. It was released in May of 2017 in an early alpha version and is, as of July 2018, in version 0.6.0 and there are release candidates out of the version 1.0.0 release.
You develop your Flutter applications in Dart, which is a language also developed by Google. Dart is an object-oriented language with static types that can optionally be trans-compiled into Javascript. It is also used to build web and server applications.
Instead of using the native widgets, Flutter is built on top of the C++ engine on iOS and Android. The Skia graphics library is used to build widgets, which have the same look and feel as the native widgets, so if you use a Text or Button component you get the native look and feel on each platform. To use the native sensors, camera etc. you use or write a platform channel. A platform channel is Flutter’s way of communicating with a native part. In Android, it can in an Activity or Service and in iOS an AppDelegate.
Getting started with Flutter requires a Dart environment and a Flutter environment, but Flutter has a nifty tool called Flutter Doctor, which helps you set up your development environment and validates the readiness of this. The guide to getting started with Flutter can be found here.
Writing an actual Hello World app after installing the environment is very easy and can be achieved in under 20 lines of code.
The negative side of adopting Flutter in your project is that you may not have access to a lot of people who know about Dart and Flutter, and even if they know a bit of Android and/or iOS, it may be a rather steep learning curve to Dart and Flutter – especially since you can’t reuse a lot of the knowledge you have from native app development. You can, however, join in on the official Gitter channel, where Google engineers and other developers try to help each other in real-time.
According to some performance test, Flutter is just as good as eg. React Native, but still not as good as the native experience. Check this link for further details.
The other technologies
The list of other technologies is long and not to forget any of these, I will reference Mobile app development on Wikipedia.