5 Points to Consider Before Making a Hybrid Mobile App

The hybrid mobile app has become a major factor in mobile app development. By enabling developers to use web technologies (HTML, CSS, and Javascript) to target multiple mobile platforms from a single code base, rather than writing native code (Objective-C, Swift, Java, C#) for each platform separately, hybrid mobile apps can significantly reduce the time and cost of mobile app development.

Many companies jump at the opportunity to save both time and money, but in some cases, electing for a hybrid app can be a crucial mistake. This article discusses several points to consider before pursuing a hybrid mobile app approach.

1. Understand what features require native code

It is extremely important to differentiate between something that can only be done natively and what can be done entirely within hybrid code. A general rule to follow is: If it is something you have seen a website do, it can be done entirely within hybrid code. If it is not, it likely requires native code.

To help give you an idea, here is a quick checklist of native and non-native features:

• Accessing a customer’s location: Non-native
• Accessing a customer’s camera or photos: Native
• Passing control to a customer’s Facebook app for easy authentication: Native
• Simple animations and page styling: Non-native

All hybrid apps have some sort of wrapper that makes the app installable, but it is provided by the chosen hybrid framework (Cordova, Phonegap, etc.). In addition to this wrapper, hybrid apps often utilize packages or libraries that allow developers to complete native functionality in a hybrid mobile app. However, these packages and libraries have to be written with native code. This means that if your app requires some native behavior, you will either have to find a functional library or perhaps write your own.

The main downside here is that these native libraries have to be written for each targeted framework, and take time to write. If you want to support native functionality right after an operating system release (such as Apple Health Kit in iOS 8.0), you will be able to hit the market much sooner by going native. Additionally, the reliance on these libraries means you are trusting that the open source community will maintain and document them.

Having an app that requires native functionality is not a death knell for a hybrid approach, but it does require careful consideration and possibly some compromises.

2. Consider current and future app functionality

If you read the above section, consulted your version one requirements document, and found no native features, please don’t stop there! You also need to consider the future and potential scope of your app. There is an app graveyard full of abandoned hybrid apps that worked as minimum viable products (MVPs), but failed as more robust applications.

Many managers and product leads have been given the grave news that their hybrid mobile app, which dutifully got them to market, will have to be put down and replaced with a native app. Many companies cannot tolerate the cost needed to entirely rebuild their app natively. Worse yet, some companies will cling to their restrictive hybrid app, rather than rebuilding natively, just to see their competitors pass them by with a superior mobile offering.

3. Know current performance limitations of a hybrid mobile app

Hybrid apps have several key limitations that leave native as the sole option in many cases. These limitations include the following:

• Animations: Almost without exception, hybrid apps handle animations with less fluidity than native apps. This is something that can be designed around, but often results in developers telling designers “no” to their more involved animations.
• App fluidity: This is very similar to the above item, but is a bit more general. Hybrid apps often appear sluggish during page and state transitions. For example, the very popular slide tray open animation looks and feels significantly worse in hybrid apps.
• Memory usage: Since mobile apps run on a small physical device, memory usage is a very real concern. Hybrid apps utilize a device’s webview, which by itself takes up a substantial amount of memory. If your app is also going to require a moderate amount of memory, you might be unable to utilize the hybrid app approach.

Each of the above items can be designed around, but in many cases doing so can restrict an app’s potential. Telling a product manager “no” because the app is already using too much memory or responding “nope” to a designer because their awesome animation will not be smooth does not kill a project, but it can harm it.

4. Lack of native user-interface and user-experience (UI/UX)

Android and iOS apps have distinct design languages and offer their own user experiences. App developers are encouraged to make their users feel at home within their apps. However, hybrid apps target multiple platforms and therefore often feel generic or resemble a competing operating system’s apps.

A good example of this is the tabular approach iOS and Android take. Android utilizes ViewPagers whereas iOS uses Segmented Controls.

These look and function differently, but achieve the same purpose. The main difference is that the iOS control shows all options and must be clicked on to change tabs. The Android one can hide items if the list of options is larger and the app can be swiped right or left to initiate a tab transition.

Another major difference is that Android phones have a physical back button, whereas iOS apps often have a back arrow in the top left corner or implement the swipe left to go back behavior.

These are the types of things that are often lost in hybrid apps. Of course your hybrid app can still function in this manner, but often users will take longer to grow accustomed to your app’s behavior and might grow frustrated if it feels too non-native.

5. The possibility of choosing the wrong hybrid framework

Native apps have a very well-established and (mostly) well-documented technology stack. Android apps are almost always written using Java and are built in a very similar way. iOS apps can be written in either Objective-C or Swift, but there is a large community of developers and large knowledge base surrounding both. Alternatively, hybrid apps are built with the help of numerous app frameworks. These are usually similar, but it would be non-trivial to take a hybrid app built with one framework and rebuild it with another. For that reason, you want to be sure you make an informed decision when choosing your project’s framework.

Making this decision increasingly more difficult is the large number of hybrid app frameworks in existence. It is highly unlikely that all of these frameworks will still be maintained in the coming years. Many will likely lose market-share and thus become increasingly costly to maintain. So, just by the act of choosing a framework, you are betting on its future success.

Conclusion

Going hybrid can be a great approach to mobile app development, but can also end up costing you more than you initially saved. Before deciding to go hybrid, you need to fully understand the associated limitations and risks. It is exciting to have this new and more cost-effect method for app development, but as with all things, there is more to consider than just the price tag.

Source

5 Points to Consider Before Making a Hybrid Mobile App