Have experienced one of these scenarios?
- Your CEO just got an iPad and wants you to build an app as part of your marketing efforts. But only 10% of your audience is using iOS.
- Your best customers insist that if you had an app specifically designed for their (insert new toy here) device to access account information and order online, they would do more business with you. (But none of them even use the extranet you built.)
- Your sales force wants an app for their iPads, but your distributor network doesn’t even have iPads and just wants mobile-friendly content.
Defining your mobile strategy and determining where to invest your budget is difficult when you have so many stakeholders to please. What the CEO, salesforce, or your best customers want, might not align with what your broader target audience needs. Establish goals and arm yourself with data. Finding discussions about whether to build a native app or web app isn’t hard–it’s an old and debated topic. But, finding one simple source that briefly summarizes the considerations for each approach is.
Should you build a native app or Web app? (And don’t forget about optimizing your site for mobile.) It depends on your audience and goals. Should you use this reference to help explain the considerations to your stakeholders? Absolutely.
| Consideration | Native App | Web App |
| Audience reach | Smaller, niche audience | Broader audience and reach |
| User experience | Can be designed for the device to be feature-rich, flexible and responsive | Generic approach, less access to all of device’s features |
| User interface and design | Adheres to UI guidelines, looks and feels like device | Generic approach, doesn’t “feel” like an app |
| Internet access | Not required | Required unless built with offline capabilities using technologies like HTML5 |
| Device compatibility | Platform-dependent; written for operating system versions so as versions change functions may be disabled | Cross-platform; requires compatible browser |
| Installation and updates | Must be released/deployed and downloaded by user | Automatic with refresh of browser |
| Distribution | Requires review and approval by app store (Associated costs if fee-based; for limited access app, requires enterprise store setup) | Requires compatible browser and Internet access |
| Device capabilities and integration | Can be designed to use the device’s potential (camera, GPS, gyroscope, accelerometer) | Limited but improving (geolocation and orientation are common) |
| Media and file formats | Flash only works if the device supports it. Audio and video may require conversion but few problems. | Flash works when supported. Audio and video may require conversion for compatibility. |
| SEO | Not searchable on web | Searchable on web |
| Find-ability | Must integrate into marketing efforts (store distribution model alone not viable due to number of apps) | Must integrate into marketing efforts |
| Analytics | Trackable if built into the app | Trackable using existing methods |
| Social bookmarking, sharing, and blogging | If built within app’s capabilities; may be unique for the app | Uses standard web methods and best practices |
| Data storage | Requires space on device | If server side, requires little to no disk space |
| Development and maintenance costs | Requires tools for and knowledge of specific platforms. Have to build an app for each new platform. | Same upfront planning and design process but created once. |
| Security issues | More secure as does not need to connect to network as frequently; access must be compliant with company IT guidelines | Security models should follow standard web security practices; requires connection to network |
0 Comments