Introduction
When you want to launch a new app, you’ll first think about the requirements you have for your app. But it doesn’t matter which specific functional requirements your app has, it should always have a nice design, have a proper User Experience, perform fast and off course be available for both Android and iOS.
And that’s where a lot of initial ideas come to a halt. I either have a ready design for iOS or Android, or a budget for just one app. But it’s not just one app you need to create. You need two to serve your future customers.
So you need knowledge about both the iOS and Android ecosystem, built 2 apps and maintain them. That sounds like a lot of duplication. In this post we want to explain our view on reducing this duplication.
Three different types of mobile apps
Native applications
Native applications are written in the language officially supported by the platform. For iOS this is either Swift or Objective-C and for Android the Java programming language. The pros of using this types are clear: the user experience will be the best, you’re able to get the latest functionality that iOS or Android has to offer and the code is optimised for the device it’s going to run on.
The cons for using native applications by launching on multiple platforms are clear as well. First of all it’s an expensive way of developing app: you have to write specific code for both Android and iOS. This means that your development team should have knowledge about both the iOS and Android ecosystem. Another downside of using the native solution is the maintainability. For example, when you want to add a new field to a certain screen, it’s required to change the code of multiple applications. So the maintainability is expensive
HTML webview applications
Luckily it’s possible to develop applications for both platforms, namely “HTML webview applications”, frequently referred to as Phonegap, Cordova or Ionic solutions.
In this case the application is build in a container which is in fact a just a web browser. Using this approach developers are able to write the business logic using just web technologies. On top of that within that webview there’s a bridge available so it’s possible to open the Camera, get the GPS location or read the Contacts from the device. A benefit for this type of application is the low level to start with it. Because the application is written down within HTML, CSS and Javascript. This makes it easy to start developing the applications. The downside is the User Experience, it will perform like a normal website and it doesn’t have the native User Experience by default. A lot of people are able to tell that your app is ‘different‘ and ‘slower‘ than the standard functional behaviour of the OS.
In conclusion, this type will have a shared codebase, some access to low level phone API’s, but the UX and speed disadvantages are too big for us.
Near Native
Is there an alternative which makes it possible to develop cross platform mobile apps? That’s the main question. We want to have the benefits of a shared codebase of the HTML webview solution, but the rendering and speed of the native components within native applications.
For this problem we as Enrise are using near native solutions, also referred to as Hybrid solutions. With near native you’re able to write an app in 100% pure Javascript but have the full native experience. There are several frameworks available which built upon this approach, most popular are Titanium, Nativescript and React Native. All 3 three of those are built around a bridge that enables developers to write pure Javascript. This bridge makes sure that the Javascript code will generate a native component. In the end a native view/component will be rendered so the application is indistinguishable from an app built using Swift/Objective-C or Java.
The bridge
Both iOS and Android use different approaches to support Javascript. iOS uses the JavaScriptCore engine whereas, the current standard on Android is the V8 engine. For both counts that they are also the driving powers behind Safari and Chrome. But the V8 engine is i.e. also used in the Node.js environment.
Using Javascript instead of the native supported language comes with a performance penalty. Every data structure and command you send over the bridge needs to be translated, as well as the response you get sometimes. For example React Native, provides specific API’s to call a view and to style it. The user clicks on a button, and the bridge is checking the code described within Javascript and executes that code again. Obviously this would be faster if you’re not using this bridge.
Someone with an experienced eye can see this visual performance penalty, but over the past 4 years the JS engines have become faster and faster. According to AreWeFastYet performance has at least doubled and in some cases even tripled.
Next to this performance gains from the past few years, another benefit is the fact that you can use every low level phone API. If there is no support yet, you can just add the functionality to the bridge yourselves to expose the low level API’s you need.
In our case this means that we currently build our complete business logic in Javascript, with the addition of additional bridge modules and have 25% of our code specific for the iOS or Android ecosystem.
Conclusion
It’s possible to reduce the build and maintenance costs of a mobile application, despite this it needs to support multiple platforms. Using near native solutions the end-user will hardly notice that application is written within Javascript and developers are able to deliver quality without knowing all the tidbits of both iOS and Android.
