A while ago one potential customer of ours asked our opinion on the issue of selecting the environment for mobile app development. They wanted to first build an Android mobile application, the iOS comparable would come later. They had no experience on mobile app development so they didn’t know where to start. We at VALA Group have the experience but for us also it always requires a lot of brain work to find the perfect solution that fits the situation in hand.
Even for the most experienced developers and project managers it always requires a great deal of consideration on many different aspects to get to the right solution. There are some wonderful tools these days that help producing great hybrid apps but still native apps have their advantages and thus are still superior in many important factors. Of course you shouldn’t forget basic HTML web apps, they also have their sweet spot in some projects. Mainly the consideration should focus on your company’s overall business strategy and skills available for the development work. The question is not which is the best way to develop a mobile application but rather which is the best way in your situation. This short post will prescribe the main aspects of the three options and provide guidance on what kind of things you should consider when choosing the best alternative for your company.
So these are the bad boys that rock the performance side of things. Native apps are fastest, smoothest, most powerful and they can take the most out of your smartphone’s capabilities. The problem of course is that you have to develop two or three pieces of these for different platforms (if you want your app to work on all them, Android, iOS, WP). Naturally more work means more time and money spent. So basically native apps are the Ferraris of the mobile world, they are the coolest and best but they will cost you more money than the other options.
There are a lot of different factors in all the three options. However we want to keep this post short and punctual so we’ll list the most important pros and cons of all of them as bullet points.
Web apps on the other hand are the opposite of native apps. They are easier, faster and less expensive to develop but you’ll also get weaker performance and UX and limited use of the smart phones capabilities (which is not a small factor these days). However nowadays you can create an experience that very much resembles native apps in UX and visually. Financial Times is one good example of this, www.app.ft.com (URL works only on mobile).
Hybrid apps are basically web apps behind a native app shell. They are made with web technologies (i.e. HTML5, Java Script) and sort of disguised as native apps and distributed through app stores. In many ways hybrid apps provide best things from both worlds (a good example of this is Netflix). On the other hand, it could be said that hybrid apps are aren’t fully taking advantage of either web or native sides.
At the beginning of your evaluation basically all you need to do is think of yourself (for once ;)). You would want to start with the solution that you are about to build. Ask yourself what you want the solution to be able to do and how will it do it (also think about what it should be able to do in the future)? Then ask yourself does it absolutely have to be able to do all of that, are there some features that you can leave out or are there some features that can be produced differently if needed? When you know clearly what you want to build, what features you must have and what features can be sacrificed if needed, then it is time to think about your (company’s) situation and resources.
First it would be wise to think about the users. Is it important for you to get as many users as possible in the beginning, or would it be reasonable to start with a smaller group of potential users (iOS users for example), handle that group well and then continue to the rest. For example some solutions may be targeted to areas where people mainly use Android. In these situations it can be wise to start with Android native app and continue with iOS (and others) if needed. Also you need to know who are going to be your users and more importantly how they would prefer to use your application.
Your resources are naturally in a very big role when considering the options. We think that the best way is to first think of what you want the outcome to be like and then see if you have enough resources to get there. If you don’t, then you need to evaluate what are the things that you can sacrifice (leave out or do in a different way). At the end money is unfortunately one of the biggest factors influencing on your decision. However, we think that you should never make compromises on the quality of your product. If you realize that you lack the resources to make the killer app you dream of, consider trying to raise more funding. Alternatively, if your boss is not on the same page with you budget wise try convincing him of the fact that good apps don’t usually make it big, only great ones have a chance.
It’s important to recognize that programming world is changing and evolving very fast. That’s why you need to stay alert and when you are making plans for your app you should try to investigate and think what the world is going to look like in 6 months, 12 months or even 3 years. We will update this post when needed so this should stay as a good place for you to check out the big picture, however keep in mind that this post is merely a glimpse of the current situation and you need to dig a lot deeper before making the final decision. If you think that you could use some tips or help, don’t hesitate to contact us. We’ve been helping businesses from startups to large corporation and we’d love to hear more about yours.
About the writer:
Toni is a Growth Hacker at VALA Group. His background is in business so he naturally always keeps the business side of things in mind when helping our customers. Business guy or not, Toni thinks that the most important thing is always the quality of the product. Check Toni’s and the rest of our peoples’ contact information here.
Blog post main photo: