Common Motivations for Using a Hybrid App Framework
Generally speaking, clients should reflect on their motivation for using Hybrid frameworks instead of native development. Below, I’ve outlined some typical motivations I’ve seen with potential clients and cleared up some common misconceptions. All of these sentiments are very valid and should be explored before making a final decision.
It’s Inexpensive.
There’s one huge misconception on the time and cost of building a mobile application:
- First, building a native app on both platforms is 2x as expensive as one using a hybrid app framework. This simply isn’t true. Often native costs can be mitigated by building one platform, working out all of the API and implementation kinks, and then developing the second platform even quicker.
For larger and more complex applications, there are diminishing returns on using a Hybrid platform because integrating with Native components often must be done per platform. Native integrations also sometimes just don’t work the way we’d expect on Hybrid platforms, and time and energy for debugging each platform is required. Sometimes Hybrid apps can take just as long, or even longer as developing a native app once you factor in these variables.
The Hybrid App Framework Shares a Common Technical Stack to the One we Use in House
- This is a great consideration for a lot of clients that have in house development teams. In the case of a future hand-off, it’d help the transition immensely.
- A few things will still have to occur in hand-off:
- Mobile concepts and design guidelines are quite different from desktop and web development. These will need to be taught and learned.
- The mobile framework itself will need to be understood in order to maintain and build new features. This includes the built-in framework tools and architectures.
Developers Can Share More Code
- Code reuse is a concept that permeates throughout every efficient software design architecture. Hybrid and Native both have strategies for code sharing between platforms.
- Community involvement increases code sharing immensely. If you have a very active community, a lot of functionality can come for free.
Consider the following pros and cons for a couple of the more popular Hybrid app frameworks as well as a native analysis in order to make a more informed decision.
Cordova with Ionic
Pros:
Community Involvement
Cordova has a huge community following, and native plugins for almost any common functionality exist. This makes integrating native functionality easy. Out of all the Hybrid platforms, Cordova is definitely the largest in terms of projects using it.
Common Frontend Frameworks
Ionic runs in the AngularJS framework, which is popular among front-end web developers. This makes it easy to get up to speed on testing, syntax, and common Angular architectures.
Ionic Tooling
Ionic offers an array of drop-in UI elements and a great CLI (Command Line Interface) for quickly building and deploying to mobile devices.
Cons:
Performance Issues
Technically, a Cordova application is just a Javascript application running in a web view that uses ‘hooks’ to interact with native components. While the web view architecture is getting better and devices are getting faster and faster, performance within a web view is not as snappy or as polished as other native views on iOS or Android.
Plugin Dependency Conflicts
Since plugins interact with native components, there’s often dependencies with native libraries. A good example is Google Play Services. Google Play Services is an Android library that contains push notification functionality as well as Google Analytics functionality. There are two Cordova plugins (one for push and one for Google Analytics). Since both rely on Google Play Services, you have to make sure the two plugins both depend on the same version of Google Play Services, or you will get conflicts at build-time or exceptions at run time. While this could possibly not effect your project, it’s something to keep in mind if you plan on using lots of native integrations.
Things Don’t Always Work the Same on Each Platform
Specifically, we’ve noticed that animations are slower on iOS than in Android, and things are often choppy when showing and hiding elements (ng-show/ng-hide). We had to implement CSS workarounds to fix this.
This will happen frequently and be time consuming, so expect it! However, since the community is so large, others have probably encountered it, and workarounds most likely exist.
Xamarin
Pros:
Performance
Xamarin is one of the faster Hybrid frameworks because it doesn’t run in a web view, and all of the C# is compiled to machine code and packaged in the app.
Shared Code
Common functionality, models, and services can be shared between all of the native projects. This promotes loosely coupled software design. There are also PCLs (Portable Class Libraries) that offer similar functionality to native platforms like SQLite database implementation and JSON parsing. PCLs are mostly supported by Xamarin, not the community.
Great for Supported Controls
With Xamarin.Forms, you can truly share tons of code, but you are very limited. There are only around 40 controls that are implemented, and each control is limited to very basic and native functionality. If you are working with a very simple application, this may work great!
Cons:
Community Involvement
The community surrounding Xamarin is very small. It reminds me a lot of Adobe Flex Mobile’s community. When working on Xamarin projects in the past, I’d make pretty frequent forum posts trying to solve issues, and often the only people answering questions were Xamarin employees. This can sometimes create blockers during development cycles.
Libraries outside PCLs are almost non-existent. For example, I was looking for a simple Video Player UI Library that had seek, pause, and play functionality when building a Xamarin application. This is pretty common and easy to do natively, and there are libraries for almost any type of video (Youtube, Vimeo, or local). There was nothing of the sort on the Xamarin side, and I ended up creating layouts and functionality from scratch for every platform, taking even more time than a native implementation.
Limited Functionality
While Xamarin.Forms offers a lot of code reuse, each control is very limited in its functionality. If you want to customize a control or give it custom interactions, it may not be supported in Xamarin.Forms at all, and you’ll have to implement differently.
If you don’t use Xamarin.Forms, you will have to build a “shared” project with common code reuse, and then create a separate project for each platform (Xamarin.Android, Xamarin.iOS, Xamarin.WindowsPhone). This can severely decrease the ROI of using a Hybrid platform.
Custom is Expensive
Xamarin often takes the same amount of time as a normal native application to build for custom applications, or even longer. If you aren’t using Xamarin.Forms, all UI design and implementation is done per platform. The only shared code you get at that point is common functionality between applications, and honestly, this can be done on the Native side as well.
Native
Pros:
Performance
There’s a noticeable difference between running a truly native application vs. a Hybrid app.
Community Involvement
Native mobile development is much more popular than Hybrid frameworks. People are building new libraries for common functionalities daily, including the Metova development team. This increases native development velocity greatly.
Latest Functionality, First
Newer features are often not supported on Hybrid frameworks until the company (Xamarin or Cordova) releases support for the newest operating systems. With Native, we have that functionality immediately, and we often get to experiment with it in Alpha or Beta stages.
Cons:
Less Shared Code
It’s a common misconception that you can’t share code between native applications. C and C++ both compile on Android, iOS, and Windows phone, and shared libraries can be created and utilized to reuse low-level code functionality. This is increasingly popular among interaction with embedded systems and AV tools.
Strategic use of web views and mobile designed web pages can cut down on mobile development for displaying simple but dynamic things like T&C’s and Privacy Policies.
Even with these avenues, a decent bit of things are still done multiple times.
Knowledge of Multiple Languages Needed
While a lot of mobile concepts are shared between iOS, Android, and Windows Phone, learning a code’s language and syntax and the platform nuances are required.
