Mobile Apps · Mobile web

Mobile App vs Mobile Web?

Asad Shaikh AWS/NoSQL/Big Data Architect at Capital One

January 21st, 2015

Which approach pays higher dividends, if you have to pick one - building a native mobile app or mobile web. I am leaning towards responsive site that can be accessed for any device (desktops, tablets, phones, etc). The app approach only solves part of the problem.

Aleksandra Czajka Freelance Senior Software Engineer, Developer, Web Developer, Programmer - Full Stack

January 21st, 2015

All depends on what you are doing, Asad. is it a prototype, MVP? does it need any native functionality? does it need to access the phone's features? are the features the main parts of the idea? then it needs to be native. 

web apps are easier and faster to build and you can access them on any device. 

how is your target audience going to find you? will they be app store surfers? will they be internet surfers?

lots of questions to answer before you start asking that question.



January 21st, 2015

I agree with Aleks. If you need app features and/or expect that to be your key marketing channel then that forces the question; otherwise a responsive web app will have the broadest reach with one interface (and if things are engineered well, adding native apps that share the backend should be possible later).

The one clear wrong answer (these days) is a non-mobile-friendly web app. Optimize (and test!!) your web app on phones & tablets.

-- Glenn

Florian Pestoni

January 21st, 2015

I think it's probably best to think of this in terms of 2 considerations: user experience and customer funnel. Native apps tend to be more sticky and offer a richer experience (gross generalization). It also allows you to leverage the app stores for customer acquisition, although getting noticed is a challenge. I agree with Lalit that having a native app may still require a website, but in that case it may be just as a gateway to the app download experience, eg landing page selling benefits.

In our case, we built a quick POC as a responsive app, and we were able to get good mileage out of it with potential customers and investors as a functional demo that helped make our vision more tangible. We are now building a mobile app (using Cordova as somebody else suggested), but it's much more than just a website re-packaged as an app.

Juan Posada Technology executive, startup advisor and entrepreneur. Also a garage tinkerer and maker movement supporter.

January 22nd, 2015

In order to provide a more meaningful answer it would be helpful to understand what your business is (or will be) and what your definition is of "higher dividends". 

You have already gotten some good thoughts on how to frame the problem in terms of customer funnel and user experience/features.

I would add a couple more dimensions that are already implicit but imho deserve to be called out specifically. One is who your target customers are and what kind of devices they use, and the other one is your monetization. There are wide disparities between in terms of utilization, conversion, and profitability per user across different platforms and form factors, so take that into account. 

I was intimately involved with mobile for a global ecommerce brand that anyone on this list would recognize and can tell you that you would be shocked by the way in which certain platforms and even specific devices over or under indexed in any of these metrics. 

If you have more specific questions I will do my best to answer them.

Nitesh CSM Sr. Project Manager and Onsite Coordinator at Endeavour Software Technologies (a Genpact Company)

January 24th, 2015

One more factor which would help you decide between mobile app and mobile web is offline accessibility of your app or some of the feature.

If there is any feature within your app which you would like your consumers to have access even if they are offline (no internet) then answer is mobile app.


January 24th, 2015

OK, I've held off on any answers to this discussion, I'm very interested at where it went.

I'm a very Senior Mobile developer, I have over 8 years of iOS and Android development as well as over 15 year of web development.

I have experience from Enterprise, eCommerce as well as Social and Gaming.

There are two things I look at for mobile development.

1 - Do you want to make money (if so make it a Native app. Objective-C for iOS and Java for Android). iOS brings in about 80% more then Android, Android users expect everything for free.

2 - Do you want to be an app builder or a web site maker? Analytics are the same for Mobile as the Web so there is not important. Mobile users expect a better experience so if you want to access contacts, integrate with Facebook and Twitter, give GPS integration, etc. Make it native.

Yes Apple must approve apps submitted, I have never had an issue with this, I have been involved in over 300 native apps that were all published!

I teach iOS and Android development, I heave never been asked to teach Phone Gap for any company. Most Phone Gap type apps have two issues, the first is the amount of memory that can be used and then the runtime, you can not do anything in the background of the app without Native programming.

If you want to send Push Notifications of have any type of real time chat, then you will need a Native app.

Native app development is the SAME if not Cheaper then most mobile web apps, I have seen companies that went web for mobile and then had to spend time and money to create a native app.

Most native apps are built in 30 - 60 days.

Most of the time consuming parts are the back end services, web services and database work, this is needed for Native mobile or Web applications.

Native mobile apps are found on the app store, they have better user experiences and retention then mobile web pages.

Graphics design is the same for all platforms, spend $1,000 on UX, this will give you wireframes and the basics of the app. The spend $3,000 on UI to get a good looking app. Do not even thing about contacting a mobile developer until you have a solid direction this means yo have wireframes, mockups and graphics assets ready to work on, if you do not have these items they will charge you to wait and you will be on the phone with them over and over.

I am not looking to do this work for you (I currently have enough going on working with Apple) but if you need resources I'm happy to point you in a direction of people in the US that can help.


January 24th, 2015

We used + cordova (phonegap) for our app build & it turned out to be almost 'native' like without the phonegap lags most people report. I would highly recommended looking into ionic if you end up going the app route


January 24th, 2015

Should've prefaced that statement by saying that I think it very much depends on much native functionality & the core value add of the application. Our application was a basic job listing app that didn't require a ton of native functionality. (i.e. camera or GPS) There are a ton of Phonegap plugins available - though some of them might be out of date or not maintained. 

Bottom line: Depending on how complex/native functionality is needed - Phonegap/Ionic can be a good solution for your MVP. 

Diego Cardozo Developer

January 27th, 2015

First, you need to create a REST Api for your backend, here you have 50% of your solution done.

Then you must pick one approach based on your resources.

1- Hybrid app ( HTML5 inside a web container packaged for android / ios) and your web page.

2- Just your web page with responsive design.

3- Native app for ios / android and your web page.


1 - You can do this really fast if you already are a web dev, and you can get the functions of the phone on the mobile apps.

2- This will be easier to implement to you.

3- Native apps have better performance than hybrid apps and web apps.

Now, you have the resources for the first approach, the second one or the third approach?
All depends on that, but remember, if you go with a web or hybrid solution, take care of the performance of your code.


January 27th, 2015

Keep your API's on a separate domain from your app server, even if they are the same you will want to have control over the API's.

Always add an app token to API's as a Header, this will allow you to track what app / partner is making a call.

Always add a version into the url like this will make life much simpler, the issue with mobile is that you can not un-install apps on peoples devices so you do not want to kill installed users if you do not have to.

There are a couple of API gems for RoR that make life a little simpler.

Try to use the same API's for web, this means you need to use Ajax/JSON/Rest in your HTML5 apps.

Always run the API's on a secure server using sll so all access is with https.

Try to use standard rest, POST for create, GET for reads, PUT for updates and DELETE for removal(Mark as deleted rather then actually deleting the data for audit purposes).

Use custom API's when needed like /customers/getAllUnread

Use parameters when needed /customers?page=1&pagesize=20

That's my two cents.