I headed to Web Monday Zurich 2012 #2, which also happened to be Mobile Monday, it was a shared event at the HP building in Dubendorf, and the topic was Native vs. Hybrid vs. Web apps. As I’m now involved with developing Lost In Reality, a mobile storytelling app, I’m very into this topic of choosing native vs. web/hybrid, so this gathering came at the perfect time for me. The following is a recap from my iPad notes, I’m intermixing what the speakers said with what I thought in my head, so hold on as this recollection could get hairy. There were three excellent speakers:

• Markus Leutwyler, HP: General overview on Web vs. Mobile vs. Native Apps
• Colin Frei, Liip: A case study on web / hybrid apps
• Vikram Kriplaney, local.ch: A case study on native apps

Markus Leutwyler from HP (@twtomcat)

History:

Now everyone is an expert and can make a web page, mobile started two three years ago, now the app is on the rise, we go to apps, not webpages. So now where are we today? Can everyone make a web app now? The web has a low entry barrier and it’s everywhere, browsers are everywhere, and now it is also an application platform. So what are native, hybrid, and web apps?

Native:

iOS, Android, Blackberry, Windows Mobile, you use a variety of languages based on the app market you want to target. Why native? Go native for performance, offline mode, find ability, device integration, monitization, user experience. You can make money with app stores. But what exactly is the native advantage? For example, now with WebGL we can do 3D in HTML.

Web App/Hybrid:

Html5, JavaScript, canvas, OpenGL, web sockets, css3, phone gap, ability to code one and export to different places (like with build.phonegap.com) Code reuse, common technologies, low entry barrier, cross-platform, familiar tools and techniques. While this doesn’t work for all applications just look at the trends, JavaScript performance is improving, hardware acceleration is coming, rapid browser evolution (short release cycles for Firefox), new tools frameworks coming out all the time.

Web vs Web Apps

Basically a web app is installed and able add to home screen. Then you have ChromOS, boot2gecko, where it simulates the native experience.

Collin from Liip (@colinfrei)

Why do an app instead of a web page? To access device functionality, camera, etc. discover ability via app store, reach different audiences than via a Google search, selling your app, ability for in-app subscriptions, easy for people to tap and spend money. Barriers? NIWEA is an answer, wrap your content in an app container, hence you can use Cocoon, Phonegap, etc.

• Phonegap: it is a container, gives access to device functionality via API using JavaScript. What are the advantages?
• Knowledge: many web developers know JavaScript, lower barrier to entry, portability, can reuse the code for different devices.
• Portability: Means you can view the sites on your browser, if you write the code well you can port the stuff anywhere and reuse it. All these things affect costs, so hybrid allows you to use advantages of native.

Phonegap is good with APIs that are wide ranging, and then use plugins to offer specific functionality, but it isn’t universal. In the end you still have to write some unique code for different devices and their unique app needs. Concerning app performance, native is always better by definition, and it depends on your use case, like games that are device intensive for hardware optimization, but you can try game closure and cocoon.js, it all depends on what your goal is.

TV App for Tages-Anzeiger:

The purpose of the app is that they just show you the good TV shows, based on their recommendations. You can stream output to your tv and devices, it’s free to try and then is subscription based. It’s an iPad app, but lots of it was Html5 and JavaScript. Video is done via Html5, Phonegap was used to wrap it for the app store. In-app plugin purchases was used for monitization. Did not do much with portability to other devices because everyone is using the iPad anyways. Development done in the browser and tested, then ported to iPad. In total, everything was good with using phonegap.

The Future

Hybrid is expected to be the future. Using the same code base is such an advantage in development. The hybrid aspect becomes much smaller, browsers will be able to implement device features, like camera tag in html5, that is now possible. Check mozilla API , see what sensors you will be able to access.

Vikram Kriplaney local.ch mobile architect

(@krips)

At local.ch they look at the breakdown of numbers for devices, iOS, android, etc. Why native? Well when they started developing for mobile it was 2008, they had expertise in iPhone, they had a mobile website, it was logical to first get a launcher from the phone and then just use the mobile optimized webpage.

In the end, user experience is biggest reason to go native. The user has expectations for that device, and they should respect that experience designed for that device. Performance is a big reason as well. Trust that the device maker has done all the optimization needed to give good UX via tight integration with hardware. Integration with other apps also good – more fine grain control. Now there are more frameworks than platforms for development, some are cross platform, some more on web side.

Leaky abstractions: any nontrivial abstraction will leak, you want to forget the details, but you end up for developing for each platform anyways. So why not go fully native from the start? Naturally for this you need a team with a wide range of competence, which local.ch has. The more audience they have on any platform, the more effort they put into developing for that platform as the platform evolves, launcher the web, hybrid, native. They do do hybrid, do it when it makes sense.

End Questions/Comments

• Is local storage a problem? In principle, offline functionality is not a problem.
• For testing, you can do automated builds and do UI testing with test flight.
• Backbone, spine as single page applications, for more responsive website.
• Yes mobile is going to take over.