Mobile apps - to be hybrid or not to be?

I am often asked by clients who are looking to develop a mobile app, and more specifically by their engineering leads: should we go with a hybrid app?

First of all, what is a hybrid mobile app? It is a mobile app that has been developed with one code base to work on the 2 key mobile platforms dominating the app space today: iOS and Android. At a very high level, going hybrid allows for one single development over both platforms, therefore saving both time and resources. Non hybrid however – or native development, as in developing apps that use the native code for each platform, Java on Android and Swift/C++ on iOS – allows for closer integration into the device OS and easier integration of native user experience frameworks (never under-estimate the impact of a good UX on ease of adoption!)

From a purely business perspective, the answer seems obvious: let’s develop a hybrid mobile app and avoid having to hire twice the number of developers and take twice the time! However, as usual the devil is in the details, and the correct answer is… you guessed it, ‘It Depends’.

It depends on your budget, of course, but it also very much depends on what app you are looking to build, and what its core features are.

• As a general rule, if one or more of your top 3 features require direct, frequent and/or intense interactions with the physical components of the mobile phone (GPS chipset, SIMcard, microphone, camera, graphics card), native iOS and Android language is expressly conceived for an optimal integration with these components. Pinging the GPS chipset and other location-based components such as the SIMcard for cellular location and the Wifi radio for Wifi location on a regular basis (for a Maps and Navigation app for example) will be greatly optimized through native rather than hybrid code
• If you are looking to generate an app that will put high pressure on the graphical components of the phone, and want to ensure milli-second level performance, native is also the way to go. Online-dating apps such as Tinder are a good example of this, where the user needs to be able to easily swipe through cards of profile content, including text, photos, videos and action buttons, all layered over each other. Native code will enable your developers to hone the screens so that together design, interactivity and performance remain optimal
• However, if you are looking to generate mainly a content and informational app, or e-commerce app with basic payment features, hybrid is a perfectly rational way to go, and will certainly enable you to launch quicker and at lower costs. Some key languages such as React will enable you to generate an app and website with very similar code bases to work across all devices
• As a disclaimer to the first two points above, it is possible to incorporate native components and functions into hybrid code bases, to achieve the performance requirements and interaction with the physical components of the device. This requires skilled and experienced developers however, who have a very good grasp of both a specific hybrid code language and iOS and Android native code. Those developers are as yet relatively hard to find, so not an easy solution for a hybrid deployment
• It’s important as well to take into account your overall ecosystem: if your mobile app incorporates SDK components (Software Development Kit: a packaged set of features and screens to be integrated in mobile apps) that you are also offering to your clients or to third-parties, the determination of whether your ecosystem uses hybrid or non hybrid apps will inform your decision for your own app and SDKs. In general it is always better to ‘eat your own dog food’, in other words, use the SDKs you offer to third parties in your own app as well!

An additional note – other than for very specific types of apps (such as ones targeting high-end customers, more likely to be on iOS phones), I would not recommend planning to deploy on only one of the platforms (iOS or Android). Today in the US, iOS represents roughly 44% of all mobile devices, and Android 54%. Overlooking either will take you out of a sizable part of your addressable market!