Sunday, February 21, 2016

Mobile development - to be native or not!

Whenever you start a new cross-platform project, there is always the question about whether to use native languages and tools for each platform or just build an HTML/javascript solution that works fine on all platforms.

The decision to use HTML/JS is easy for most teams - you have a single code base, you are working against a tight budget, you have hardly enough time to develop for one platform, you have to develop a website anyway to handle the fringe mobile platforms or to provide ubiquitous access, the team may have expertise only on a few platforms & you can create quick prototypes to impress the investors or execs etc. The rich ecosystem around tools & open source libraries also helps with the choice.

Ionic has emerged as the leading platform for building applications for mobile platforms using HTML/JS technologies. It leverages angular JS & Cordova to offer the promise of build once and deploy everywhere.  But, there is always a catch, right?  The HTML/JS applications are indeed an excellent choice for certain types of applications, so there is no single correct answer to the question about the technology choices.

But, you might have to consider a native application, if you are building a solution:
  1. that takes advantage of the unique features of the platform.
  2. that showcases best-in-class interaction & animation
  3. provides the native look and feel
  4. and prefer to avoid cross-language debugging problems
  5. on platforms where the browser technologies may not be available. eg. watchOS
  6. that needs to be future-proof (exist beyond the time that ionic/react native may survive)
Please note that there are existing alternatives to most of the above except for #4 & #5. You can take advantage of unique features by writing cordova plugins that work on each platform.  But, now you need to have in-house skills in each of the supported platform, maintain it & debug it when there are new platform releases. 

There are hybrid solutions like Xamarin & React Native that lets you build a native UI by using a single code base in C# or JS respectively. React Native provides some excellent features, but is supported only on iOS & Android, with some upcoming efforts to support platforms like OS X. This does give you #3, but #1 & #2 still requires custom plugins which again introduces similar problems as cordova plugins.

You could also consider other options like NativeScript, Titanium, Java2ObjC, Flutter etc for cross platform development. Flutter is unique because it uses Skia to render components without leveraging any native components. Java2ObjC depends on writing model code in one language & then automatically converting it to another to help write custom UI and re-use model code. Golang, Lua, Haxe, OpenGL etc are also other less popular options for partially developing cross-platform functionalities.

The native toolset & libraries have independently matured for each platform that helps you kickstart you project quicker than ever before. The cocoapods libraries in iOS is just an example of how easy it is to integrate with several high quality open source components. There are tools that let you build a complete UI without code via storyboards. The Android IDE lets you auto-generate several common UI patterns.

Personally, I have been a proponent of HTML/JS in the early days of mobile development, but I have also been through the stages where you pull your hair to just create a screen that is "native" LAF with buttery smooth interactions. This was before the days of Ionic, but I believe it hasn't changed a lot if you need to build custom components even though it is definitely possible. The application at the end felt just good enough,  because most of the time was spent making the app look like "native". 

So, please review the above requirements & potential issues before you make the final decision. The good news is that you can make both options work in most applications due to the hybrid options & plugins available. It is the amount of time & hardship that maybe different.