

Would you use PhoneGap again? - grobmeier
http://www.grobmeier.de/would-you-use-phonegap-again-18052013.html

======
gisenberg
I've had pretty extensive experience with PhoneGap targeting iOS, Android, WP7
and WP8, and would neither recommend it or use it again.

This isn't so much a commentary on PhoneGap as much as it is HTML5 as an
application platform. The bar for an application tends to be much higher than
a web page; a fantastic web page may be pretty shit when compared against the
app bar. Users have fundamentally different expectations around
responsiveness, interaction and fluidity for an app that they had to go
install as opposed to a site they visited.

Apps demands certain responsiveness, and replicating that behavior in HTML is
exceptionally difficult and leaves the user with a bunch of UI behaviors that
are close, but not quite right. Fluidity in user interactions, specific
scrolling behaviors and so on that are exceptionally difficult to replicate
across platforms.

A browser is also a pretty leaky abstraction. Targeting an API level in
Android guarantees a specific set of behavior and functionality, but targeting
a browser offers no such guarantees. The Samsung Galaxy S2 has a modified fork
of Webkit that provides device-specific app problems within the same versions
of Android, which make releasing a quality product pretty difficult to
guarantee.

And, of course, different screen dimensions are a problem. Android devices can
range from variable aspect ratios with a minimum width of 240px all the way up
to 1280px. Responsive design is a bit of magic that can be sprinkled on to
help make things work better, but that's a substantial bit of effort relative
to using the native UI tools for each individual platform.

edit: Another challenge with PhoneGap applications is targetting iOS. HIG
without designer assistance is a challenge, and this particular gem in the iOS
approval guidelines is somewhat damning: 2.12 Apps that are not very useful,
unique, are simply web sites bundled as Apps, or do not provide any lasting
entertainment value may be rejected.

~~~
mcgwiz
Very interesting. So it sounds like the problem is effecting a native
experience with HTML5 (something, notably, that Windows 8 gives first-class
support to). So then, given the HTML5 expertise and attention to detail, would
you recommend PhoneGap? Or would you still advocate separate, native efforts?
(Or something else?)

Also, do you really think adding media queries to the stylesheet(s) is
"substantial relative to native tools"? Taken holistically, I would think that
when you're targeting multiple platforms, you expend much greater effort
building natively for each platform. Using those native UI tools to provide a
good experience for variable aspect ratios actually entails knowledge of
different languages, build tools, runtimes, standard libraries, third-pary
library ecosystem, and best practices related to all the above.

~~~
gisenberg
It's not a matter of expertise and attention to detail. It certainly isn't
impossible to make a native-feeling web application, but I do think that the
level of effort is comparable to just doing the app natively, and the web
counterpart will still fall a bit short. For what it's worth, WinJS apps still
feel clunky to me when compared to their native equivalent.

I think summarizing responsive design as adding media queries oversimplifies
things a bit. The test overhead for PhoneGap is enormous; deploying fixes to
an app is much more difficult than deploying fixes to a site, and individual
devices can exhibit bugs that other devices won't within the same Android
version. Adding different levels of responsive layouts multiplies that effort.
By the end of one particular PhoneGap project, I literally had a dozen
different devices on my desk to assert reasonably small changes.

The browser as a leaky abstraction thing also continues to be a pain point.
One particular difficulty I had with PhoneGap was Android 2.3.x, in which div
overflow scrolling isn't implemented (also, ironically enough, not implemented
in WP8 IE10 when used in conjunction with the -ms-viewport CSS rule),
requiring a design that either doesn't use scrolling elements, or emulates it
with JavaScript. In either case, the native experience wins out.

Hitting several platforms with a good-enough experience may be an overriding
priority, and you could certainly pick worse than PhoneGap to make that
happen. For my own tastes, though, I'll be leaning on Mono for cross-platform
efforts.

~~~
mcgwiz
Thanks for sharing your insights. I appreciate the viability of the Mono
option. Back in the early web development days (an approach that continues to
this day), achieving cross-browser usability meant constraining design to the
few portable features that worked well. It seems from your statement that the
similar might be the case (product design within the constraints of the
portable HTML5 featureset) which would mean better trained product designers
(to understand which design elements common in native apps are more costly in
PG apps) or more collaboration between them and developers.

But as you said, Mono/Xamarin is a technically better option with the same
ultimate goal. Though a couple trade-offs there are unavailability of the
source and upfront licensing costs.

------
smanuel
I'm using PhoneGap and I'll use it again.

Yes, a PhoneGap app may never run as smoothly as a native app but I'm not
ready to sacrifice the advantages that PhoneGap approach brings:

\- Using HTML/JS/CSS for all platforms \- I can strip all PhoneGap related
calls from my app and have a mobile web app (which can run as a full screen
web app)

And there're various tips and tricks to help you achieve almost native
experience with PG ([http://coenraets.org/blog/2013/05/top-10-performance-
techniq...](http://coenraets.org/blog/2013/05/top-10-performance-techniques-
for-phonegap-applications/)).

Imagine doing this in: \- ObjectiveC for iOS \- Java for Andriod \- C# for WP
\- HTML/JS/CSS for having a mobile web app

Sacrificing some performance suddenly starts making sense.

------
kayoone
instead of relying on HTML5 as your base tech stack for mobile apps i am much
more a fan of approaches like xamarin (<http://xamarin.com/>)

Basically you write the core of your app in C# and then use the bindings to
the native SDKs of iOS, Android, WP to build real native UIs on top of it. Its
a bit more work and you need to learn C# (which is awesome) but imo its an
optimal compromise between speed of development/maintainability and the
resulting user experience.

~~~
LordIllidan
I have used Xamarin recently - while I absolutely loved developing an iPhone
app in C#, it was a bit frustrating to see that all the best 3rd party
libraries, tutorials, etc for iOS are all in objective c - and some concepts
didn't seem to translate easily to C#. It was my first iPhone app, so I could
be mistaken - but I think I'll go down the native route in future.

~~~
danabramov
In my experience, it's fairly trivial to create a library binding so you can
use ObjC library in C#. They even released a tool that generates bindings by
header files, called ObjectiveSharpie.

~~~
LordIllidan
Yes and I've used it twice - the problem is that all the documentation you'll
find naturally uses objective-c code - which you have to understand anyway to
get it translated to c#.

------
ergo14
I don't have experience with Phonegap. But jquery mobile was mentioned in the
article and it's lack of "native" look.

If someone is interested in developing mobile apps using JS framework I would
like to suggest dojox.mobile from dojotoolkit, it DOES have native themes
ios,android 2.3, android 4.x holo (and maybe more), iv'e built a big mobile
app with it and it worked like a charm - it's used directly + some of the app
views are used in our native app(yeah we have that too) - to speed up
development.

<https://dojotoolkit.org/features/mobile>

------
thekingshorses
Yes, I would.

Most people don't realize, but most good native apps (not games) are only
available on one platform. Only big companies and funded startups has apps on
all platforms that are good.

Also, major problem with Phonegap is jQuery mobile and similar frameworks.
they are heavy and makes app sluggish.

Android specially chrome browser is another major problem.

Despite all that, you can still create a very good app that performs well on
all platforms.

I wrote this hacker news HTML5 app mainly for trial run to see if it is
comparable to native apps. I only developed and tested on mobile chrome, ios
and desktop browsers. r/windowsphone redditors told me it works pretty good on
WP8 too.

<http://hn.premii.com>

What I have learned? \- Android (chrome too), Firefox and Window Phone 8 -
they need to provide better support for overflow scrolling. \- iOS - Remove
300ms delay for click for mobile apps \- WP8 - You can't fucking embed fonts
in your phonegap app. It has to be hosted on remote server. Also you can't
have ? in local urls (files that you are loading locally). It won't load those
files.

~~~
robocat
Have you tried embedding fonts on WP8 using a data url? Apparently it works:

"I was able to get my font/icon set to be recognized by Windows Phone 8 using
base64. Make sure you use WOFF and TTF fonts as follows (where * are the long
base64 strings):"

{{{<code> @font-face { font-family: 'icomoon-ac'; src:
url(data:application/x-font-woff;charset=utf-8;base64,* * _) format('woff'),
url(data:application/x-font-ttf;charset=utf-8;base64,_ * *)
format('truetype'); font-weight: normal; font-style: normal; } </code>}}}

[http://stackoverflow.com/questions/15819717/font-awesome-
not...](http://stackoverflow.com/questions/15819717/font-awesome-not-
displayed-on-windows-phone-8)

~~~
thekingshorses
I saw that yesterday. It doesn't work for me. I am also using icomoon. I
copied font to HTML file and also remove other fonts, but I couldn't get to
work.

Same guy stated in other comment that only icomoon working for him.

I am also including another font, and since that won't work, I am just gonna
load everything from remote server.

~~~
acturbo
That was my post on Stackoverflow (acturbo). I did in fact get icons from
icomoon working properly on WP8 (HTC 8x). My same web site looks the same on
WP8, iPhone, Android and iPad. Let me share 2 comments: 1) i only tried
icomoon, and 2) i used only 1 embedded font.

I use jqMobi, now called Intel App Framework, to build a mobile website that
targets all major mobile browsers. The jqMobi framework includes ~70 icons
from icomoon embedded into its ui CSS. I needed a few more, so I initially
tried to extend that by making another font file called icomoon-extra,
uploading it to <http://www.motobit.com/util/base64-decoder-encoder.asp> to
produce the base64 string and adding another @font-face to the jqMobi CSS.
That didn't work for me, so i simply created a new icomoon-ac file that
includes most of the original icons from the jqMobi icomoon selection, plus
another ~30 or so icons that i needed. Now, i just use my icomoon-ac font in
the framework and it works.

Regarding jqMobi, I absolutely love this framework. Much like the author of
the original article, i looked at a bunch of frameworks. jQuery Mobile was my
initial "no brainer" choice but it quickly lost favor with me because it was
very difficult to customize. They really screwed it up, IMO. I looked at wink,
joApp, dhtmlx, unify, uranium, embedjs, enyo, lungo, the-m-project, mobl,
barleyjs, limejs, joshfire, lavaca, xui, zepto, chocolatechip, jQT, iUI. I
ended up standardizing on jqMobi because it was based on a stripped down
version of jQuery and it added a very logical and flexible framework for
building mobile websites.

------
madmaw
Would I use PhoneGap again? Maybe. In my experience PhoneGap doesn't bring
much to the table. The core UI element (a thin wrapper around the native
WebView) is easily replicated in less than 100 lines of code. The plugins I
used were very inconsistent between Android and iOS, so in the end I spent a
lot of time either wrapping them in JavaScript to make them consistent, or
(re)implementing missing plugins on one platform or another (or both where
they were substandard).

Yeah, it lowers the barrier to entry if you are a web developer looking to
wrap your web site up as a native app, but if you have even basic skills in
your target platform(s) it's very easy to replicate its functionality and you
get finer control over how it starts up (which was an issue for one app I
made) and your distribution file will be much smaller.

Would I use HTML5 to create hybrid apps again? For the right project,
absolutely. I think other people have mentioned that there's currently no "one
size fits all" solution on mobile, and JavaScript frameworks, associated
tooling, and mobile browsers are definitely still in their infancy when it
comes to building full-blown client-side HTML5 applications. This is one space
where things are happening incredibly quickly, and even with what's available
today(1), you can get acceptable results. For a small-medium sized business
that simply doesn't have the money to develop and maintain applications
targeting every platform (including web) hybrid development is a very
appealing option.

(1) disclaimer: after some investigation of Backbone/Angular I was unimpressed
with their ASP/JSP on the client model and rolled my own MVC framework, but
literally millions would say I was wrong to do so

------
BigBalli
Yes, definitely, unless we're talking about a very specific kind of apps.
PhoneGap is perfect for most apps out there even if only deployed to one
platform. I can code in both and can guarantee that setting up the same view
takes 5x more time in ObjC than HTML (PhoneGap).

However, if you're looking at games or highsecuritt apps, you shouldn't even
"try" with PG.

I think the author is spreading some erroneous information. \- the delay in
tapping is only because he doesn't know how to properly make webapps (ie using
clicks rather than touch). \- you do not "need" frameworks. only if you don't
know how to do things yourself.

------
gonewest
Is learning objc really so difficult compared to learning all the obscure
things you have to do to make a native-like html5 app?

~~~
zackmorris
Learning objc isn't too bad but it introduced a lot of (in my mind)
unnecessary complexity because now you have two code paths (message passing
vs. ordinary functions). It's quite a verbose language so you have to declare
member variables several times, and ARC has drawbacks over garbage collection
so it's not always clear when something should be declared strong or weak,
making it nearly impossible to prove that an app is free of leaks in low
memory conditions. Apple's iOS frameworks have a lot of trouble with
inheritance, so you might have code that works with regular buttons but can't
work with toolbar buttons for example, because they don't share a root class.
So I generally find iOS development to be remarkably complex and tedious for
even the simplest GUI elements, especially if you are trying to do something
beyond the vanilla layouts that Apple has in mind. You also really can't
develop for iOS without Stack Overflow, which to me is a red flag for any API.
Xcode has numerous bugs, especially with XML, so you may find that some change
you made to a .xib file is not revertible because of a caching issue, and when
you examine the XML you see that something was named slightly differently, so
you have to be diligent with your version control and snapshots. Apple is
unable or unwilling to acknowledge many of these problems, much less solve
them, so I constantly fight against issues that I thought would have been
fixed by iOS 6. I think out of every API I've learned, iOS is the hardest, not
because of conceptual problems (their threading system is actually fairly
good) but because of poor implementation choices where Apple omitted something
for political reasons so you have to reinvent the wheel. What we really need
is a cross platform middleware that provides a consistent event system and API
like win32 for all platforms, and then someone could write language hooks for
that in javascript, lua, ruby, whatever. Without that middle layer, it's too
constraining to work with pure html5 IMHO. I've only touched the tip of the
iceberg here - there are so many hurdles to even getting an app published
natively that I think making a cross platform app is still an open problem.

------
sunsu
The author's comment that "Sencha does also come with a Look & Feel, but
again, it’s the Sencha Look & Feel, not the Android or iPhone one" is false
and also is, imo, a silly reason not to use Sencha. Sencha is entirely
themeable and it even comes with iOS and Android themes that you can easily
enable.

Sencha does, however, have a steep learning curve. I think thats probably why
the author didn't dive into it deep enough to grok the themes.

~~~
grobmeier
As I mentioned, I am not a Sencha expert. I experienced the stepp learning
curve you mentioned and didn't like what I see from the examples. So I decided
to not step so deep into it. Also I got recommendations from people I trust to
not use Sencha because of its complexity. I cannot say anything about that, so
I left it out in the post.

------
Egregore
The best experience in developing cross platform games I had with Haxe+Nme,
the aproach works and the speed is native. Also it's free and open source.

------
bdfh42
Yes - I ran a trial a while back to see just how difficult it would be to get
a common HTML/CSS/JavaScript set to work across iOS and Android browser
variants for a non trivial graphical app. [It was quite difficult - much
simpler to write 2 variants - but that was why I ran the trial]. Using
PhoneGap the trial app is doing well as a free download in the Google Play
Store and the Apple AppStore.

------
soemarko
> It’s the details which eat up your budget.

The article hit that spot on. You'll spend more time getting the swipeable
cell to bounce and swing correctly than working on the app. It'll be "cheaper"
to work with someone who knows the native language. You could learn one of the
native language and see if the app sells before jumping to another platform.

The bigger problem, IMHO, is that these sort of abstractions, like PhoneGap
and Appcelerator (maybe Xamarin too? I don't have any experiences with
Xamarin), most of the time will left you clueless when the app crashes.

------
hawkharris
Thanks for sharing this, Christian. Reading about your research and experience
makes me want to give Cordova a try.

I'd also like to offer a small piece of feedback concerning your first
paragraph, where you wrote "more worse": <http://www.wikihow.com/Use-Worse-
and-Worst>

This is a minor thing that doesn't take away from your well-researched post in
any way. I'm only taking the time to point it out because I enjoyed your
writing, and I think all writers can benefit from a little feedback.

~~~
grobmeier
Thank you. As a non-native speaker I often struggle with the english language
and gladly take any hints to improve my writing. Have fun with Cordova, it's
worth trying.

~~~
hawkharris
No problem, and thanks again for sharing the research. :) As a native English
speaker who is struggling to learn a second language, I can relate and
appreciate how tough it is to remember those weird quirks. (Not to mention
that English is especially quirky.)

------
talhakhan720
Check out <http://www.icenium.com/> by Telerik.

They just recently added support for Sitefinity CMS using Icenium as well.

~~~
spo81rty
For people who want to use Phonegap I highly recommend looking at icenium.

------
peteforde
Irony: the author's blog renders poorly on mobile Safari, due to unfortunate
floating interface elements.

~~~
grobmeier
Several people told me, I am going to fix this issue. It's akward. Thanks!

------
mackon
That's why Titanium rocks - one cross-platform codebase in JS, native UI
controls, no interface lags.

~~~
ceejayoz
It was pretty damned buggy when I built an app in it a year ago, to the point
where it felt like a way to drive you to their paid support.

~~~
quahada
I'm using Titanium for my app. Some things are still a little buggy, but it's
a lot better now. It is open source, so I am modding the SDK to fix the bugs I
have.

------
spo81rty
Another option is Rarewire. They have a way to write native apps once. Check
it out. We are using it to write a simple app with some good success.

------
ahaproudowl
Old arguments, yes there are problems. People are solving them beautifully.
See <http://famo.us>

~~~
grobmeier
Why do you think a landing page solves my problems?

