I spent an inordinate amount of time fighting webkit before switching all of our stuff to native. The four biggest problems, I think, with the state of webkit are:<p>1) Implicit memory management of large images/surfaces isn't reliable. There's basically nothing you can do (outside of not doing anything) to prevent your page from crashing webkit if you use too many (where too many is undefined) accelerated elements/total texture space. There's no "Running low on memory" callbacks or means to explicitly remove a recently drawn image from memory outside of removing it from the DOM and crossing your fingers.<p>2) Lack of proper prioritization in javascript. One of the things that IOS focuses on a lot is separating out user interaction on the main thread from everything else on background threads. In JS, if you're not careful and you do an innerHTML in the wrong spot, you can lock up a bunch of user interaction or delay an AJAX request that would otherwise be executing. Maybe the answer here is something like .updateInnerHTMLWithCallback(function foo(){}) to prevent breakage of JS that does expect the DOM to be consistent after an innerHTML update. (Edit: Oh I forgot, we actually did something similar to this by doing all of our innerHTML updates in setTimeout'ed functions with a 1ms delay). There's a lot of weird stuff around loading images and keeping UI responsiveness then as well.<p>3) No cache beyond pure source code between separate user sessions. One of the biggest issues for us was initial load time (parsing and calculating CSS, parsing and running JS, and blitting down accelerated DOM elements, etc). Once everything was loaded we could imitate a native-level experience, but this often would be 10-15 seconds in. Perhaps an intermediate cached file (kind of like python's pyc) would help alleviate this.<p>4) Debugging. This was covered, but ugh, what a nightmare. At a certain point I was booting up XCode instruments and tracing through webkit code to figure out what parts of our JS/CSS/etc to optimize.
This person successfully managed to trade a bunch of irritating issues for a different set of irritating issues: that generally makes one feel happier, as working around new and thereby relatively exciting irritating issues as a vacation from the worn and tired ones we are now so sick of it makes us want to die, is all many of us can hope for in life.
I am equally productive with web as well as native development so it makes no difference to me. Not surprisingly, Phonegap never appealed much - same work, inferior results, single (but dubious) benefit: cross platform.<p>I was pleasantly surprised by Titanium mobile though when I had to evaluate it at my job 2 years ago. I set to reimplement one of our (non-trivial) apps and summarize my experience. I ended up writing 50% less code and it took about the same time as what I had spent on the native version. I consider this a compliment though as I was completely new to Titanium. On the flip side I was completely new to the app when I wrote it the first time :-)<p>The build/run/debug loop was unpleasant but I've heard that it has improved since then. As for performance, it was good - Titanium generates native UI, albeit with an interpreter in the middle.<p>I was quite surprised when it turned out that I have a 99% identical app. You see, from the very beginning I decided that I'll be hard on Titanium, my goal was no-compromise, high-fidelity clone. And it worked. The only problem was positioning a tooltip near a touch point - at the time there was no way to traverse the view hierarchy. But then again, maybe I could have implemented it in a different way.<p>I realize a lot has changed since than, but this is my 2 cents - sharing a real world/product experience.
These types of apps sit solidly in an uncanny valley of application design. They appear as if they should work like a native app, and they pretty much do, but not quite. The fact that they look like a native app greatly magnifies that last missing 10%.<p>Unfortunately, this isn't just a mobile problem, as web apps get more interactive, we're hitting this problem on the wider web as well.
Same experience with phonegap + sencha touch. My personnal conclusion is that :
if you're doing "business" app (aka : where data matters much more than UI responsiveness) AND you want to release the app both for Android and iOS : go Phonegap.<p>Otherwise, and until the majority of smartphone become as powerful as the iphone4S, stay native. With ARC, developping on iOS with Obj C has become pretty much like developping with any other language (if not better).
I like this post. I'd like it if we could get studies/posts on:<p>1) A/B testing of users' responses and revenue outcomes on native vs wrapper implementations of apps<p>2) Webkit performance metrics in wrapped apps on different platforms (e.g., exactly how slow is the app on the 4S, why, and can this be mitigated?)<p>3) good approaches to interfaces that don't confuse or put off the user but are simple enough to run smoothly in Webkit<p>I'd love it if anyone could point me to enlightening information on these topics.
Funny how that exactly mirrors my experiences building a HTML5/JS app on iPad - I've quickly managed to get 90% of the app done and then wasted hours and frustrating hours of hunting WebKit performance issues, bugs without pretty much any help from tools or operating system.<p>Especially annoying are intermittent bugs that show only in certain minor iOS versions, which are hard to look for and test because of Apple no-downgrade policy on devices :\<p>Choosing native app was just a better way to keep my sanity.
Great post. Having dabbled in mobile dev (and spent lots of time in web development), I always want to leverage my existing skills rather than learn new languages/dev techniques if possible. Still, a hammer - no matter how useful - is not always the right tool for the job...<p>For all of the attention to user interface design, I find iPhone development one of the least intuitive environments going. Objective C isn't bad, but wiring up GUIs ends up being a headache. It seems to make sense if you understand what is going on behind the scenes and look at it from the perspective of dragging / dropping / connecting widgets rather than taking corresponding steps by writing code, but I have not been working with XCode for years and don't see it that way. Most other visual development environment that I has felt somehow more intuitive (some VB, other small third party UI design tools).
My suspicion, not first-hand in this case, is not that Webkit is buggy but that it’s a web browser. Browsers are not designed for embedding into applications. They are designed for wrangling a wild west of code, downloaded from untrustable origin, involving at least 3 languages (HTML, CSS, JS), and parsed at runtime.<p>It just a different use case than what PhoneGap is trying to do.<p>I don’t think it’s the wrong thing, I am quite attracted to it honestly. But we might be better off thinking of browsers as “web content displayers” than “runtime-programmable application plugin”.
We're going through the same thing right now. Built up a mobile app based on HTML/JS/CSS and bundled it inside PhoneGap and got close to done really quick... but it just doesn't feel right. So PhoneGap will be more of a StopGap until we can put more resources into a native app.
It's important to distinguish between PhoneGap's performance, and the performance of jQuery mobile or Sencha Touch, which are more responsible for the native sliding and scroll features of the non-native apps.<p>In my experience with PhoneGap, the framework does a great job of exposing native features of the iPhone, i.e. recording audio, taking pictures. The downside for me came only came when adding the visual effects to mimic a native iPhone app. Trying to fix all of the quirks with jQuery mobile, such as persistent headers and footers (although the latest RC has been looking much better), has ultimately led to my abandonment of the non-native app.
Your limits are defined by the memory size of Mobile Safari (embedded). Have you ever opened 10 tabs to see what would happen on actual apps? Now imagine full fledged JS hungry apps. Last year I warned a firm about this. Client insisted. Result - 90% was complete and the client hated the result (responsiveness & a literal boot time).
The strength of PhoneGap & Co is the ease of rapid prototype-production cycling and the flexibility in UI construction empowered by CSS3/HTML5. This guy clearly took it as "a way to avoid native framework".<p>Interesting how one can make the right choice without of knowing what he truly wants and/or the right tool for his intent.
Would it be worth doing a poll on what technologies people are using for mobile development? I've done some native Android/iPhone and now I'm jumping into HTML5. From most of the comments, I'm wondering if it's worth it.
It is important to note that the author worked on a iOS only app. If he was working on one, his devision would most porbably have been the opposite, or at least more nuanced.<p>Still, I think he made the right decision.
Another point: You have to pay to have you app reviewed on the AppStore, and it may be refused. If it is accepted, Apple will take 30% of your incomes. And your app will remain slow if it is connected to a database online.