

PhoneGap vs. Native: Some Thoughts on Going Native - alifaziz
https://groups.google.com/forum/#!topic/phonegap/BFyBYjQp3a8

======
newhouseb
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:

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.

~~~
icebraining
I'm not a mobile webdev, but about (2), did you try using Webworkers for the
background tasks? iOS Safari supports it nowadays, right?

~~~
freddywang
Web workers doesn't really work. Somehow, It still blocks the main UI thread.

~~~
ef4
That's a bummer. I was planning to rely on them soon.

Any links to more detail?

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

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.

~~~
RowanH
Titanium has come a long well, I eval'd it around 18months ago and was
frustrated with 'how the heck do I build something that doesn't leak'. I was
amazed at how quick I got something running, until it crashed... I hugely
struggled with the best way to build an app.

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...](https://wiki.appcelerator.org/display/guides/CommonJS+Modules+in+Titanium))
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.

~~~
Kiro
I disagree with the "if you're building a game" part. I build games in
JavaScript/HTML5 for iPhone/Android, package them to apps using appMobi and it
works pretty good. I haven't tried PhoneGap though but I guess it's more or
less the same thing.

~~~
RowanH
Sorry I should preface it with 'if you're building a game to squeeze all
resources out of a system'. As obviously there is a (pretty small) overhead
with running the interpreter..

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

~~~
Arcanum-XIII
It's not exactly like that — there will always be issue, we know it, but some
are more irritating than other. I can handle Xcode crashing, and needing some
help to compile everything — I can live with that. The debugging part
otherwise, is subpar. It's (at least for me), a true hell. Appcelerator was
the king of unusable error for example, that and a lack of GOOD (heck, even
complete) doc were driving me mad.

So yes he has made a trade. I think a good one, but to each his own !

~~~
saurik
Context: I have been doing iOS app development, both native and with massive
amounts of mixed in HTML (using a home-grown mechanism similar to, though I
will personally claim nearly infinitely better than, PhoneGap) since early
2008 (yes: half a year before the SDK existed).

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

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

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.

------
creamyhorror
I like this post. I'd like it if we could get studies/posts on:

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.

~~~
tylerneylon
For A/B testing:

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.

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

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

~~~
creamyhorror
What if you've already developed a (simple) Android app for consumers, and you
want to enter the iOS sphere as well, but you don't have an iOS dev on the
(completely bootstrapped) team? Would it be worth investing one team member's
time to learn iOS development, or outsource the creation and simultaneously
learn to maintain/extend the code, or to simply go with PhoneGap despite the
performance drawbacks?

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.

~~~
mattront
In my experience it is worthwhile to learn native iOS development. Once you
setup the environment and get used to XCode it is kind of fun and it doesn't
take too much time. Knowledge of Android and iOS and optionally PhoneGap
development will make you (or your team member) a better developer regardless
of which technology you actually use. And based on that you will also be able
to make an informed decision about which approach to use for a particular
project.

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

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.

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

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

~~~
hboon
In that case, skip IB and build your views in code.

~~~
EzGraphs
Yeah, that route could work... but it is a bigger investment in time to learn
another language/development environment in greater depth. At least part of
the appeal for PhoneGap and other third party tools is that devs are trying to
avoid XCode / Objective C development. There is something painful/time
consuming about the process in comparison to other comparable programming
tasks.

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.

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

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

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

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

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.

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

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

Interesting how one can make the right choice without of knowing what he truly
wants and/or the right tool for his intent.

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

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

Still, I think he made the right decision.

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

~~~
pooriaazimi
What about the exposure it gives you app, and (potentially) _much_ more sales
(it has hundreds of millions of users with credit card, and buying stuff is
just one click)?

~~~
scriptproof
Zero exposure when your app is removed from the store (look at the news).
Beside that, I am not a fan of Apple the patent troll and very reluctant to
build an app specifically to them. HTML 5 has great exposure on EVERY
computer.

~~~
pooriaazimi
I'm an Apple _fan_ on the whole, but like many others completely dislike many
of their behaviors, including _random_ rules on the App Store.

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.

