Going cross platform on mobile, part two: Native, web and hybrid apps

So if we decide, having looked at the market and our product’s objectives, that we need to move beyond a single platform reach model, then we need to look at how we do this in the most efficient and effective way.

You can go native, using the primary programming language for each platform, but it’s going to need dedicated skills for each and of course the time to code for each mobile OS you want to have a presence on.  The alternative is to use well established and understood web technologies for product development, or to use a mixture of the two to create a hybrid approach with the aim of gaining the best of both approaches.  There are also frameworks that allow you to develop for cross platform delivery in one particular language and cross compile as necessary.  We mention these briefly below, but will cover the concept in more detail in part three along with frameworks that use web technologies as well.

In simple terms we can classify the three approaches to mobile app development as follows:

Native app

  • An app installed on a device (usually from an app store, but not necessarily) written in the ’native’ code of the platform/device.  It’s generally accepted that the UI of native apps does not consist of full-screen web page views alone – in this sense a web site ‘wrapped’ in native code in order for it to be distributable via Google Play, the App Store etc. does not constitute a native app.

Web app

  • Web apps are developed using standard web technologies to create a ‘web site’ that attempts to imitate the look and feel of a native app, or at least is designed to look and feel comfortable within the confines of a ‘mobile’ device i.e. it is not just a web page designed for desktop simply shrunk to show on a mobile phone.
  • When is a web app a web app and not a (mobile) web site?  It’s arguable, but for me in most cases it suffices to say that a web app follows the same model, and is used in the same way, as a native app.  The UI is structured along similar lines as an app and is focused upon a specific task.  That it might be consumed via the device’s browser rather than installed through an app store is not seen as making the defining difference (it might make a difference in terms of performance, but that’s not the user’s concern).
  • Also a web site may use responsive web design approaches and mobile best practices to improve the look and consumption of the content on a mobile device, but if it isn’t following an app style user model it can again be argued that this is a web site and not a web app.  As you can tell the difference can be a bit of a grey area.

Hybrid

  • Hybrid apps are an instance of a native app, utilising web and native tech/functionality to varying degrees (e.g to access the device’s camera or to provide the ability to receive push notifications).
  • Most people probably understand a hybrid app to be a similar proposition to a mobile web app, but packaged as a native app with access to native services (à la Phonegap/Cordova apps).  They either try to mimic native look and feel or at least are (hopefully) designed to look and function comfortably within the confines of the app use case.
  • However, hybrid apps sit on a spectrum; ranging from simply being mobile web products ‘wrapped’ in an app (offering little if any native functionality to differentiate them from mobile web) through to hybrid apps that are almost fully native.

Cross compiled apps

  • Cross compiled apps are another approach that need to be mentioned.  Frameworks in this category allow you to write code in web technologies and/or a selection of programming languages, which can then be compiled down to native code for specific platforms.  In theory they should provide closer to native performance than web apps do, but feedback from developers is varied and likely dependant on what is required from the app.

The above are touch points on a spectrum of possibilities, where native functionality can be mixed with web centric technology to varying degrees resulting in varying strengths and weaknesses.  The mix you choose for your product will determine the level of interoperability you have verses the level of functionality:

IntVsFunct

from: http://designmind.frogdesign.com/blog/unraveling-html5-vs-native.html

Or to show it another way:

Nathtmlhyb

from: http://wiki.developerforce.com/page/Native,_HTML5,_or_Hybrid:_Understanding_Your_Mobile_Application_Development_Options

There are many sites that list the pros and cons of these approaches in detail, but in overview you’ll find the following to be true:

  • Native will always be faster, and especially so for richer and more involved experiences, however the drawback is you have to redevelop your product for each platform and you need access to skilled developers as required
  • It’s good to remember that expectations are different when people open an app compared to when they browse a site – native is on balance more capable of delivering the functionality that’s expected from an app, and so more focus will be needed to meet user expectations when developing apps via non native frameworks
  • Mobile web apps use known technologies, offer greater cross platform reach and promise ‘write once, deploy many’ capabilities, however the truth is that the differences between devices, their browsers and OS means you can not guarantee how well they will perform across all permutations – pure web apps do not have access to native functionality and we’re still waiting on standards to be set by W3C.
  • Hybrid apps potentially offer the best of both worlds, utilising native code to leverage native performance and functionality, whilst creating other elements in web technologies to gain the benefit of known tech, quicker updating/maintenance (web elements can be updated within the app without the need to resubmit the entire app to the app store), and easier portability
  • As previously mentioned, hybrid apps exist on a spectrum going from highly web app oriented to heavily native, depending on the needs of the product – there are also a number of frameworks that allow web code to communicate with and use native functionality, but these perform to varying degrees and due diligence is needed to confirm if the framework delivers sufficiently for your particular needs.

There is no right or wrong approach, but right now you have more chance of seeing a badly performing web tech based app than a native one.  If you’re going to leverage web or go hybrid make sure you do what you can to make your solution as performant as possible.  I have read a number of studies during 2013 that indicated the majority of people were disappointed with their experience of browsing web on mobile devices and would use their smartphones more if the browsing experience improved.  64% of smartphone users expected websites to load in 4 seconds (compuware, April 2013).  Download speeds are the biggest factor in achieving this – to hit the 4 second load time, based on general UK speeds right now, a website should aim to be a maximum of 1MB for 3G users and 3MB for 4G users. However due to network latency, smartphone memory, cache and CPU, in reality the download size needs to be less to make up for all of these potential bottlenecks.

Below are some best practices for making web performant.  These especially apply to mobile:

  • Reduce dependencies/HTTP requests, image dimensions, and client side processing whenever you can
  • Use CSS3 instead of images where possible, sprite your images using CSS or transfer your images using a data URI scheme
  • Minify your code
  • Eliminate redirects
  • Load contents lazily and don’t load data that will never be seen or used by the user
  • Utilise a mobile content first policy for your web content or create pages specifically for mobile use alone
  • Plan for the lowest common denominator if you’re looking to reach many users – alternatively focused on a specific set of devices that represent your audience and focus on their capabilities alone
  • JavaScript on devices with slow processors can be expensive to execute, so it is important to make sure your client-side code is lean, mean, and uses minimal memory too, as well as implementing network-based optimisations
  • Policies and standards for web technologies using advanced features like geo-location, camera integration etc. are still developing and the implementation of HTML5 is far from uniform – it varies from browser to browser and from mobile platform to mobile platform, so be cautious of any promises of “one size fits all” tools and perform some proof of performance tests up front:
  • The Nitro JS engine used in mobile Safari is not available to the UIWebView, which is used to show web content within apps on Apple devices, so performance will be worse – test how (the lack of) JIT compilation affects your app’s performance by building a test app, or alternatively by installing Google Chrome for iOS, as it uses the same UIWebView component and is similarly compromised when it comes to JIT compilation
  • Similarly the same browser engine isn’t used across all Android devices and so performance can differ in this way too
  • Write efficient JavaScript code that doesn’t block the UI thread and follow language optimisations and best practices for it

Lots of scope for deep diving on this subject, but that would turn this blog entry into a book.  Instead the below links should provide some food for thought on the subject of mobile app/web development and act as a springboard to further investigation:

If you take away one thought from the above let it be this: there isn’t one ring to rule them all… not yet anyway.  Right now we still need to take each mobile project on its own merits and decide the best approach for it.  The choice you make will be dependant on the product you want to create, the skills you have to hand and the other business factors that influence your efforts on a daily basis.

That said there is still a trend for developers to be moving towards HTML5 and other cross platform facilitating frameworks, and understandably so when we need to make our development efforts as efficient as possible, but it is by no means a clear cut decision yet and the options available must be explored.   Take a look at this article from VenturBeat on what developers felt at the end of last year.

In part three we’ll wrap things up by taking a look at three available frameworks that offer an alternative to native development for going cross platform on mobile.

Advertisements

One thought on “Going cross platform on mobile, part two: Native, web and hybrid apps

  1. Pingback: Going cross platform on mobile | New Technology Development Team Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s