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
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
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
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
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 sketch.io 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…
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
- Available Native Plugin Integrations
– Barcode Scanner
– Push Notifications
– Fingerprint Scanner
– Camera API
– Voice API
– Google Maps
- 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 Card.io plugin where Native Script doesn’t have it yet.
- +1 for Native Script for styling options given out.
It’s a tie again!
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
- Healthy Community is Key #1
- Angular 2 and Typescript — We think the duo is Super Brilliant
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 😛