Native vs PhoneGap apps

Eoin

Does anyone here have any experience with developing native apps and cross platform apps using PhoneGap (or similar)?

We have to produce some apps for our product, and they need to be cross platform (iOS, Android, Windows mobile).

PhoneGap would seem the obvious solution for this, but some of the comments I've seen after a bit of googling are that:

• Performance can be 3 times slower using the web pages in PhoneGap than a fully native app
  
• There's still a bit of tweaking to do for each OS (e.g. iPhones have a back button on the screen, Android have a hardware key for it etc)
  
• A PhoneGap app might mostly look like a native app, but won't feel 100% right - so if you do go down this route, you might be better off designing a UI that looks more proprietary to your product than to the OS

We probably won't have a huge amount of business logic in our apps (meaning less common code between the platforms); we want to start simple and probably just display data and use the local storage.

I'm really finding it hard to decide what route to take on this - has anyone done any similar comparisons?

srsly78

Depends on what you are trying to do. 90% of applications don't need an "app" at all, they just need a webpage. Phonegap is fine for this.

However for stuff that requires performance and interactive graphics (like games), then Phonegap is no good.

Eoin

Thanks for the quick reply!

Graphics isn't an issue - performance is. It can't feel as laggy as just browsing to our product through a pure browser. So off the top of my head, that sounds like pre-loading the screens and then populating them with local cached data first, and then refresh with live data from our cloud platform.

I should have said that we definitely need to plug in to the native functionality and actually use the phone's capabilities rather than just consider the phone as a small browser. It's important for us to be listed on the app stores, so a browser only solution is a big no-no.

Atomic Pineapple

If you have the time and can afford the extra expense then I'd recommend native development, from my research on hybrid solutions they are fine for extremely simple applications but even in simple applications can have strange behavior. Some people report they will run fine on one OS but exhibit strange behavior on the others, mostly slow response times.

If your application isn't all that complex developing it natively should be relatively simple anyway with only slight overheads.

I guess as srsly78 pointed out it really depends on what the application does.

srsly78

PhoneGap and the other cross-platform tools basically work by using html5 browser apps. Note they they DO give you access to some of the native phone functionality. Some, but not all...

As you have pointed out, browser apps aren't necessarily slow - only if they are poorly written. Caching the data etc as you suggested is the way to go.

Also the "browser app" can be packaged up into a "proper app" and sold on the app store. This is what PhoneGap does... You should try it out first to clear up your misconceptions.

Eoin

draffodx wrote: »

If you have the time and can afford the extra expense then I'd recommend native development, from my research on hybrid solutions they are fine for extremely simple applications but even in simple applications can have strange behavior. Some people report they will run fine on one OS but exhibit strange behavior on the others, mostly slow response times.

If your application isn't all that complex developing it natively should be relatively simple anyway with only slight overheads.

I guess as srsly78 pointed out it really depends on what the application does.

Thanks for that - very useful to know. If we end up having to fork code to make a wrapper app cross platform, then maybe we won't really save much effort in the long run.

That's certainly what the app development companies told us, but I'm just trying to get some independent opinions.

srsly78 wrote: »

PhoneGap and the other cross-platform tools basically work by using html5 browser apps. Note they they DO give you access to some of the native phone functionality. Some, but not all...

As you have pointed out, browser apps aren't necessarily slow - only if they are poorly written. Caching the data etc as you suggested is the way to go.

Also the "browser app" can be packaged up into a "proper app" and sold on the app store. This is what PhoneGap does... You should try it out first to clear up your misconceptions.

Yep, I did know that. I misread your post and thought you meant a fully browser based solution could be the way to go. I can see that's not what you said.

I've heard that the control that renders webpages is slow at the best of times, regardless of the coding in the pages themselves.

srsly78

And yet various vendors are always going on about how fast their javascript performance is, go figure.

The Corinthian

I've played around with a few of these multi-platform frameworks, but can't say I've really stress tested them commercially, however I have a few observations I'd make both from my own experience and the experience that others have imparted.

First of all is not all of these multi-platform frameworks are the same. Some produce little more than native wrappers to interpret your code, some apparently do compile into fully native code; a rule of thumb in this regard is probably to check the size of the app package - if 'Hello World' is a few Mb in size, then it's going to be of the former variety and thus ultimately end up being more sluggish.

Another model used is some frameworks (typically the 'easiest' to get into) are really little more than browser based apps, using content hosted remotely. They're typically so limited that I'd expect you'll rule them out quickly enough.

As an addendum to the above, many of them have changed over time, moving from the interpreter model to the native one (I think Titanium Appcelerator has or is in the process doing this), so always look at the date of any review as it may no longer be valid.

Functionality is another issue to look out for. Functionality available to a natively written app may not be available to one written using a framework; support for things such as in-app purchases or NFC can be patchy. So be sure you read the API documentation before getting stuck in and finding that what you want can't be done.

Graphic-intensive apps, such as games, are another limitation; many don't properly support that level of graphics and even when they do there can be serious performance issues. Given this there are frameworks that are specifically designed for such apps, such as Unity 3D.

Another thing that has been said to me a number of times now, is that when writing for multiple platforms, the 'write-once' approach breaks down after a while. Even between iOS and Android, there are numerous UI differences, even before you get to the API's available to each. This can lead to a bewildering number of IF-ELSE type nesting as you try to write increasingly complex code that will work on both OS's.

Overall, I'd agree with what's been said on app complexity; relatively simple apps work well enough. The more complex the app, the more problems you'll come across. The less your app needs to access the UI or device specific API's, and the more it just needs to process data in the internal business logic, the better.

Nonetheless, I would do my homework first on how the framework architecture works and what API's it supports for the various OS's before doing anything else.

srsly78 wrote: »

And yet various vendors are always going on about how fast their javascript performance is, go figure.

Yeah, got one calling me last week who tried to sell this line.

Eoin

Thanks The Corinthian, that's great info. There's no graphic type stuff involved, and we are hoping to keep it very light on the business logic side. I'm downloading the titan appcelerator studio at the moment and will see if I can make any sense of it.

Another thing that has been said to me a number of times now, is that when writing for multiple platforms, the 'write-once' approach breaks down after a while. Even between iOS and Android, there are numerous UI differences, even before you get to the API's available to each. This can lead to a bewildering number of IF-ELSE type nesting as you try to write increasingly complex code that will work on both OS's.

This is my biggest concern.

Overall, I'd agree with what's been said on app complexity; relatively simple apps work well enough. The more complex the app, the more problems you'll come across. The less your app needs to access the UI or device specific API's, and the more it just needs to process data in the internal business logic, the better.

I think it's going to be the opposite. Interaction with the phone and not much processing. Just relatively simple CRUD operations with our cloud platform.

The Corinthian

Eoin wrote: »

This is my biggest concern.

I would be tempted to say that such issues occur because the code architecture wasn't properly planned in advance. Modularizing UI or device functionality code into a separate class or object, for example, would be what would pop into my mind to deal with it.

Given this, I've worked with a few of these frameworks, but not in any great depth, so I can't say if this would work - I'd research it, if I were you, and see what other developers who are expert in them would suggest.

Eoin

Yep, I think that's a fair point. Though if the UI layer is quite unique to each OS, then the question is why not go native if there's not much business logic to share across the platforms!

Anyway, lots of questions to research, but thanks very much for all the input.

srsly78

They all have buttons and tab controls and the usual stuff, there is a lot of commonality. Only more advanced stuff starts to run into differences.

Eoin

Yep, it's just finding the tipping point I suppose. One difference that springs to mind is that Androids have a physical back button; where as iOS uses on on-screen one. I guess it's just a matter of identifying these areas and taking it from there.

The Corinthian

Eoin wrote: »

Yep, I think that's a fair point. Though if the UI layer is quite unique to each OS, then the question is why not go native if there's not much business logic to share across the platforms!

Developer resources. Going native for iOS and Android means a competency in both Obj-C and Java (add WP7/8 or RIM and you've got even more languages to master). With any of these frameworks, you'll just have to be competent at the one language be it JavaScript or whatever.

Developers who are competent or proficient in more than one language cost more than those who are competent or proficient in only one (thus one expensive developer or two cheaper ones will be required). Taken further, one can also suggest that JavaScript or PHP (common framework languages) developers will also cost less than Java or Obj-C developers in general.

Sometimes even if something does not make that much sense on a technical level, it can on a financial one.

srsly78 wrote: »

They all have buttons and tab controls and the usual stuff, there is a lot of commonality. Only more advanced stuff starts to run into differences.

You run into issues pretty quickly, TBH. Back buttons, for example?

Edit: Eoin beat me to it with back buttons

srsly78

I haven't actually tried these cross platform thingies so I am just guessing based on what mates have told me...

But I would imagine that the back button is such a basic requirement (used in ALL android apps) that the framework would expose some way of handling it gracefully. If not then I would instantly ragequit and start posting about how useless they are

i71jskz5xu42pb

I don't think your decision is difficult enough so I'll add another variable: finding people to do/maintain the work.

The HTML5 based frameworks: HTML/CSS/JavaScript - lot's of people at least familiar with the technologies.
Android: Java + the Android framework - again there seems to be a fair amount of people working on it as it is easy to get into (no Mac/Dev centre reg required)
iOS: Objective C - really hard to find quality developers.

(Just saw The Corinthian raised this already, so I second it)

Freddio

I started with phonegap, moved on to appcelerator and progressed to native android and iOS.

You really cant beat the native experience with cross platform and if cost and multiple os is your benchmark, you might as well just create a mobile website.

Also most of these cross platform binaries send userdata back to the mothership (not yours)

Eoin

Interesting - good to get that sort of insight.

cost and multiple os is your benchmark

They're just two of many factors - PMan and The Corinthian have touched on another important one.

We already have a mobile-web version of our product. We specifically want an app (possibly a few down the road) that does a few things really well, rather than the wide but shallow functionality of what we have at the moment. Not sure if the powers that be would be happy with just wrapping it in a shell app.

I don't think your decision is difficult enough so I'll add another variable: finding people to do/maintain the work.

Also most of these cross platform binaries send userdata back to the mothership (not yours)

Really? That won't go down well! I'll have to read up on that.

The Corinthian

Freddio wrote: »

Also most of these cross platform binaries send userdata back to the mothership (not yours)

Really? Do you have links to articles discussing this?