Hybrid Apps - The Best of Web and Native Code

There is still a very high demand in app stores. There are various reasons for this, making it an excellent opportunity for many companies to sell products via this platform. Users now have a pronounced sensitivity for details and quality. The demands for intuitive user interfaces and reliable software are constantly increasing. If the apps are developed with the native language of the system (Objective-C/iOS or Java/Android), the UI can be used directly with proven operating concepts. This is all about user feel and it is recommended not to emulate UI elements with web technologies. A large proportion of users also prefer the software to have features that cannot be implemented comparably or at all with web pages. Furthermore, native apps have a much higher performance.

For us, the advantages of both technologies are relevant, which excludes some disadvantages by itself. Thus, we decided to develop a hybrid app. We are aware that there are frameworks for this. While PhoneGap serves as a simple wrapper and supports addressing a few hardware functions such as contact book, compass or the chamber, Titanium provides a wide range of native functions that can directly address the API of the iOS environment via JavaScript and do not use HTML at all.

The manufacturers advertise that you can develop apps with the same codebase for multiple systems. It works for trivial apps, but as soon as they become more complex and difficult to reproduce bugs occur, it becomes increasingly complicated and time-consuming again. Often, a feature works exclusively in iOS, while it breaks again in the other environment. The time advantage in development is thus put into perspective again. Furthermore, it has been shown that a specialist is needed for the build process, who is familiar with the corresponding system. There are also dependencies on the manufacturer of the framework. As soon as Apple or Google change the APIs, the corresponding framework has to follow suit. It can be very nerve-wracking if the app is faulty at the customer's site and the update has to be waited for in order to get the update through the Apple review. During this time, days and weeks can go by, which is not sustainable for professional apps.

With this, we had decided to develop a multi-device platform (MDP) based on Java, which sends the web content to the mobile devices or to the iPad app. The MDP also sends various configuration files in JSON format, which are processed by the app's native code. In the configuration files, among many other setting parameters, we also have so-called feature toggles, with which we can turn any feature on and off at any time. We also work particularly intensively with deck configurations, with which all the information is in a JSON file, which is then parsed by the app into complete decks (storefronts for swiping). Each article page is in turn a web view, where the HTML is rendered by the MDP.

Most of the UI is implemented natively because we couldn't achieve comparable quality with HTML/JS. It was also a good decision for the new feature "Favorites" (also known as Favorites), because it feels pleasantly snappy, the animations run cleanly and are easy to implement. It can be extended at will and without complications, which could become more challenging with some ideas, such as arranging the elements, with JavaScript, without a comparable feel.

The hybrid communication of the app with the MDP server requires a solid underpinning. In the iPad app, we send various events via NotificationCenter, which is used as the basis for a publisher/subscriber pattern. This allows the web views to communicate with each other and mutually send data to native code. Once a data exchange with the MDP takes place, all data needs to be validated and other security aspects need to be considered.

With this technology stack, we have combined the best of both worlds. We have more control and flexibility over our apps with fewer dependencies.