Google Groups

Re: [thoughts/IOS] PhoneGap vs. Native: Some Thoughts on Going Native


Dave Sims Apr 17, 2012 7:47 PM
Posted in group: phonegap
Kerri, I could have posted this nearly word-for-word. Just finished porting my company's Android app from PG to native. I second your remarks that this is not an issue with PhoneGap. It's WebKit and rendering and choppiness and the heaviness of all the JS libraries, JQMobile, Sencha, even just JQuery or Zepto, the overall feel and performance of the UI just isn't there, doesn't feel like a premium app.

So I'm just chiming in to say I'm glad to see someone back up my experience, against all the noise of so many saying how HTML5 is the future and it doesn't make sense to write two native codebases, etc. I agree HTML5 is the future,  it's just not the present, at least not for apps where UI/UX directly affects things like purchases and the bottom line (like ours really, really does). I do use WebViews with Zepto for targeted places where it makes sense, like detail views and other specific areas where I can re-use some of the mobile site's styling. Just not as the main structure of the app.

Again, no knock on PG, it's a fantastic framework, and I've recommended it recently. There's a lot of domains and contexts where it's a great solution.

Thanks,
Dave

On Tuesday, April 3, 2012 12:41:17 AM UTC-5, Kerri Shotts wrote:
First off, I just wanted to say what a fantastic community this is, and what a great thing PhoneGap is. That said, I wanted to share some of my thoughts about developing an app for iOS using PG vs. going the native route. Keep in mind that this isn't a knock on PhoneGap -- it's more a knock on mobile webkit development than anything, but I did want to get this out there in case anyone else is feeling similarly.

The projects to which I am referring are below:
Native Version: https://github.com/photokandyStudios/gbible [Yes, the organization in the folder structure is horrible. Load it up in XCode for a legitimately organized view...]

I was /this close/ to being finished with the PhoneGap version. It was 99% done. Almost ready to go. And then... *pow*... performance issues that weren't related to anything that I could find: it seemed some combination of CSS/HTML/JavaScript was getting in the way. Did some rework to attempt to fix, and on the iPad, it made it better, while on the iPhone it made it worse. (No consistency.) The delay was so much that I considered it unacceptable. I worked to find what was causing the issue, only to come to the conclusion that it was webkit's rendering slowing things down, and there was suddenly little I could do about that and maintain a good, native look & feel. And then the other niggles popped up: controls that looked good, but not quite great; controls that responded almost natively, but not quite; and more. Nothing terribly serious, mind you, but something that very indicated that the app was not really native. Again, none of this is a knock on PhoneGap. If anything it's a knock partly on Mobile Webkit and it's glitchiness/performance issues and my patience with dealing with it.

So I decided to tinker natively and to see what I could come up with. Surprisingly, after a few rough starts (especially when trying to wrap my head around storyboards), I realized that this was /so much easier/ than trying to shoehorn my html, js, and css into a native look & feel. After all, you get native look & feel for /free/ natively (obviously), but I've suddenly realized how important that is. I went through lots of tweaking on my UI (and its all important, and will have future uses, so I'm not abandoning the /concept/) to get it close, but there are just some things that I don't think one can ever /totally/ duplicate. [Okay, yes, you probably can. But it would be a ridiculous amount of work, and likely not nearly as performant.] 

Now, I could probably have done something very similar by creating plugins that would do some native controls in phonegap -- and I did consider that. I considered creating tableviews and other controls that could live atop the webview, and then suddenly decided that if I was going to have to go to all that work, I may as well do the whole thing natively. Tableviews naturally fit my data model, and at that point, a very large portion of the code would be handled natively /anyway/.

I could also have gone the route of Nimbus/Appcelerator/etc. But in each there was something missing that I would need, and the more I drilled down into them, it quickly became apparent that if I was going to have to live in Apple's world, I may as well live in objective C/UIKit/etc. as well, rather than always going through someone else's wrapper around it.

And so here we are: I've got a project that (so far) is going quite well natively, and while there isn't feature parity yet (far from it!), I'm already feeling like I've made more progress than I did getting from 98% to 99% on the webapp. Why? Here's a few reasons:

  • I'm not having to continually come up with a workaround for some silly webkit bug, glitch, or quirk. Believe me, this was quickly becoming the largest time consumer at the end.
  • I'm not having to generate the native UI elements /and/ make them feel native. They just /are/.
  • Objective C and UIKit and Foundation, etc., are actually quite easy. You can get a lot accomplished with a few lines of code. [Nothing against JS here. I like the language.] Plus, there's a lot of sharing going on out there, from components and controls to code snippets that really help. [Note that html/js/css doesn't have the same thing, but it's not /quite/ the same. Hard to explain.]
  • I can really, truly /debug/ on this now! That was perhaps the second most frustrating part (aside from webkit getting in the way): no true debugging. Yes, you could develop in a desktop browser for most functionality, and then you could use the iOS simulator and Safari to debug, but to debug /on/ the device was a pain. Weinre is a good solution, but it's not /quite/ there (no breakpoints!). I can't say how /nice/ it is to truly debug without having to drop in console.log() every few lines just to see if JS got there or not.
  • Drop-dead easy gesture recognition. In comparison, the equivalent code to recognize a swipe gesture in JS is nuts.
  • Lighter memory footprint. Of course, this just happens mainly by not having to load a webview, a javscript engine, etc. 
Does native development have its issues? Yes - lots:
  • XCode gets twitchy about what it decides to compile and deploy. Sometimes it picks up a newly added file and does the right thing, and other times you have to tell it what to do. I swear, if I add a .h/.m file to the project, wouldn't you think XCode could figure out that I wanted it /compiled/? Yes, it does this most of the time, but every once in a while it decides not to, and you get some unfriendly linker error complaining about missing references. Oi vey!
  • XCode likes to crash. Even on my loaded iMac that has lots of memory and space. Needless to say, saving frequently is a really good idea.
  • UIKit does some very funny things. I mean why in the world is the background color of a table cell decided at one point, when the /content/ of that same cell is decided at another point? And heaven help you if you do it in the wrong place -- chances are you wont' get an error -- just that it won't work as you expected.
  • /Customization/ of the native elements isn't as straight-forward as I would like. Apparently Apple's made great strides here, since before iOS 5 you would have to subclass almost anything to customize its appearance, but still. Further, some customizations are still out-of-reach without subclassing and drawRect:.
  • Table View rendering takes a lot of thought to get right, and I won't even say I'm 100% there /yet/. Mainly because if you do much of /anything/ when creating a cell, scrolling becomes herky-jerky. That means you essentially have to do the work up-front so that you can quickly load the contents of a cell rather than calculate them on demand. Or get into Grand Central Dispatch or something similar to put part of the processing outside of the main run loop. Whatever, my hat is off to anyone who can make a beautiful, data-heavy table view in iOS that scrolls like butter.
  • The view hierarchy is both amazing and a bit nuts. I've programmed for Windows and Windows CE before, and goodness knows, it's nothing like that. I've had to unlearn quite a lot of my notions about how UIs work underneath.
  • Interface Builder/Storyboarding is too much magic for my tastes. /Especially/ storyboarding. It's great for getting a prototype UI down, but then just /try/ and do something simple like dismiss a popover. For some nutty reason, you had to go to (what I considered) extreme lengths just to do so. So I built my UI all from code. I can work with /that/. ;-)
  • And plenty more...
And even with all those quirks, I'm still happier with what I've got natively than with what I got with html, js, and css. Oh it looked nice enough. It functioned /almost/ natively. But look too close and you could spot the glitches -- like switches that you couldn't slide, or small differences in how shadows rendered, and scrolling -- don't get me started on scrolling! And then the performance issues that occur for no good reason on a simple list where in you could spend five seconds just /waiting/ for something /simple/ to happen. And there was no JS code running during that time -- it was pure webkit.

Anyway, enough of a ramble. I'm not abandoning phonegap -- no, I think it has a lot of potential. Nor am I abandoning the concept of a native-feeling web-based UI -- just that I was overloading webkit in this particular app. I fully plan on using the things I've learned in building mobile sites that act like apps, and I also plan on working on some phonegap plugins, especially now that I'm getting a much firmer grasp on Objective C and the Apple Way. But this is one app where I think native is the better choice, and so far, I'm feeling much better having gone native. Oh well, live and learn, right? C'est la vie!

So, I just wanted to share that and show a comparison between the two paradigms, including some code. Now, questions, comments, etc? I'm sure someone has something to say about all this. ;-)