PhoneGap vs. Native: Some Thoughts on Going Native
groups.google.com
groups.google.com
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.
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.
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.
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.
Any links to more detail?
So yes he has made a trade. I think a good one, but to each his own !
The day you realize that what version of Xcode you were using when you compiled the application (in addition to the version of the firmware installed on the device) affects the behavior of UI classes on deployed units, and that these effects are not documented (and are in some cases /insane/) is the day you realize that no: it is just different.
To describe this another way: yes... Apple seriously implemented a kind of "quirks mode" (I believe that is the most fair, accurate, and descriptive term to use to describe it, by analogy to web browsers) in the UIKit framework on the device; they will change the behavior of the library slightly, and then do runtime checks to determine "could you have known that we did that".
To be clear: this is not due to compiler bugs; they do it with a runtime function called UIApplicationLinkedOnOrAfter() (to be clear: which looks at the date of the UIKit library used, not the date of the link). I discovered this after spending an incomprehensible amount of time attempting to debug a serious UI issue that only occurred when /some/ of the developers working on my project compiled it: I sat around disassembling and tracing and then... "woah".
The places where I have seen this stuff used, while attempting to maintain an application not over the course of a few months but over the course of now over four years, has been sufficiently "wtf" that on iOS 4.1 I finally wrote a tool that disassembled UIKit, found all of the calls to that function, and attempted to document "for what version it is being compared".
(I intended to at some point even write a detailed blog post about this, with examples, and a chart of all of the usages, but I've never had time. I really wish I had more time to sit around writing blog posts, but the really good ones of those take days to put together, if not even longer ;P.)
In contrast, the stupid WebKit bugs in or changes to iframes and multi-touch that seem to get traded around in every version of iOS are actually tame in comparison: they simply have not caused the kind of debugging hell and frustration that the simpler native components have caused. I have only once been "I upgraded to the latest version of iOS and all of my content disappeared" with HTML (iframes with height=0 stopped auto-sizing: changed to height=1: irritating as now an iframe cannot autosize so small as to disappear), but it has happened four or five times with my native code.
So there: just another set of anecdote to throw in the pile of "irritating garbage" and "debugging hell" that people like to throw around about everything they do. Personally, I find that I'm happiest when I switch back/forth between doing Objective-C, HTML, Python (server), and assembly (reversing) a lot, so that no specific one set of irritating problems ever becomes so depressing that I throw up my arms and quit (which has totally happened a few times).
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 :-)
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.
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.
I realize a lot has changed since than, but this is my 2 cents - sharing a real world/product experience.
12 months later, the SDK has improved, and documentation has improved. I circled round to Titanium again. Now I've got an app in my spare time that's pretty close to store submission, not leaking, not crashing, all native. I'd find it very hard to go past Titanium now. Once you get into a groove with the CommonJS style (https://wiki.appcelerator.org/display/guides/CommonJS+Module...) of constructing your app, and follow some of the latest examples, it all clicks into place.
I haven't tried to learn Objective-c (Rails/Javascript guy) however if you're not building a game, or trying to get 10/10ths out of a native app, I think it's damn good solution.
Any other got'chas or suggestions beyond getting a firm grasp of the CommonJS style?
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.
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).
It's not a question that can be answered without additional context, but thoughts on various approaches for this situation would be helpful and appreciated.
1) A/B testing of users' responses and revenue outcomes on native vs wrapper implementations of apps
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?)
3) good approaches to interfaces that don't confuse or put off the user but are simple enough to run smoothly in Webkit
I'd love it if anyone could point me to enlightening information on these topics.
I'm working on a fast testing framework for native iOS apps. I posted some early design specs at appgrok.com. There's also clutch.io, which supports iOS app iterations (things similar to A/B testing) using a hybrid approach, if I understand it correctly.
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 :\
Choosing native app was just a better way to keep my sanity.
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).
It seems like there are two ways of approaching GUI/language development:
1) Apples way: Keep building on a base language (C). Add new features (Object orientation, XML rather than proprietary configuration, Code Generators). Maintain backwards compatibility (your old devs will be wowed by each new release's automations and syntax improvements. New devs that have not been part of your programming tradition will require greater up front study time to grok the process).
2) Microsoft's approach: Make visual development "primary" (closer to the way one uses a GUI rather than builds it). Ignore underlying language constructs and best practices (e.g. make everything global).
Having worked with Microsoft, I thought that Apple (especially with their attention to UI design) would give developers a more intuitive interface. Perhaps it is intuitive to those who can build GUIs in code, but it was not to me. This is in stark contrast to Microsoft, where someone who knows very little about programming can create a usable GUI (and get themselves in trouble quickly as well). Don't get me wrong, I am not a Microsoft fan and spend little time in that world. However, I was able to jump in on several projects and be productive with very little ramp up time. Apple development required a greater investment of time and energy up front to be productive. Enough that I have considered PhoneGap and other tools as alternatives for subsequent development.
It just a different use case than what PhoneGap is trying to do.
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”.
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.
Interesting how one can make the right choice without of knowing what he truly wants and/or the right tool for his intent.
Still, I think he made the right decision.
I've sold so many items that would otherwise live forever in a closet because they'd be too hard to find a local buyer. The number of eyeballs looking at eBay makes the place a huge net win.
But, App Store is a very good thing for developers. You can make a Chess game both with ObjC and HTML5, but chances of someone finding your HTML5 app via Google (search) is practically zero. On the other hand, because there are less than 150 Chess games for iPhone, if a random surfer searches the App Store for 'chess', they see your icon down the list. That's the exposure I'm talking about.
And again, I don't like Apple's rules very much, I'm just stating that being on the App Store brings you a lot of exposure.