Mobile App Development Landscape

One Monday morning, a client reached us out to develop a multi-platform mobile app for Banking. They have built a prototype with all the screens and that was our spec sheet. “Okay, Cool”. Now we got to build this idea of theirs, which was close to 50 screens. We only got 3 months. Whoa.

Where do we start? What technology are we going to use? Are we going to go for heavily adopted tech stack in the market or are we going to bet on edge technology stack? These were the questions that were ranting in our heads.

Amidst this confusion, we thought we should get a sneak peak of every possible solution before we pick one. We then started to analyze all kind of possible solutions in hope that we would get a solution. Oh, wait… That’s a bad idea! This analysis leads us to paralysis of not making a decision. This blog post is all about how we moved on with this paralysis by analysis. (We just began the development when we finished this article 🙂 )

(The prototype  consisted of more than 50 screens; needed integrations such as camera, NFC, Location Services, Push Notifications, etc.)


What is Our End Goal?

 -Ideal success scenario of our struggle

Deliver the mobile app idea with perfection which ultimately satisfies our client, the end-users AND US (It’s very hard for us to get satisfied with anything:-P. You would’ve known that when you read the title of this post itself)

We believe that every creation that we work on should be of pure enthrall. We never wanted to and never will, create something that we aren’t proud of saying that we made this.

Let’s Traverse the Decision Tree…


Native Apps: Apps developed through native development languages like Java, Objective-C, or Swift.
Hybrid Apps: Apps developed with web technologies which reside inside a native container which gives API access to native plugins
Almost Native Apps: Apps which runs on JavaScript virtual machines but takes advantage of native UI components

Native Apps

If you’ve come to this point of this article, you would know what we are going to talk about. YES! IT’S DEVELOPMENT NIGHTMARE. Writing the same app in different languages is like going through the same hell again and again. You can imagine how hard it would be to undergo maintenance and upgrades with different code-bases.

Of course, it would be a super-duper dapper thing if we build and maintain pure native apps. But, in our eyes, we believe that it’s not worth the effort and not feasible for the Project X with the time duration we have.

Oh, wait… Xamarin to the Rescue


Xamarin backed by Microsoft, offers you the ability to share 75% of the codebase while giving you the freedom to design the user interface for different platforms separately. It’s just WOW, isn’t it?

Native User Interfaces, Native API Access, Native Performance. And now it’s made FREE!
Yes. Xamarin would be a brilliant choice, but then again it’s not easy as we speak. Here are the cons which made us look into other options.

  • Time that we have in hand ( we have only 3 months)
    – Development overhead is very high
    – Testing and developing UI for different platform takes time
    – Certain requirements of the client may lead us to spend time in writing libraries which we don’t want to
  • The solution that we are offering needed rapid development
  • Xamarin community is not large as we expected.
  • Our Core team does not love c# language development ☹

We don’t want to discuss further. We just moved on to other options as it required more time for us to deliver the app

(We might suggest going with Xamarin if you have enough resources and development period)

Let’s Talk Hybrid

What we are going to discuss is basically apps whose UI Components resides in a web view container. Here’s the first pitfall: the web-view consists of a DOM and that leads to slower apps when compared to native.

Okay. We know it’s going to be slower, let’s see how this solution gets the upper hand.

  • Progressive App Development
  • Almost all native features are available through wrappers
  • Web Technologies (HTML5, CSS, and JS are our friendly Heroes)
  • Maintaining is easy as pie (at least when compared to other solutions)
  • Community Support is unbelievable
  • Etc.

Now we need to analyze whether we can compromise on the pros and cons. But before that…

Let’s look at the options available (at least the ones which interested us)

  • Ionic 1.3 with angularJS
    – Has an excellent community support; it’s been there for ages
    – Angularjs is our friend (but not)
  • Framework 7
    -Impressive and well documented, but lacks community support
    -Learning curve exists as it features its own framework
  • Sencha UI, Appcelerator
    -Needs a learning curve
    -Lesser community support
    -It’s not free…
  • Build our very own theme components
    -It’s very promising. But is it worth the effort?
  • Ionic 2 with angular 2
    -Hmm… I think this should do… but… Oh, wait… Ionic 2 is still in beta


While we were discussing the options available for hybrid app development. The community support of ionic and the framework itself impressed us. First, we dived into ionic 1.3.

  • Good documentation;
  • The framework is mature enough
  • Tech stack we already knew
  • Development Planning was easy peasy
  • We knew each and every bit of the whole development challenges

So we thought, without any further analysis we should pick ionic 1.3

Rollback. Rollback. Rollback

Ionic 1.3 is built on angularJS. We have a terrible experience with mobile app development with angularJS. Considering the prototypes and the complexity of the app, we were able to forecast the performance drawback which we can’t afford to give in the app.


With Angular 2 just released around the corner, the architecture of Angular 2 gave us a promising performance improvement. Ionic 2, on the other hand, has much better UI and give native feeling to the app which is ABSOLUTELY FANTASTIC.

Before we lock Ionic 2, we had our concerns

  • After all, it’s a hybrid app, it will not hit very high on performance
  • Ionic 2 is still in beta
  • Angular 2 it’s a new stack we should learn

So why we were not reluctant to keep the bet on ionic 2?

  • Ionic 2 recently (relative to 20/12/2016) has locked their API which means we won’t be having any major issues with regards to their framework.
  • The phones that we are targeting are phones with almost good performance (ideally, Galaxy S3 and later versions).
    In this context, will the performance be a big barrier? We do not think so. This is the reason behind it -> “A healthy community won’t back a Mobile framework if it doesn’t guarantee the expected performance”

So, we are actually betting on the community behind angular 2 and ionic 2 that it would be the best solution for this mobile app development work.

And it starts… starts with angular 2


We began exploring angular 2 and Ionic 2 and started to build a throwaway prototype. While the prototype is in process, we mainly focused on re-thinking the UX part of the app and we started to sketch the UI with so that our client and our development team are on the same page for this Project X (We cannot afford any last minute changes as the development period as the timeline is very critical)

Almost Native Solutions

While we continued with Ionic 2, we thought of exploring the next branch: Almost-Native Solution, before we actually build the app.
React Native and Native Script were on our plate to discuss…

Both Frameworks boasts about native performance. They use JavaScript to power the logic behind while UI is handled with native UI components.

This sounds very promising!

  • Lesser development time
  • Known Technologies (almost)
  • Rising Community Support
  • Performance Edge


It is very hard to pick between React Native and Native Script. It will always end up as a battle between Angular 2 vs React JS.

We went on analyzing the available components and libraries with respect to project X in hand

Our Concerns

  • Available Native Plugin Integrations
    – Barcode Scanner
    – NFC
    – Push Notifications
    – Fingerprint Scanner
    – Camera API
    – Voice API
    – Google Maps
    – Bluetooth
  • Ability to custom style components
  • Stability in the APIs provided
    (we don’t want the application to break with future versions of the framework)
  • That’s almost I can think of now (Of course there can be any unseen devil)

Thinking from the point of our concerns, both React Native and Native Script are Ideal choices.

  • +1 for React Native because it already has plugin where Native Script doesn’t have it yet.
  • +1 for Native Script for styling options given out.

It’s a tie again!

Final Verdict


What do we choose…? Ionic 2? React Native? Or Native Script?

We Picked Ionic 2… Badum-tish!

It’s hard to pick the best out of the options we have on the plate. All we can do is, pick the best for the project (At least, hope that its the best)

Why Ionic 2?

We just picked few points as to why…

  • Ionic 2 has bigger community support
  • All Plugins which needed are already available
  • We can deploy a windows app as well
  • We have already learned the tech-stack by this time
  • Typescript; Better Tooling!
  • A Big +1 for styling and customization (you know why 😛 )


Is That All?


One of the main reason for us to go for Ionic 2 is Angular 2! Wondering Why? Here’s it….

In future, if the client decides to go native, Native Script will be there for the rescue. We believe Native Script also would support windows apps by that time. All the providers and business logic, doesn’t need to be re-written again! We may just have to create the UI components and rewire the entire app.

Don’t you think that this would be the best game plan?


The two key things in which we are keeping the bet are

  1. Healthy Community is Key #1
  2. Angular 2 and Typescript — We think the duo is Super Brilliant


Disclaimer 😛

This is a story and the flow of the article is aimed at our mindset when we were thinking about each solution. Get ready to be confused 😛

Next Article


    1. Hi Adam,
      Thanks for sharing Delphi 🙂

      We just had a very quick overview of it. It seems that there is a huge learning curve and a lesser community support for it. We also feel that wiring Native Plugins will be a nightmare.

  1. I think you took a reasonable approach and picked the best framework for your project! I’m a big fan of Ionic 2 but I know others will always fight about what’s “the best” framework.

    The best framework is the one that get’s your job and project successful done and leaves you with code that people don’t fear to touch in 2 years!

    1. Hi Simon,
      Thank you for sharing your thoughts.

      We totally agree on your point.
      “The best framework is the one that get’s your job and project successful done and leaves you with code that people don’t fear to touch in 2 years!”

  2. Honestly, the fact that you had to go through all of the options, and still only chose the solution that was easiest rather than better tells me that you probably aren’t qualified to be working on projects like this in the first place.
    I feel sorry for the client.

    1. We went through all the options to validate if we are making a logical fallacy that Ionic was the easiest. If you are given the option of choosing two technologies – Vue.js vs React you would you throw away Vue.js cause it wasn’t the easiest pick? What we have learned over the years is that it’s always good to take a step back and evaluate the available technologies (at least the top 3 or 4).

      Yes. Ionic 2 will not be a native alternative. It has its cons. But for us, for this project, we believe ionic 2 is a good choice. We have built a working prototype and so far we are happy with the progress.
      Also, the client is also very happy ?

      We also welcome your critics and would like to hear more about your view

    2. Give me a break. I went through much the same process but I started with Angular before Angular2 and Ionic2. I’m sorry. Just because you don’t chose the hardest framework to code in doesn’t make you a loser. Obviously, you haven’t ever had to actually run a business and make a profit. Further, customers ALWAYS ask for changes. There isn’t a single piece of software I’ve written in 40 years that hasn’t changed. The best solution is the one that can be modified relatively easily and will produce the desired results as quickly as possible without sacrificing performance (or at least too much).

      With Google behind Angular2 and their willingness to solve the issues with Angular even though they took big heat for doing so shows they’re (hopefully) willing to stay behind it. And, Ionic2 has embraced the PWA concept which is obviously going to be the future of web apps.

      I’m sure your the smartest programmer (oh, excuse me, ENGINEER) the world has ever seen. Best of luck to you.

  3. Nice job, IMO it’s good practice to always consider multiple options and discuss them with the client. If they agree with your views then why not use the framework you prefer? So kudos on your choice and do it all again for the next project.

    Also thanks mentioning, looks like a nice new NativeScript plugin I can work on this week 🙂

  4. Well we just developed our first ionic 2 app as well. Ionic has a layer added on top of Cordova plugin which actually wraps it in a nice way with promises that play well with the rest of the framework.
    But the roadblock was when we wanted the push plugin to subscribe to topics. The feature was available in the native Cordova plugin. But the ionic wrapper wasn’t updated yet. And the feature was in development for a month plus but still not merged with the main branch. So had to find work arounds.
    Apart from that I did enjoy ionic 2.

    1. Hey 🙂
      Thanks for sharing your experience with Ionic 2.

      We also faced some plugin issues where we had to do workarounds. But, we believe it’s a price that we have to pay when we bet on a framework which is still in beta.

  5. Wow! This can be one particular of the most useful blogs We’ve ever arrive across on this subject. Actually Wonderful. I am also a specialist in this topic therefore I can understand your effort.

  6. Thanks for sharing excellent informations. Your web site is so cool. I’m impressed by the details that you have on this site. It reveals how nicely you understand this subject. Bookmarked this website page, will come back for extra articles. You, my friend, ROCK! I found just the info I already searched everywhere and simply couldn’t come across. What a great web site.

  7. I’m sorry but reading “Native development is a development nightmare!!” really rubs me the wrong way. Aren’t you overlooking a few things? For example, depending on the product you’re building, it might be the ONLY real solution. Surely we, as developers, know that certain tools are better at different things. An enterprise web solution will likely use Java/struts or whatever (or the .NET alternative) whereas a smaller scale web solution can get by with PHP, etc. Well, mobile development is a development stream of its own and if you want expertise in that field, you need to acquire experience in it and not treat it like an offshoot of web development. That may work for small & simple products but at some point you will want real OO development, to build your own frameworks, create your own animations, deal with threading/background process issues, high performance, etc.

    It’s usually a development nightmare if you DON’T have the resources (expert mobile developers) to do the job. There is absolutely nothing with multiple codebases for different products. At the end of the day, you need expert developers to build your products and they get to be experts by learning a language/framework and developing multiple products with it – whether it’s angular & cordova, REACT, Iconic, etc. If you are working for a mobile dev shop then you NEED native expertise…and for some projects, using REACT or other technologies may be just fine. For YOUR project and YOUR developer resources, using REACT or ICONIC may have been the right solution; however, it’s not just an either/or question!

    1. We agree with your concerns. Hybrid Solutions are NOT ALTERNATIVE to Native Solutions. I also agree that ‘Development Nightmare’ is a little exaggerative. But, when compared to Hybrid Development, Native Development needs additional resources and time.

      Our concerns included timelines, budget, and other resources. We picked Ionic because it served the requirements of the client. We explained the cons and pros of Hybrid Solutions, and the client was alright with it. In our eyes, a Hybrid Solution seems to be the most efficient solution for this project.

Leave a Reply

Your email address will not be published. Required fields are marked *