April 17, 2015

Hybrid or native mobile apps (part 2) – A technical stance

Written By Martin Sandhu
Scroll

In January Bre blogged about the differences between hybrid and native applications,  this month I will try to expand on Bre’s article from a more technical point of view. As developer I know that each app is unique and requires a fresh approach each time. So when should you develop a native mobile app, or go for a more universal hybrid version? The answer depends on what your app does and requires.

So, what’s the difference?

Native mobile apps are specific to a particular mobile platform, such as Android or iOS. They are written in the platform specific programming language, Java for Android and Objective-C or Swift for iOS, and work alongside the platform SDK (software development kit).

Through the SDK the app has access to many of the phones hardware elements, such as the camera, speaker and microphone. Companies large and small, from Nottingham individuals to global brands, use them.

Hybrid apps embed HTML5 web applications within a native wrapper. These apps use standardised web technologies such as HTML5, JavaScript and CSS, which are then rendered to looks the same way across a wide variety of devices. The native wrapper then allows access to the phones hardware elements from within the web application. They were used by media giants BBC for the Olympics and provide flexibility.

What are the pros and cons?

      • Native
      • At Roller we primarily develop native mobile applications, which are:
      • – Tailored for each platform. This results in a more natural feel for each platform and a better user experience. A common example is that iOS devices have no physical back button unlike Android devices, and will need a different design pattern.
      • – Fast. They compile into native device code and have direct access to the processing power and hardware elements.
      • – Highly customisable. As native apps use the building blocks provided by the platform SDK’s they can be moulded to create highly specific applications.
      • – Take advantage of device specifics, such as Touch ID or NFC.
        • But, there are drawbacks, which include:
        • – Not all platforms provide the same SDK elements and do sometimes require 3rd party libraries. These are often open source, but do sometimes require licenses.
        • – The code needs to be written in a specific language and is non-transferable between platforms, which increases development time.
    • Hybrid
    • Hybrid applications are an attractive alternative to developers with an existing web technology background. They are:
    • – Cross platform. Which means the application only has to be written once for a variety of platforms, reducing development time.
    • – Provide a consistent look and feel, independent of the device they are run on.
    • – Can be written by existing web developers without the need to retrain.
  • Hybrid apps do have their drawbacks:
    • – They are slower than native applications. Because they reside in a wrapper, and all instructions from the application must be translated into native commands there can be a delay when accessing hardware elements.
    • – The graphics are rendered using web technologies, which emulate the native look and feel. Each platform has a different user experience, which can be difficult to cater for in this “one size fits all” method.

So what’s best?

As mentioned at the start, the answer to this question ultimately lies with what the application needs to do. With a native application you can produce a highly specific and customisable product. With hybrid applications you can produce a more general application far quicker using common web elements.

As a developer with a skill set firmly planted in native mobile development, I always create my apps natively. I find it’s easier to work with the SDK building blocks than via a sometimes-limiting native wrapper. There are drawbacks – each platform provides it’s challenges and can be frustrating with the their intricacies and quirks, but once you know them you can do far more than with hybrid frameworks.