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:
- 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 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 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:
Or to show it another way:
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
- 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
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:
- Good article to read on building fast loading mobile websites
- LinkedIn set out to use a hybrid model – the objective, to be simple, fast, easy, and reliable
- The FT web app is a well known example of a web app. Here’s an interesting feature from the UK Guardian newspaper about it – it took a while for them to follow it up with an Android equivalent, but after a quiet beta launch to gather feedback they have an Android hybrid app openly available from the Google play Store
- Facebook moved back to a hybrid approach with a strong leaning towards native following their problems with HTML5 dev
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.