Native Apps v Web Apps v Hybrid Apps

Zipppy

Which is best?

I realise that Web Apps can't access some native phone features...but understand that hybrid Apps are actually Native Apps wrapped in a Web App??

I've some Apps to get developed in work and the cost of hybrid v Native is huge..along with cross platform compatibility of hybrid...and development time..

Opinions??

The Corinthian

Depends largely on what you want to develop.

Hybrid apps principally replace a native UI with a Web one. This can have advantages, such as shorter development times (although this is arguable if you've good experience in native UI's), greater flexibility in updates (as the bulk of your business logic is on your server and does not require the user to update the app on their mobile) and greater ease in implementing cross platform apps (as all you need to write for different OS's is the wrapper).

Resource costs are also a factor; a PHP developer is cheaper than an Obj-C or Java one.

Where they fall down is typically that they are dependant on the user having a working Internet connection and your server being up; they simply don't work if either is offline, or if the connection is poor, can result in broken images and timeouts that can also affect user experience far more than in a native app.

Server bandwidth and processing power can potentially also be an issue given that the computational load of such apps is not being taken up at the client, but must be borne at your server. If you have a million users with your app and each is fetching HTML and images from your server, there's going to be a much higher cost to that than if all they were fetching was data in an XML, CSV or JSON format.

Native UI's are also arguably nicer and cleaner, although this is a matter for debate.

Another point is that hybrid apps need not necessarily be 'dumb' wrappers either. Many use both native and hybrid UI's and business logic depending upon what makes sense. Some bundle assets, such as images, with the app, so as to reduce server bandwith.

So it principally depends on what type of app you want to build; some types lend themselves more to hybrid apps, while others realistically need to be native.

Can you give a little bit more information on what you need to build?

Giblet

Corinthian has covered most aspects so I'll just detail my experiences with all three approaches so far.

Web App: No native functionality, just making a fancy website that looks native. Easy to maintain. Using appcache can help a great deal with speed but absolutely useless if you have dynamic content or something like a shopping cart (the html is also cached so you would need to touch the manifest file any time some content changed in order to spark a full reload of assets, which defeats the point, so without appending crap to the url each time you will always get served the first page you opened with that url, even if it has changed since). Mobile web has advantages of being available for every device and computer.

Hybrid: (Phonegap and WebView embedding). I found phonegap to be a bit fiddly, but it can do the same stuff as what I did just by hand so I mention it here. Depending on what you need to do can be a bit tricky to get some particular use cases working. Especially if you have remote content (HTML page itself) mixed with local content (you want to display an image that you took from the camera) in a WebView. There are ways around this (uploading assets to the web server, or loading the server generated html as a string and pointing it to local assets mixed with absolute http paths), but you are getting into making more complicated software already. Also, some things that work fine on iPhone, might not work exactly the same on Android (even with Phonegap).

Native:
Called a web service API and sent some JSON back and forth. Simple to deal with as well, and no fiddling with extreme edge cases and easy to create bundles of content, and download remote resources like images easily. I'd recommend this, but again, ,making the same app twice for android and IOS (and more if you are going with Windows Phone or Blackberry), but can leverage the full power of the device. It might seem like it has a larger barrier to entry, but it really doesn't (I got up and running with a PC, VMWare and OSX Lion which is 30euro). Outsourcing development might cost you a pretty penny though. I think this is the fastest option, but changes will be a pain if you application is in flux and is already out in the wild.

The Corinthian

I'm not sure you can really classify Phonegap as exactly hybrid.

For me a hybrid app is essentially a custom browser, with the bulk of UI rendering and business logic done online on a server. Phonegap is more correctly a programming framework, which allows one to develop an app that includes the bulk of the UI's and business logic in the finished app, rather than leaving them on a server. Certainly the dividing line between hybrid and framework can be a bit blurred at times though.

Frameworks are a fourth option worth mentioning though. The advantage to them is that they produce a 'native' app and in theory the same code can be compiled to produce versions for multiple platforms. Examples of frameworks out there include Appcelerator Titanium or Corona.

In practice I've found they have a tendency to be bulky (because they need a runtime engine bundled, as a result their final size can end up rather bloated) and sluggish (again because their code is typically interpreted at runtime). Another issue with them is they will have patchy support for native and third party API's; most notably in-app payments or Admob integration, respectively.

Finally, the 'write once, run everywhere' promise has always been more than a little optimistic (e.g. J2ME). It's certainly true for simple apps, but you will quickly find that platform specific code will have to be included once you push the boundaries even a little.

Given this, other than the cross platform advantage (and limitations notwithstanding, they do eliminate the vast bulk of platform specific development) they will often employ languages that are more readily available (such as HTML, JavaScript, PHP and so on) than those employed for native development. And so for many apps they make a lot of sense to employ.

Giblet

Sorry I meant as in implementing some of what PhoneGap tries to do on the specific platform, rather than using PhoneGap as a framework. Load a UIWebView and pass callbacks to and from the WebView to the native application. Without PhoneGap (on iPhone at least) this would simply be a UIWebView with the correct delegates hooked up to handle requests parameters, or simply pushing javascript to the UIWebView. It's still a native app, just rendering your web application in the UIWebView and using these requests to call functions in your native code. ie: Load a modal viewcontroller with an image picker sourcing from the camera.

The Corinthian

No worries. The area isn't entirely defined and even with hybrid apps there's a lot of blurring. For example consider a very simple app that allows you to search (online) for widgets, returns a list, from which you can burrow down into a details screen for a specific widget. Essentially the user would have three screens:

1. Search
2. List
3. Detail

If you did this as a hybrid app, the first screen you'd probably be better off going native, rather than serving up what is largely a static form each time (also here you could trap for lack of Internet access). The second could be Web based, but could also be implemented natively without much difficulty. The third however may well benefit from a HTML UI.

It's a hybrid app, yet much or even most of it is in reality native. Or once you start bundling assets such as images and designing the native portion of your native app to be reusable in other solutions you're already well on your to developing your own framework.

So the entire area is, in reality, quite blurred.

I do think, for the OP, frameworks were worth raising as an alternative option, but ultimately what we can all agree is that it comes down to the nature of the app (platform or platforms, complexity, type, etc) and available resources (time, budget, skills, etc) and without further input from the OP, all we can really give him is a generic 101 on the subject.

Zipppy

Hi All

Sorry for delay in replying (I've been ill )

App required will need to be cross platform and will need to access phones accessibility features (such as text to speech) and the compass and GPS etc.

App will be used to assist people with sight difficulties navigate their way about..

I know a native App can achieve this but can a hybrid ??

The Corinthian

Zipppy wrote: »

I know a native App can achieve this but can a hybrid ??

Given the responses you've received, that explain what a hybrid app is, you probably should be able to answer this yourself.

The short answer is, in theory, yes.