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

[Kerri Shotts]

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:

PhoneGap Version: https://github.com/photokandyStudios/GreekInterlinearBible

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. ;-)

[Giacomo Balli]

there is no "one" tool to make something.
You always need to assess what is the best technology depending on
what needs to be accomplished.
I would never say I'm abandoning something just because it was not
ideal for one project.

In addition, every tool is at most as good as the person using.Perhaps
there could have been something to improve your code...

Just my to cents...

>    - 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...

[Sam]

Thanks for sharing your experience ! Yes I agree with you, you can loose a lot of time if you want to emulate the native feeling and UI components. But, IMHO, if you want to support several plateforms, phonegap is the way to go. In addition, you can easily have your own UI design with CSS. You don't have to have a native look to sucess.

[seasp...@gmail.com]

On Mon, Apr 2, 2012 at 10:41 PM, Kerri Shotts <kerri...@gmail.com> wrote:

• Objective C and UIKit and Foundation, etc., are actually quite easy. You can get a lot accomplished with a few lines of code.

Thanks a lot for the insights. I'm curious to know where you were starting from when learning Obj-C? What languages did you already know and how long until you became productive in Obj-C?

--
You received this message because you are subscribed to the Google
Groups "phonegap" group.
To post to this group, send email to phon...@googlegroups.com
To unsubscribe from this group, send email to
phonegap+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/phonegap?hl=en?hl=en
 
For more info on PhoneGap or to download the code go to www.phonegap.com

--

Learn Bird Songs, Support Conservation: http://www.larkwire.com

Bikewise: http://www.bikewise.org

[Kerri Shotts]

Phil,

My programming background is quite varied: I've been at this for 20 years, give or take, since I was a kid. Started with BASIC (Commodore, no less. Ack!), and worked out from there. Languages I've had experience with include Pascal, C, C#, VB (Unfortunately), PHP, PL/SQL, and Javascript, along with some other minor excursions into various other languages. I've been working in PHP and Javascript the longest, simply due their proximity to web development. What that ultimately means is that my sense of syntax and grammar is already very C-like, so I would mark that up as being a large help. [Though I still get trapped by the spurious "var" in obj-c, when it should be "int" or something similar.]

Probably the biggest thing that helped me wrap my mind around Objective C was something I read somewhere, and I wish I could remember where... but it boiled down to saying that Objective C is a marriage between C and Smalltalk. I've had enough experience with smalltalk (back in my college days) so that helped cement the underpinnings of ObjC's idea of objects, which is both similar and disimilar to a good portion of the languages I'd previously worked with. In reality the only difficulty in picking up the /language/ of Objective C was getting used to bracket notation when sending messages to objects instead of dot notation (which is reserved only for property accessors). Given that I might write "object.doThis()" in JS, the same would be written "[object doThis]" in ObjC. The next biggest thing was in getting over how parameters were handled. While it is great for readability, it does tend to get verbose. In away, ObjC's methods are more akin to methods with named parameters that are required than they are to regular parameter passing (where it is done by position). For example, in JS I might write a function declaration as "function doThis (a, b, c)", in ObjC, I'd do "doThis: (type) a withB: (type) b withC: (type) c". Not that you can't do the other in ObjC, just that it's the preferred convention.

Of course, being a C-based language means that all the C notation is there too: you declare a string as "NSString *", and you pass variables by reference using "&" [when appropriate]. You also have to deal with primitives not being boxed automatically, so an "int" isn't always something you can use without converting it to an NSNumber. Or vice versa. Further, given C's proclivity towards type casting, you also see this quite often in Obj-C. Consider that all objects are of type "id", you often will see something along the lines of this: "(MyViewController *)[subviews objectAtIndex:1]" whereby I'm taking an object from the subviews array (which contains any object, but typed to ID), and then I'm typecasting it to the type I need.

Becoming productive in the /language/ was pretty quick. It really is a matter of understanding the grammer and syntax, and then getting used to the differences. What took longer, I think, was the concept of how the libraries worked to build the user interface. I've written programs for both Windows and Windows Mobile (when it was CE), and so I had a pretty firm grasp of how Windows constructed its UI. Apple does things entirely differently when it comes to iOS, and I had to unlearn my personal concepts of how UIs really did work. Getting used to the view hierarchy really was the hardest thing for me to do, and I won't vouch that I'm there 100% yet. 

This wasn't helped by going the "Apple Way" and jumping into storyboards immediately, either. I think they are great for mocking up a UI quickly, and even including a good deal of interaction. For simple apps, it could probably work quite well. But to me, there was too much magic going on. The same tended to apply to Interface Builder when desigining forms and such visually. Yes, great, visual design for a visual user interface, but I don't know... I've always preferred my UIs in code. Perhaps because of the flexibility, the lack of magic, and/or this is the way I'd always done things. ;-) So once I dropped going with StoryBoards and Interface Builder, I was a lot happier and much more productive. I bought various books and looked at lots of sites (http://www.raywenderlich.com/ is a good one), and then got busy coding. After a couple misfires, the code that started to come out started making sense and actually working!

Consider this: the little objective C I /did/ know came from peering inside Phonegap and its plugins. Put that around January/February of this year. Now, by early March, with less than a month of intensive coding, I've got just over 5k lines of ObjC. Granted, to compare line count with performance, proficiency, efficiency, etc., is a fallacy, but it does indicate that there's plenty of stuff going on inside. Is the code excellent? No. Are there better ways of doing things? No doubt. Does it /work/? Yes. Is it working better than the non-native method? So far, /yes/. I don't want to think about how much of my non-native code was working around a webkit glitch, or was a tweak to get a little closer to native look & feel (lots), whereas here, the code is all doing app-specific work: loading data, displaying it, taking it from the user, etc. 

That I'm probably a couple weeks away from feature parity doesn't necessarily indicate the effectiveness of ObjC as a language, or UIKit as a framework: a lot of this stuff I'd already developed for the non-native app. If anything, I could consider that non-native app a good mockup. The majority of the concepts can be used directly, and it's really just a rewriting of code. Along the way some changes were made, obviously, as would occur in any rewrite, but the concepts were already in place. Without those concepts in place, I'm unsure how long it would have taken to get here. 

Okay, that's a long-winded answer, so the TL;DR of it is this: languages previously known: C#, C, PHP, VB, PL/SQL, BASIC, PASCAL, dabs of SmallTalk. Time from start to productivity: <3mo. [This is really closer to ~1.5mo, TBH, if you don't count my first failed attempt at storyboards. But it was part of the learning process...]

Further, let me state that I rather like most of the languages I know, so I'm not attempting to state that ObjC is an easier language, or that UIKit is necessarily a better framework than any other UI framework. Half the difficulty with the non-native solution was the lack of a good debugger that you could use while doing on-device work [And weinre is /great/, btw. But it's not a fully-fledged debugger yet.], and the other half was working around webkit's glitchiness. [Case in point: implementing native scrolling. Should be easy, right? Wrong. Scroll feels great, but then you'd find out that text wasn't rendering correctly. Fix? Add webkit-transform:3d-translate(0,0,0). Why the flip did that work? These are things that are less about fixing bugs in your actual app, and more about trying to get webkit to work the way it /should/ all on its own. Or stopping the bounce effect. Typical solution: stop the default event action via javascript. Turns out that nukes other things that you /might/ want in your app. Then you have to rebuild them. Turns out its easier to use some ObjC to turn it off. *sigh*]

And just to drag this out a little longer, I don't mean to say that PG and/or non-native development never has its place. Just that it wasn't working out for me with this particular app. Had it been a different app, things probably would have gone differently. What is the right tools for this app (native Obj C) may not be the right tools next time. 

Hope that made some sense!

On Tuesday, April 3, 2012 3:07:24 PM UTC-5, Phil Mitchell wrote:

On Mon, Apr 2, 2012 at 10:41 PM, Kerri Shotts <kerri...@gmail.com> wrote:

• Objective C and UIKit and Foundation, etc., are actually quite easy. You can get a lot accomplished with a few lines of code.

Thanks a lot for the insights. I'm curious to know where you were starting from when learning Obj-C? What languages did you already know and how long until you became productive in Obj-C?

--

You received this message because you are subscribed to the Google
Groups "phonegap" group.
To post to this group, send email to phon...@googlegroups.com
To unsubscribe from this group, send email to

phonegap+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/phonegap?hl=en?hl=en
 
For more info on PhoneGap or to download the code go to www.phonegap.com

[Kerri Shotts]

Of course, nor am I trying to indicate that one tool fits all. It doesn't. Never will. That's why I use a /lot/ of languages ranging from C to PHP to PL/SQL. I use what I think will work best for the situation. Obviously that doesn't always work out, as I initially believed (and my initial tests seemed to indicate) that html/js/css would do the job for this app. 

And actually, I think they would be a perfectly fine tool. It wasn't so much the language, it was the platform - that is, mobile webkit that got in the way one too many times. I perhaps should have retitled the post to Mobile Webkit vs. Native development, since this isn't PhoneGap's fault. It just provides the interface from webkit to some other native device features. 

My frustration largely stemmed from having to debug what felt like a webkit issue vs. debugging my own code. First off, debugging is a pain in the rear anyway, and it is worse when there is no proper debugger for the platform. You can only go so far by developing in Chrome or Safari, and then using the iOS Simulator + Safari. After that, issues become issues /on the device/, and while Weinre is great, it's not a fully-fledged debugger yet. Oh, for the day it is, because then one of my primary complaints goes away. But until then, my point stands. And when the issues show up only /on device/, you're left with being unable to debug in a proper environment. Oft times I was reduced to console.log(). People, this is the way we used to debug 20, 30, 40 years ago. 

If we discount debugging, the next big frustration was webkit. I /love/ it. Don't get me wrong. I use Chrome on my desktop (webkit). I use Mobile Safari on my iPad and iPhone (webkit). I /convert/ people to Chrome whenever I have a chance. I /love/ it as a browser, and as a platform. But when it translates to a touch environment on a mobile device, mobile safari has a long way to go. Let's see a few of my issues:

• For a long time, the only scrolling solution was a js library like iScroll. Performance sucked when you got beyond a non-trivial amount of elements. In fact, it sucked so much, that I gave up. First, I converted my most element-heavy page to canvas, and then, I dropped iScroll entirely.
• Native Scrolling stinks too. I mean seriously, Apple, why in the world do you have to bounce my entire UI? The typical fix is to stop the browser's default behavior. Which breaks other things -- like simply selecting text! Ack! And then you re-implement those things, only to discover that suddenly (for no good reason, and inconsistently across the board), pages will scroll, but /not/ paint their contents to the browser window. WTF? The fix? Adding a 3D Translation of (0,0,0) to the element. Now tell me, /why/ in the /world/ does that fix the problem?
• Touch delays. Yipes, we shouldn't have to write funky code just to handle touches that are supposed to be "clicks" instantly. And then we end up having to write more special code to filter out those touches that get doubled up, causing all sorts of havoc either way you deal with it. You can ignore them, but then that hurts the responsiveness of the UI.
• Animation performance. Yes, the hint is to use the CSS transforms whenever possible. And that's fine. What gets me is whenever the element being animated is suddenly non-trivial (and has dimensions over a certain size) then performance goes down the drain. I get we have limited memory. Was /tiling/ the textures to the GPU /really/ the best way around it? It screws with the fluidity of the interface in a bad way. Or, say, a simple fly-out leaving funky trails of itself behind during the animation. What a horrible user experience that is. 
• Webkit repainting is not always predictable. In fact, for a while I had to go to a fix I found somewhere that essentially added a style to the page just to force webkit to redraw itself. First, I shouldn't even have to do that. Second, why in the world was adding a nonsensical style (it really did do NOTHING) the fix? Third, I shouldn't have to do that! I felt like I was back in the 90s building my own personal UIs. Even then I had repainting down. It's /not/ that hard!

I could go on and on, but seriously, it quickly became a feeling of debugging webkit vs. debugging my app. Honestly, I'm not doing anything in my code, my stylesheets, or my html, that is that hard. Regular Safari handles it just fine, and that's perhaps the only hope that mobile webkit will improve in future versions of iOS. But when I'm feeling like I'm debugging the very platform I'm running on vs. debugging my own code, productivity goes down the drain, and I'm forced to consider other options. 

It is true that the tools can only be as good as the person using them. This adage holds true in all walks of life. That said, I'm a pretty good programmer. I've been doing it for 20+ years. I've worked most of my adult life in programming positions creating successful applications for the companies I've worked at. Am I the /best/ programmer? No, by all means, no. Do I write hacks sometimes? Yes. Most programmers do at some point. Show me something /in production/ for a few years that hasn't become hacky over time. There's always an incredibly horrible exception to the rule, something most college courses and language purists like to ignore. Would I love to write pure, beautiful code all the time? Sure, but you may as well toss productivity down the drain, 'cause it just ain't happenin' in real life. Something always comes along to throw it out the window.

Could different code have alleviated my issues with performance? Maybe. Actually the majority of performance was quite good. In fact, the one place that should have been slow as molasses /wasn't/ (canvas). The final straw became a ridiculous 5s delay (sometimes - like I said, this was inconsistent at best) between selecting a /list element/ in a simple unordered list (and I do mean /simple/) and the display of the next list in the hierarchy. There was nothing in my code there causing such a delay. Of course I couldn't reproduce it in a full debugger either, since there is no full debugging on the device. So /maybe/ there was code somewhere getting run taking up all the time. There is simply no way to know at the moment. But something was getting in the way, it was inconsistent at best, and the feeling was: oh no, not /another/ webkit problem to work around. When that was the feeling, I decided it best to start over in an environment where, at least, I could debug properly if any performance issues came up. In fact, they did. (They /always/ do.) But this time I could use the debugging tools at my disposal and pinpoint the problem precisely. Oh, if only I could have done that non-natively.

[Kerri Shotts]

Yes, for cross platform support, nothing comes close. But at the same time, I do feel it important to closely emulate the platform you're running on -- that is, if you're on iOS, use iOS conventions. If you're on Android, use Android conventions. Anything less is disconcerting for the user. (Though, perhaps, only iOS users will thumb their nose at it? ;-) )

I'll agree that you don't have to have a native look & feel to be successful either. Games are a great example of that. But my app really did need to look and feel native -- the content here was the more important thing -- the UI should just /blend in/, be /immediately understandable/ by the end-user, which meant it needed to act the way a typical Apple app reacted. And that means emulating native look & feel. I do think I got really close - about as close as possible without going insane and trying to be pixel-perfect. Ultimately it was less the UI that got me, and I think, more webkit's issues with handling it that did. With no proper support for debugging on-device where the problems occurred, it was impossible to fully figure out where the problems actually were. It was starting to feel like a webkit issue, simply due to this fact: the replacement I wrote to be /faster/ was -- and wasn't. Super fast on the iPad. Dead-slow on the iPhone. What's up with that? The two devices had comparable power (iphone 4 vs ipad 1). Why was webkit acting so differently on the two devices? I don't know... and may never know, though my brain does want to figure it out... just after I finish the native version that doesn't have to worry about it. 

[Devgeeks]

I think Android users would thumb their nose at a UI that looked like a ported iPhone UI.

I would if I was one of them :)

[Alper Çuğun]

On Tuesday, 3 April 2012 07:41:17 UTC+2, Kerri Shotts wrote:

I was /this close/ to being finished with the PhoneGap version. It was 99% done. Almost ready to go. And then... *pow*...

I hade the same on my current project but I had it after 5% in. It may not be Phonegap that was the issue, but I had half second freezes on event handlers for buttons in mobile safari and that was having only created a handful of very basic screens. I did a bunch of micro-benchmarks to see where the issues was, but being so fresh into the project, I thought I might as well switch to native development instead of wasting time polishing it and it slowing down on me in other places.

Especially with ARC and Storyboards developing iOS is not quite as easy as Javascript, but not much more difficult either.

-- 

Alper

[DanN]

"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."

From my recent experience I can say that performance issues are dependent on what javascript framework you use. I have tested many of them: I created a list with 100+ items and done some operations (scroll, add new element, delete,...). These tests were done on one of the slowest Android devices. I ended up using JQmobi http://www.jqmobi.com

For now, I will continue developing my project using PhoneGap. If I switch my mind I will surely share my experience :)

@DanNegrea

[Dave Sims]

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:

[Dave Sims]

Completely agree here. I've finally pared it down to nothing but Zepto unless I really really need something else. Even just getting away from core JQuery makes a big difference.

[Joe]

I'm with Dave Sims on the not using one of the mobile frameworks, especially on iOS. I'll concede I use jQuery, not Zepto, though. If you're concerned about page transitions being shaky or flickering or something like that, just use translate3d to do all your moving things around and the GPU will kick in and everything gets nice and silky smooth. Can't wait til I can do that on Android, but 2.2 and 2.3 are still like 90% of the market.

One other thing I came across happened with a project I'm in the middle of writing right now. It has about 30 screens and when the app started it took like 15 seconds for the index file and all the js to load. I think this actually has to do with css being applied to all that HTML, but to be honest I really don't know. The fix was to break out all the screens into their own html files and *only* use a script tag for cordova.js file. When device ready fires, load in the js and html. It starts up in about a second now. You have to do some extra work to make sure your javascript has loaded, but it's way faster. Also saw a performance boost by swapping out background images with solid colors. And it became easier on my eyes....

The worst part for me is dev environment, especially Eclipse. Is there a better one around for Android? 

[Joe]

Did you try using ontouchstart instead of onclick?