• NZ 03-441-3223

Wine iPad and iPhone App Best Practice: native, hybrid or web?

One of the first decisions you’ll need to make when creating a wine iPad or iPhone app (app is application software, run by touching an icon on your iPad or iPhone) is whether you should make it a native app, web app or a bit of both i.e. a hybrid app.

Although this sounds technical it is probably the first question your app development agency is also going to ask as some agencies only do one type or the other as they require different types of programmer.

Note I’m not talking about whether you should have a mobile website or an app – the answer is you should always have a mobile website which I’ve written about before.

Native App

A ‘native’ app means an app that uses the mobile or tablet’s native code and runs like any normal app e.g. Mail or Contacts. I prefer Apple products so for me that means Objective C. In the case of Google phones and tablets it means Java. A native app can be purchased through the Apple App Store (accessed directly or via iTunes).

Web App

A ‘web’ app means an app that uses standard website programming languages, specifically Html5, CSS3 and Javascript code.

The app runs inside the iPad Safari browser. If it runs inside a browser how can it be an app, I hear you say! Well when you go to the web page it will show Safari’s toolbar and the tab bar at the top. But if you click on the Action button (an arrow in a box, fourth icon from the left in the toolbar) you will see the menu item in the dropdown menu ‘Add to Home Screen’, see screenshot to the right. Web App - add to home screen menu

Selecting this will add an icon to your iPad/iPhone and the next time you click on it you won’t see the Safari brower at all. Instead it will look just like any other app despite technically running inside Safari. Pretty cool huh! A web app can be simply downloaded from the web. It cannot be downloaded or featured on the Apple App Store.

Hybrid App

A ‘hybrid’ app is a web app that is ‘wrapped’ in native code – a combination or ‘hybrid’ of both types. This gives advantages from both types of apps which we’ll talk more about this option below.

So in technical parlance you have three options:

  • Native: native code in a native container
  • Hybrid: web page in a native container
  • Web: web page in a browser container

At first blush I like the idea of a hybrid app a lot but in the end choose the native route. Here’s why…

App Speed

The native crowd look down their noses at the slower speed of a web app – everything has to be downloaded from the web causing at best a slight delay. The web app developers say that is no longer a problem because the new version of html, Html5HTML5 logo, can use something called localStorage to store the common parts of the web page (header, navigation, sidebars, footer) on the iPhone or iPad itself. The hybrid crew point to development software like Sencha and wrappers like PhoneGap that can also take care of this.

Confused? I’ve trialed all three and frankly native is noticeably faster. It’s not just the download speed it’s also that the native code works directly with the iPad/iPhone operating system iOS without any other code in the way (called ‘layers’ in the software world).

Having said that we’re talking half a second or two – though sometimes that can be okay. For example a news app will always need to download the latest news so we accept that slower performance. However if we are changing pages on an app and it takes a second or two, just like a web page, then on an iPad we’re not impressed – the app appears clunky and flaccid.

For me this is a real dilemma regardless of what code I use because the first iteration of my app downloads the latest information from the vintank internet database – therefore there is likely to be a delay. I’ve got round this by using native code and caching the first page of wine content. If it was a web app I may have to download page design elements as well as the wine content.

Access to hardware

By hardware I mean the camera, accelerometer and gyroscope, but also push notifications (which I guess is more restricted access software).

I don’t see the need for the accelerometer and gyroscope as these tend to be more for gaming. I understand that the camera will be able to be accessed via web apps shortly. Which leaves only the push notifications.

From a marketing angle push notifications have been proven to be very effective. For example Ebay saw a 300% increase in conversions when they enabled this feature in their app. Indeed this blog has many examples of interacting with your customers to increase conversions and engagement e.g. email marketing, Facebook, Twitter. So this functionality is crucial. I know I know, whenever I install an app and it immediately asks me permission to send notifications I also say no – but it looks like enough people say yes to make this very effective.

The question then is can Sencha or Appcelerator, or such like hybrid frameworks, access this? Probably not though there is a service call Urbanairship that looks like it could do something similar. Still no banana, if you want push notifications you will need to go native.

Bar code, QR code and Image Recognition

In the future I want people to take photos of QR codes or wine labels to launch the relevant wine page from within the wine app. To do this I need the app to access another QR app, image recognition app, or build one into my app. I’ve looked for a way to do this with Sencha but without luck – looks like native again.

Internet connection

It seems obvious that you cannot use a web app if you don’t have an internet connection but that’s not quite correct. As mentioned above with something called Html5 ‘localStorage’ you can have a functioning web app without an internet connection. The classic example of an Html5 iPad app that does this is Chalk (link only works on an iPad).

Given one group that will use the app is wineries, and wineries are out in the boondocks often away from a good broadband connection, I feel I’ll be limiting my market if I have to rely on an internet connection.

Still, I’ll need to ensure that the native app does at least cache a few pages of wines. Although I’m going native it will still need to access the vintank database over the internet as mentioned above.

So why use web apps at all!?

Any app that is sold through Apple’s App Store requires approval before it becomes available for download. If you want to make an update, even for a small error, then it will need to be approved. If you want to use your iPad as a table tennis racket, then approval is required. Okay I’m joing about the last one. Apple is a benevolent dictator but it is still a dictator when it comes to their own tech platform.

And proudly so. They want the iPad user experience to always work and work well. Note it also has a set of moral principles, one of which affects us – we have to flag that our app is about alcohol so only adults can download it.

If you want to avoid this then use a web app and the Android market place. It’s a pain and I’m always worried about an Apple approver having a bad day and rejecting my app, but them’s the rules.

Revenue sharing is the other reason. Apple takes 30% of everything sold via the App Store regardless of whether you are offering a software type app or a newspaper type app. Fair enough.

Financial Times Web App ScreenshotHowever one popular app called Readability was caught in between. It allowed people to browse newspapers and magazines and save articles they liked to read later. It use to charge $5 for the app itself. If customers also wanted to subscribe to paid-only content then they could do so through the app, not the AppStore. Readability got 30% of the revenue and the content provider the other 70%. In early 2011 Apple rejected their app and said that any ‘in-app’ purchase also incurred a 30% fee – effectively taking Readbility’s subscription revenue. An uproar ensued, indeed one publisher has now taken the web app route only to avoid any sharing of subscription revenues (ft.com see image to right).

Don’t worry Apple is not asking for 30% of your wine sales this only applies to content-type publishers. My problem is that I want app users to be able to get (perhaps purchase) wine articles from various as yet to be decided publishers. To do this will be a minefield using a native app but not through a web app. But that’s a problem for another day and another blog post ;).

Summary

I’ve gone with a native iPad app because I want better speed, access to push notifications and QR code/image scanning, be internet free and be findable in the Apple App Store. Web apps almost make the mark and perhaps in the hands of a good web app developer could be made just as good. What makes me hesitate with native apps is the benovolent dictator’s view on in-app purchases.

Comments

  1. With any iPhone app development plan, you need to research your market and see how many your clients use which smart phone.

  2. Hi Bruce, I was wondering about the following sentence in your article “Don’t worry Apple is not asking for 30% of your wine sales this only applies to content-type publishers. ” So apple only charges for content type publishers? For example buying wine through your app they wouldn’t charge or buying food through the likes of GrubHub and Seamless they don’t collect 30%?

    Thanks

    Joe

Speak Your Mind

*