App development. It's like, a big thing now right? Everyone has a smartphone, and practically everyone out there wants to make sure that there product or service is "mobile-enabled". However, if you want to reach the largest possible audience, you have to make sure that your app runs across all of the smartphones that said audience is going to use, right?
So that means making sure your app runs on iOS and Android, and probably Windows Phone as well. Blackberry? Possibly, but I think that depends on that market you are targeting, so for the purposes of this article, I am going to ignore it (and the plethora of other platforms that exist) and focus on the Big Three who, according to IDC, hold more than 98% of the market share as of the end of Q3 2014.
Targeting all three platforms with a native app means maintaining at least two different operating systems for development (OS X and Windows will have you covered) and writing your app in at least three different languages. That seems like a whole lot of work, right?
Enter the Hybrid App.
So whats a 'Hybrid' app?
Wikipedia tells us that a hybrid app is:
A hybrid mobile application (or hybrid mobile app) is a mobile application that runs inside of a native container and leverages the device’s web browser to display locally hosted HTML pages
Well that's pretty straight forward, albeit a little perfunctory. Let's see if we can expand on that a little bit.
One of the more popular examples of such a toolkit is Apache's Cordova project. Cordova supports almost every smartphone platform that has been conceived to date, and provide plenty of cross-platform plugin goodness to allow you to access the device camera, accelerometer and do other things like create splash-screens.
There are lots of other products out there, and they won't be listed here. Google can help you find them and, should you decide they are for you, help you select the most appropriate toolkit for your requirements.
Pro's and Con's
So you might be asking yourself, "If I can just write my app once, and my code will work on pretty much any mobile platform I want, why wouldn't I do that?!". As with anything, there are lots of wins as well as trade-offs associated with hybrid apps.
Write once, test everywhere
Probably the most obvious pro's of this sort of app development is that you only need to write your app code once. And because what you're writing is designed to run within a web browser you can run simple functional tests in your favourite web browser. Coupled with a local HTTP server you have a simple and straightforward development and test environment for local testing.
When you think you've got your feature or fix ready, you can then build native applications for each of the platforms that you need to support.
Writing in technologies used by every modern web developer certainly has its advantages. It's likely that you or your development team already have existing skills in this area, and if not, there are a plethora of tutorials and on-line courses devoted to teaching the whys and wherefores of modern web coding.
As I mentioned before, there are lots of frameworks and toolkits out there to aid in the development of Hybrid Apps. I mentioned Cordova, but a quick search of the web yields many different toolkits and frameworks, all ready to help you build your first Hybrid app.
Cloud build environments
Quite a lot of the current Hybrid app toolkits also offer (via a paid subscription in most cases) a cloud-based build environment to allow you to build your apps for any platform you like without needing the associated operating systems or SDKs on your local computer. This is a real plus if, say, you want to develop an iOS app but don't have access to a Mac with XCode.
So that's a couple of the positives about Hybrid apps but lets also look at some of the potential downsides to this approach.
Apple, Google and Microsoft release updates to their operating systems and associated SDKs with some degree of frequency. These updates invariably contain additional functionality, additional methods or make changes to or deprecate other methods or functions.
Frameworks or toolkits that rely on these SDKs must then spend time "catching up" to the current SDK level. This takes time, with the amount of time dependant on the developer base of the toolkit.
What this means for the developer of the hybrid app though is that it often takes some time before its possible to use all those nifty new features that are being release. Not being able to take advantage of these could put you at a disadvantage compared to your competitors
This is a subjective comment, and I make no bones about that. This one is my opinion only, so if you don't care about that, skip to the next one (or.. don't read this blog?) It's my personal experience that the user experience of hybrid apps lacks something when compared to their native counterparts.
I find that hybrid apps lack conformity to the smartphone UI and also tend to be somewhat "slow". Of these two, the lack of user experience integration is what concerns me most; the success or failure of an app can hinge on how easy it is for users to interact with it. Making the app use the same, familiar controls and have the same look and feel as the other apps on the users phone means your app will be easier to use.
As an aside, whilst this is my opinion, it is shared by others. Mark Zuckerburg once said that
The biggest mistake we’ve made as a company is betting on HTML5 over native
Not everything is cross-platform
Whilst the framework and toolkit makers do their best to provide frameworks for everything, there is the unfortunate (depending on your point of view) that Apple and Google and Microsoft don't always do the same things and this means that there will always be some things, features, or services that only work on one platform or another.
So.. at the end of the day you will still need to support different things on different platforms.
A better solution?
At last we come to the real reason that I'm writing this article.. and that is that I think you can get the best bits of a hybrid app whilst still developing native apps. How do you do this? You turn to another framework. A framework like RubyMotion or Xamarin. These tools are a little different to the hybrid app frameworks I discussed earlier.
These frameworks all you to write native apps for a variety of different platforms using tools other than those provided by the OS providers. Whilst this means that you still have to write separate apps for each of the platforms you wish to support, it gives you one key and very important feature and that is, the ability to share common code across all of your applications.
That means that you can wrap your business logic and other core functionality into a common library that is used between all of your apps. You can then write individual apps for each platform, using all of the native functionality that each platform provides (as these frameworks wrap the native SDKs of each platform and give you direct access to them). Using these types of frameworks you can also integrate platform-specific features into your app as soon as they're released meaning you can keep pace with the advances that each platform is bringing to the market as they bring them.
Now I will be honest and say that I have only had experience with RubyMotion, but already I would never go back to developing hybrid apps. Whilst RubyMotion doesn't currently support the Microsoft phone platform, I'm hopeful that it will soon be added (this may or may not happen as they are somewhat Mac-centric). They added Android support in the 3.0 release with a number of bugfix releases already having been made. Oh, and best of all, you get to write native smartphone apps in Ruby!
Xamarin's website states that it offers a similiar type of toolset. Xamarin uses C# as its language of choice, which is a turn off for me however if you have a team of developers who are familiar with C# then this might be just the platform for you. It also supports Windows Phone right now.
Neither of these platforms are free, there is a small cost, per developer, to use them. From a purely economic perspective however this cost is minuscule compared to the man-hours saved by these tools.
If you're a mobile developer and you haven't had a look at these frameworks, I highly recommend you invest some time and check them out.