Home»MOBILITY»Cross-platform Mobile App Development Dilemma: Decoded

Cross-platform Mobile App Development Dilemma: Decoded

Pinterest Google+ Linkedin

We live in an age where businesses are fast realizing, if not already, that they need to offer their customers cutting-edge mobile applications that will help them engage with the brand and its services, in near real-time. But which platforms do you build your app on? iOS? Android? Windows? Which one should you build first? For iOS, which programming language do you use – Objective-C or Swift? How do you overcome the significant duplication of effort in building native apps for each platform? That is where cross-platform application development tools come into play – they provide the ability to rapidly develop and deploy multi-platform apps, leveraging a shared codebase.

There are 2 kinds of cross-platform mobile app development tools available to developers – there are tools that provide high-level abstractions; meaning that they allow you to work with HTML, CSS and Java, mapping the underlying platform features to the modules within the tool. Then there are tools that use a common programming language to work across platforms, accessing unique features of each of those platforms.

These tools can further be classified into four broad categories:

  1. HTML5/JS script based solution embedded inside a native code container

Such a solution provides the user with a UX similar to that of the mobile-web experience, except the part where they have to remember the web address, as opposed to launching it from an app which is downloaded from the app store. This solution saves a lot of effort and execution time but lags in terms of device hardware integration, security and above all, performance and usability. A few examples of such tools include – Sencha, Jquery, Mobile and Phonegap.

Kony goes one step further with their KonyOne offering – It provides eclipse based cross- platform java script APIs to build cross channel mobile apps through the KonyOne Studio. It also provides libraries/APIs to include OS-specific properties, and the option to integrate third party APIs. The second component of the Kony solution is the J2EE based KonyOne server – it provides features like security, offline sync, notifications etc.

There are many pre-built, vertical based Kony apps as well which can be configured for a particular client to speed up their go-to-market strategy. On the flip side, all the Kony based competitor apps will also have similar features and usability. The major challenge with such solutions is user-based pricing, and the code generated can barely be ported if one decides to move away from this platform. Hence the customer gets tied to such solutions and it will require a complete overhaul of the solution to come out from this bond.

  1. Runtime-based Solution Providers

Appcelerator Titanium provides cross-platforms with JavaScript based APIs, for not just accessing native UI components, but also native device functionality such as file system, network, maps etc. In case the native access is not provided through APIs, it provides transparent access to native functionality. Source developed using Appcelerator is interpreted using Javascript engine such as Rhino for Android/Blackberry and Javascriptcore for iOS.

The cons of this method include – the app takes much longer to load compared to natively developed apps. It also has issues with cross-platform compatible APIs w.r.t memory management, causing many runtime and power related problems.

Adobe AIR, AppMobi etc. are other examples of similar offerings.

  1. Source code translation based native solutions

The Xamarin platform allows developers to develop applications in MS Visual Studio (along with Xamarin plugins) using C#/.Net coding. Using this platform, developers can build a common business logic layer, and using Xamarin forms developers can build a limited feature common UI layer. Though the Xamarin-based app is complied as native binary, it adds a small .Net runtime which has a slight impact on the app’s loading time.

The advantage of such a solution is basically the fact that it allows to use a common code across OS platforms, which is a good thing for.Net developers. The downside is that it doesn’t allow code generation, high cost of annual SDK subscription, new version support only after the platform upgrades to support the new version, and once you move to this platform, you’re committed to it forever.

  1. Native code generation tool based on provided schema

The SAP Mobile Platform is primarily a database schema based code generation platform. It creates native platform codes for various platforms and helps generate the data sync layer between the mobile app and the server. Using this platform, developers can write the business logic and the platform can in-turn translate it to a different version of the device OS. However developers are required to write the code for the UI layer separately in the respective native language, as it doesn’t support most of the important interactions available in today’s devices.

The pros include the ability to develop a sync layer easily and the ease in developing a simple UI. The cons include high device-based pricing, bound by the platform forever, and new version support only after the platform upgrades to support the new version. Another example for a similar platform is Antenna.

Looking at the pros and cons of all the offerings available in the market today, Endeavour realized there was a gap, and decided to build its own cross-platform development framework to address this challenge – EnCAP (Endeavour Common Application Platform). The advantages of this framework include:

  • The flexibility of developing a business layer once and using it across platforms.
  • It allows generating the native code based on the schema provided.
  • It has the flexibility of writing the code for an own, native UI layer.

Combining all these factors will essentially result in savings of 60-70%, in terms of code re-usability. To top it all off, everything is in pure native code, which makes life easier for developers and can easily be extended if required. There’s no binding to the framework, no dependence on the framework upgrade with the new version of OS launch, no device-based pricing and no performance or loading issues. Sounds appealing?

Is this a challenge your organization is facing currently? Does EnCap sound like a solution that will help make your lives easier? Tell us what you think in the comments section below; we’d love to hear your thoughts.

Manish Garg

Manish is the COO at Endeavour, where he heads the core departments of Delivery, Technology Consulting and UX. He brings to the table, a large breadth of knowledge about Mobility and innovative leadership skills. Technology and innovation continue to fascinate Manish, as he finds new ways to understand and predict mobility trends for the future. Manish also has a few patents to his credit in the Mobile Digital Marketing space. He likes to mentor the next-gen leaders in his spare time.
Previous post

Apple Watch Review: Not Living Up To Expectations?

Next post

The Really Tough Digital Transformation Crossword Puzzle!

  • Christina

    Xamarin’s architectural approach is commendable. It is not just a “write-once, run everywhere” platform. It has this unique ability to implement native user interfaces specifically for each platform which makes my life a lot easier.

    • Thanks for your note Christina. I agree with your views on Xamarin’s architectural approach. For EnCAP we follow the similar architectural approach except the part of getting bound with any specific platform since entire codebase will be in native OS language.