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 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
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.
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.
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.