In the blog post, Bruno Oliveira, Tech Lead of the I/O app project states “If one of the goals of the app is to be useful to conference attendees, the other primary goal is to serve as a practical example of best practices for Android app design and development.”
This is a guest post by Tim Masterson, founder of conferencehandbook.com. Thanks, Tim, for the insight!
If you’ve done any poking around in the mobile world lately you may have heard the terms “Native App”, “Web App” and “HTML 5” app. They are all different ways to provide apps on your smart phone. In the next few minutes I hope to demystify these terms a little for you, as well as share the tradeoffs of each technology.
What is the difference between Web App and HTML 5 apps?
Every HTML 5 app is in fact a web app. But not every web app is HTML 5. HTML 5 is basically a new set of tags that programmers can use to display your application in a web browser. HTML 5 supports some really cool stuff like video and it also makes it easier for the developer to do asynchronous calls back to the web server. The term “Web App” is used to mean any application that needs some form of a webserver to run.
- Benefits: Write once for all platforms. Updates are server side and instantaneous.
- Trade offs: All logic is on the web server so network connectivity is required. Users user the browser to access the app and not an app store icon. Access to sensors (GPS, Cameras, accelerometers) is limited.
What is a “Native” app?
In general apps you get from the app store are “Native apps”. A truly native app is written in a language and compiled down to an actual executable that runs natively on your phone with out a browser. Some native apps, still connect to web servers to interact with data in the cloud or to receive updates. In general Native apps have access to more sensors than web apps. They also tend to run faster because more of the processing is done locally. The draw back is in the cost to develop a native app. To develop for many platforms you have to rewrite the app for each platform. (Which explains why it took months for Android users to get their own version of Angry Birds).
- Benefits: Access to all sensors, the users address book, schedule, GPS. Runs without network connectivity. Graphics are cleaner due to hardware acceleration. Available on the app store.
- Trade offs: Entire app must be rebuilt for each mobile platform. The user must initiate updates, unless the app is built to automatically update itself.
Some apps are in between
It is possible to write a native shell for a web app. To do this the developer writes the bulk of the app in HTML 5. Then they write a native wrapper for each platform that basically has an icon, and a page that holds a “Web View” the web view then calls back to the web server to get the app content. This approach is great for some applications but still has it’s own set of trade offs.
- Benefits: Only the shell must be rewritten for each platform. Users can access the app from the app store. If use is in a place where network connectivity is good, the user will never know it is mostly a web app.
- Trade offs: The app is dependent on network connectivity. The web app portion of the app will not be able to access the sensors.
The Bottom Line:
Know what you are signing up for when you pick a software vendor. Understand how they are delivering your content and the tradeoffs associated with that method of delivery. Make sure their method maximizes the size of your mobile audience while mitigating the tradeoffs.
About the Author:
Tim Masterson is the founder of Total Integrated Mobile, the makers of ConferenceHandbook.com. A one stop solution for the mobile app for your next conference.