Status
This is a draft, work-in-progress analysis derived from the “Closing the Gap with Native” Headlight task force.
Introduction
To compare the various existing mobile apps development approaches, two main perspectives can be taken:
- from the end-user perspective: how well the said development approach will make it possible to provide the best possible user experience;
- from the content and service provider perspective: how well the said development approach will optimize their costs and benefits.
This document applies the separately developed model to analyze a give mobile app development approach from provider perspective to Web applications.
See also:
- Proposals to reduce the gaps of Web applications from a provider perspective
- Framework to compare mobile apps development approaches from a user experience perspective
Web Applications Strengths and Weaknesses from a Provider Perspective
| Provider experience parameter | Strength | Weakness |
|---|---|---|
| Development cost | ||
| Hiring / training developers | A lot of Web developers | Not many Web developers know how to develop good Web apps for mobile |
| Writing code | Plenty of IDEs for the Web | Support for responsive approaches? |
| Finding documentation and guidance | Lots of Web-related sites and forums | Lack of authoritative content? |
| Finding libraries | Lots of them | Hard to find the right one, esp. with mobile constraints |
| Reporting platform bugs | Technologies are developed in public |
|
| Debugging and diagnostics | Same Web platform on desktop and mobile makes it somewhat easier to debug |
|
| Testing | Lots of automated testing tools, incl. on mobile | Hard to test chrome-based user interactions (e.g. consent dialog) |
| Deployment cost | ||
| Getting authorization to deploy | None required | |
| Uploading the app | Mostly seamless | |
| Advertising the app | As open as anything else on the Web |
|
| Protecting the app code and operations | Server-side component out of reach to client-side attackers | Hard to get as thorough protection of client-side as available to native apps |
| Maintenance cost | ||
| Getting user input and feedback | Use the Web | No one-click infrastructure to share comments associated to a given identity (assuming reputation is an incentive) |
| Keeping up with incompatible changes in the platform | Platform evolutions are decided in the open | Hard to keep track of these evolutions |
| Getting visibility into future new features of the platform |
|
|
| Expected outcomes | ||
| Reaching out to as many users as possible |
|
Hard to design apps that work well across many devices, browsers, culture, etc. |
| Getting paid | Each provider can pick its most appropriate payment system |
|
| Getting recognition | Neutral? | |
| Enabling social change |
|
|
