
I made an iPhone game with PhoneGap and won't do it again - bok
https://bokstuff.com/i-made-an-iphone-game-with-phonegap-and-ill-never-do-it-again/
======
bschwindHN
Cross platform mobile games when you have C++ skills: Use C++ with OpenGL and
share most of the code.

Cross platform mobile games when you need to ship faster and don't want to
deal with C++: Unity

Cross platform traditional apps when you don't have a ton of developer
resources: React Native (or better yet, Re-natal with ClojureScript)

Cross platform traditional apps when you have ample developer resources: A
native app for each platform

Need to ship something quickly that will perform poorly, have weird UI quirks,
janky scrolling, misbehaving touch events, and hard-to-debug canvas bugs that
only occur on specific devices? Use one of those JS mobile frameworks.

~~~
calsy
Phonegap has great scrolling, touch events work as they should and UI quirks
are not a fault of the framework. Maybe just dont make games with it.

I have a successful phonegap weather app with over 200,000+ users in multiple
countries. As a solo dev it certainly does the job I require of it and gives
me very good return on effort as I can effectively deploy the app to most any
platform I wish.

Keep the JS lightweight, use CSS for all your transitions and most people
won't be able to tell it's a hybrid app.

~~~
bschwindHN
I can't argue with a successful app. If it gets users and the users are happy,
then you've succeeded.

However, I disagree with with "Phonegap has great scrolling, touch events work
as they should and UI quirks are not a fault of the framework"

I just downloaded your app on my Nexus 5 and easily broke the UI with just a
bit of button pressing. I don't know if the map is ever supposed to be
displayed in a tiny portion of the app at the bottom, but here is what it
looked like after some quick button presses:

[http://i.imgur.com/AoM5iKf.jpg](http://i.imgur.com/AoM5iKf.jpg)

Additionally, the drawer list items don't scroll at 60FPS, and the scrolling
acceleration is different from android's native acceleration.

The drawer that comes into view from the right (city detail?) also doesn't
scroll at 60 FPS and actually prevents the last row of details from showing on
the screen unless I drag it into view (at which point it will snap back down
when I release):

[http://imgur.com/JaZ9lMc.jpg](http://imgur.com/JaZ9lMc.jpg)

It's also quite easy to screw up the views with multitouch pinching (which
users _will_ notice when they try to interact with your map):

[http://imgur.com/ojfcTV6.jpg](http://imgur.com/ojfcTV6.jpg)

This isn't your fault, but it's _very_ hard, if not impossible, to get all
this stuff 100% correct compared to a native version. Obviously the majority
of users don't notice this stuff, but I just don't think you can make the
claims you do about Phonegap.

For new apps these days, if you have to go the hybrid app route, I don't see
how someone would justify choosing Phonegap over React Native.

~~~
calsy
I appreciate the feedback, always take that onboard.

1\. The bug in your first screenshot is completely my fault and not the
frameworks. Something I need to look into definitely.

2\. While I would like the forecast to scroll at 60fps on low-end Android
devices, I do not consider it a high priority. You might not agree, but the
scroller works as it should albeit not at 60fps on lower end devices. iPhone5S
onwards and later model Android devices run at the desired fps.

3\. Multitouch is intentionally disabled on the map view, but if I was to
include it I would use something like hammer.js which is a great js library
for multitouch support.

I cant judge React Native as I have not had the time to dive into it. I will
say phonegap was one of the easier frameworks I have worked with and it has
definitely served me well with many users on multiple platforms.

There is no disputing there are many shoddy web apps wrapped up with phonegap
and dumped on App Store/Google Play. They instantly leave a negative
impression and do affect people's opinions on web apps. However, those web
apps that are great, you dont even know they are web apps! They run so
flawlessly that it doesn't register in your mind that it is infact a web app
and not native.

~~~
izacus
Since when is a Nexus 5 a low end device?! It'll easily scroll anything in the
os at 60fps and there are huge amount of people out there running
significantly slower phones.

~~~
calsy
Again, the scroller works! It's not busted, the app doesn't crash on a large
group of slower phones. Many of my users run slower Android devices.

The OP who has a general bias against JS centric frameworks stated that the
scroller on his device did not run @ 60fps. I dont have any benchmark results
to prove this to be so, so I can only take his word for it.

Now, when someone who has a bias against something, provides an answer to
support his argument without evidence, is that reason enough to ditch a
framework?

As I have mentioned, I have a large amount of users across multiple platforms
and devices. That for me is good enough evidence that people enjoy using the
app that is built on the phonegap platform. Are there limitations, YES... give
me a framework that doesn't have them.

So enough about phonegap, show me a react native app running on multiple
platforms built and managed by one person with large amount of users.

------
memracom
This sounds like the same old rule that has existed for the last 30 years or
more. If you want to build an app that uses graphically intensive animations,
build as close to the metal as possible and do not rely on layers provided by
the OS.

I learned nothing from this because if I was going to build a game like he
described, I would suck it in and get down to the platform's assembly language
layer which for IOS is ObjectiveC and for Android is Java.

It would be far more interesting to read a review that explores the boundary
of what works well in PhoneGap and what doesn't. Clearly lots of successful
apps are built in PhonegGap/Cordova. We could have the same conversations
about desktop apps or server apps. Too many layers make things easier to build
but impose a performance penalty. It is wise to think before you build and do
some architecture and engineering before coding. Writing code is NOT
engineering.

~~~
candiodari
Of course the little detail here is that 50 tiny sprites apparently counts as
graphically intensive.

Why do web developers constantly make the argument that Javascript is not
slower than C (or Swift, or C++, or any native programming language) ? The
difference is night and day, 5000% and up for simple things like drawing.

~~~
erikpukinskis
> The difference is night and day, 5000% and up for simple things like
> drawing.

I find that seriously doubtful, you're going to have to provide a citation if
you want me to swallow that.

The relevant comparison is a single JavaScript function in Firefox looping
through a static array and making WebGL calls vs. a C++ function looping
through the same array and making OpenGL calls.

If the difference is 5000% or more I will donate $20 to the charity of your
choice.

~~~
GuiA
> The relevant comparison is a single JavaScript function in Firefox looping
> through a static array and making WebGL calls vs. a C++ function looping
> through the same array and making OpenGL calls.

...that's not how graphics benchmarking works. That would be like benchmarking
a language by seeing how fast it can add up integers.

~~~
SomeCallMeTim
Actually their example of iterating over an array and making WebGL calls is
_very_ close to exactly what you need to benchmark.

~~~
candiodari
It would seem more to the point for me to compare something like a game
downloaded from steam with a webpage, as that is directly comparing the user
experience.

If you artificially limit the scope to something trivial, anything can work. I
mean, that might be interesting for web browser developers, sure, and by all
means, use it for that. But what matters is what experiences can be created by
it.

The web experience for games sucks.

------
dheera
I've tried PhoneGap and Cordova wih Polymer and my biggest gripe is that even
the most _basic_ of mobile UI gestures have no good analogue. For example to
emulate swiping between tabs on a ViewPager, you have to implement hundreds of
dirty lines of code in JavaScript to catch touch events and decide how they
should behave, and hope you emulate the native experience. None of the tabbed
interfaces of any of these frameworks have it built-in.

Then you inevitably have to deal with Safari's stupid rubber-band scrolling,
which causes the _titlebar_ of your app to scroll if dragged. Then when you
disable that scrolling you're forced to implement your own scrollbar from
scratch and emulate the Safari rubber band on the parts you actually want to
scroll.

Pull-to-refresh? Good luck implementing it in a way that feels like a native
app.

Building all that in JavaScript is possible, and with the help of CSS3 and
WebGL it's often possible to get FPS on par with native apps, but emulating a
native-feel UI in JavaScript is _more_ work than just developing twice for
Android and iOS. And you usually end up with so much JavaScript bloat and DOM
hell that it takes forever to load on 3G or slower connections.

Seriously, can someone just give us <GridViewPager>..</GridViewPager>,
<ViewPager>..</ViewPager>, <ListView>..</ListView> or something like that,
with everything included, including touch gestures, and make it "feel" exactly
like iOS or Android depending on the OS it is loaded on, matching the
respective fonts, elasticity coefficients, gesture thresholds, and everything
else, no questions asked?

~~~
youdounderstand
You're never going to get smooth scrolling if you need to hit the UI thread
for every touch event. The platform UI frameworks use background threads for
scrolling, directly in the OS compositor.

~~~
panic
I don't know about Android, but UIScrollView does all its work on the main
thread of the app.

~~~
xenadu02
This is not strictly correct. CoreAnimation does it's work in a background
thread, so the mechanical work of scrolling pixels is not done on the UI
thread unless you are doing custom drawing. Under the covers its a texture so
the scrolling is really just translation.

~~~
panic
If you want to be pedantic, this isn't quite right either. CoreAnimation does
some work on the main thread to encode layer properties and send them to the
render server, which is in another process, not another thread.

The important part isn't the amount of work it takes to render, it's that
event handling is serialized with all the other stuff happening on the main
thread.

------
WA
> the iOS 10 beta introduced some new behavior where WebKit ignores the user-
> scalable viewport meta property. This "feature" is supposed to be for
> accessibility reasons; anyone should be able to pinch to zoom any web page.
> That's fine and all, but this would completely and totally break most
> webview-based apps.

This. I don't read a lot of outcry over this for unknown reasons. It baffles
me. Apple essentially broke all web based apps and not many people seem to
care.

~~~
izacus
That's because users are actually happy with the fact that they can now read
websites with readable text size instead of being locked into whatever the
20/20 eyesight designer thought they should read.

It was a huge problem and this made life easier for a lot of users,
significantly more than there are webapp users affected by this out there.

~~~
Lewton
Exactly, webpages blocking zoom was a cancer so nasty the side effects of this
fix are worth it

~~~
petemill
Why isn't it nasty that you can't pinch to zoom in all apps? What makes web
sites which declare they have been laid out for a small screen just like an
app different?

~~~
MBCook
I'm with millstone. I've never had that issue with an actual app.

Maybe that's because of app review, maybe it's the system defaults, it just
isn't an issue.

I don't think I ever had an issue with a webpage that seemed _purposful_. It
always seemed to be something they were trying to do for the desktop (perhaps
not a great idea there) that was a disaster on mobile. Or maybe they tested on
an iPad and when the screen is 4" instead of 10" it's unusable.

~~~
Tiksi
Heh, I've had the opposite experience. Generally sites that completely ignore
mobile are manageable on the phone, maybe I have to scroll around a bit but
its not a big deal. Mobile specific sites however seem to "break" (or at least
annoy me) spectacularly and frequently.

If I press the menu and your menu takes over the entire screen, seemingly like
a new page, the back button should close the menu, not navigate off your site,
_especially if there 's no way to close the menu other than navigating to a
link_. Floating elements that take up 20% of an already small screen with
absolutely nothing useful on them and no way to get rid of them are broken.
Redirecting a non-mobile link to the home page of your mobile site instead of
to the content the link actually points to is pretty common too.

~~~
MBCook
In general I HATE mobile sites because they're usually less useful than the
real desktop site or break things like reader mode. I'm especially FOND of
sites that try to implement their own gestures thus messing up scrolling or
the system gestures. That means YOU imgur.

But I've never seen an app present me with the equivalent of 3pt text by
default.

------
lambdacomplete
This post should be titled "I made a game with ImpactJS and packaged it for
iOS with phone gap" because any of the tools you used might be at fault. You
said it yourself the same phone is capable of running high-end 3d games
smoothly so, maybe, there is something wrong with GPU acceleration in either
Impact or canvas with WKWebView. That might be the reason why Unity uses
WebGL. Saying "I won't do it again" after not knowing precisely the cause of
the performance issues, and just blame hybrid apps in general, is not very
scientific.

~~~
swsieber
You're right. But its very practical - there are enough alternatives to try.

------
djsumdog
He developed it in PhoneGap and didn't release the Android version? :(

I've heard a full engine like Unity is a lot better for designing games across
mobile platforms. I've heard cross platform mobile development is a pain, but
if you're going to do it, use the right too for the job. Don't develop a
shopping app in a game engine and don't try to implement a game engine in
something meant for a shopping app.

~~~
bayonetz
This is worth repeating; use the right tool for the job. Phone gap is actually
pretty great for the scenario where you need a simpler info screen app to be
cross platform from day one. I made a personal app that way and it worked out
great. The author sort of conflates Phonegap being bad for games for Phonegap
being bad for apps in general. I think a lot of smaller companies would be
better of going the hybrid route for things like food ordering or boutique
shopping, etc. but there is this serious bias against it that I think 9 out of
10 times is more tribal/religious than for actual technical limitations.

~~~
rudedogg
> there is this serious bias against it that I think 9 out of 10 times is more
> tribal/religious than for actual technical limitations

I always feel like it's the opposite. People who haven't tried it themselves
will say to use Cordova for everything, but once you start you notice the
performance issues right away.

It's frustrating because a lot of freelance jobs I see are asking for Cordova
experts, and it's pretty obvious they're going to end up with a shitty app.
But, no one is going to tell them that. They'll spend all their money getting
a Cordova app made, and then look for a native developer when they realize how
bad it is and have no money left.

For background, I was learning JS development, and was really excited about
Cordova. I thought Moore's law had finally put web based mobile apps (mostly)
on par with native. But it's just not true, and I don't think it will be for a
long time. I wish people would be more honest in their documentation about the
limitations of things.

~~~
SomeCallMeTim
>People who haven't tried it themselves will say to use Cordova for
everything, but once you start you notice the performance issues right away.

I've developed a half dozen apps in Ionic Framework, and they all operate at a
silky smooth 60FPS. I don't end up with performance issues because I'm:

* Using CSS for animations

* Not using JQuery for things you should _never_ use JQuery for in 2016 because they're too slow on mobile

* Not piling on tons of verbose frameworks to accomplish every little thing and therefore slowing down the JavaScript engine as it ends up with multiple megabytes of code

* Limiting asset sizes so we don't overrun mobile memory limits

* Generally optimizing the code so that I'm not wasting time or creating 16 intermediate arrays in every data conversion/manipulation because the functional approach looks so pretty

I understand you were "just learning JS development." It may actually
(ironically) take more of an expert to get good performance out of Cordova
than it does to produce a decent native app.

But everything I did above should also be standard practice for creating _any_
web pages, since otherwise performance will in fact be crap on mobile. So it's
really just web development best practices.

No, it's not that there are limitations in Cordova. It's that writing web
pages for mobile is harder than for desktop, but that when you do it right, it
makes for a good app experience as well.

Not to mention React Native and NativeScript, which will get you full speed on
mobile with native controls.

~~~
rudedogg
I'll be a little more detailed. What I tried to do was make a game using
Phaser. I didn't get past creating the loading and menu scenes before I
starting noticing really bad sluggishness when first loading, etc. If you let
it sit for 10 seconds then things mostly smooth out, but you still have the
frame rate randomly drop, etc. I had done so little there was nothing to
optimize, it was just the barebones to get something on the screen. And I
didn't even try it on mobile, this was using my desktop/laptop.

I see the same thing with CSS3 animations. There's this weird jerking, even on
something simple like this:
[http://www.w3schools.com/css/tryit.asp?filename=trycss3_anim...](http://www.w3schools.com/css/tryit.asp?filename=trycss3_animation_speed)
. When I enable the FPS meter I see drops to 30FPS.

Also, I hadn't heard of Framework7 mentioned in another comment, so I checked
it out. The demo apps I tried
([http://framework7.io/apps/](http://framework7.io/apps/)) have issues on
mobile. I just feel like it's unfair to new developers who are going to invest
a lot of time before they figure out hybrid apps have issues. I know people
want to market/highlight how great their framework is, but it causes us all
grief. We should be more upfront about what works well (CRUD apps), and what
doesn't (games, animations, custom UI).

I don't know enough about React Native to comment.

~~~
SomeCallMeTim
I'm working with Phaser on an app that _needs_ to be mobile, but I'm
regretting not using PIXI directly.

See:
[http://www.goodboydigital.com/pixijs/bunnymark/](http://www.goodboydigital.com/pixijs/bunnymark/)
\-- click or touch to spawn bunnies.

Run it on mobile. On my Nexus 6 it stays pretty smooth around 10-15k bunnies,
sometimes more. I've seen it glitch as thousands of new bunnies are added at
once, but in a well-written game you'd create a "bunny pool" and pre-create
all of them so that you could add them without as much overhead.

It's actually a bit jerky on Firefox on my "ultra low power" laptop, despite
having a recent Intel i7 CPU, but Chrome is smooth up to 10K bunnies. On my
gaming computer, heh, I can go over 100K bunnies without it dropping below
60FPS. That's a lot of sprites, period.

At some point I'll probably port my game from Phaser to PIXI. Like I said, I'm
stuck using a browser for at least part of my game. If I were creating a 2d
game that didn't require a browser, I'd probably use something else: Unity,
maybe, or I'd look around at the other 2d and 3d engines out there to see
what's available. I also have an existing 2d engine that I might bring up to
date.

In your sample on w3schools, I ran some profiling, and it's firing off
_dozens_ of JavaScript callbacks per second, doing who-knows-what. Analyics,
probably? Also, as mikewhy pointed out in a sibling comment,
transform:translateX() gives you hardware acceleration. Otherwise it has to
rebuild the DOM on Every Single Frame. I pulled the code to a local server
without the w3schools extra cruft and it was much better, but still not
perfect. Converting to using tranform:translateX() made it silky smooth.

In any case, good luck.

------
rogueSkib
OP - I've been working with the Game Closure team on the HTML5 devkit for
quite a while now, and we have yet to find an engine that gets better
performance out of 2D JS games on native. The view hierarchy, rendering, and
animation are written in both JS (web builds) and C (native builds), connected
by a Java Android stack and an Objective-C iOS stack. The docs are a bit out-
of-date but the tech is really powerful. It supports WebGL and canvas
rendering in web builds, but there's no 3D support yet.

Github:
[https://github.com/gameclosure/devkit](https://github.com/gameclosure/devkit)
Docs: [http://docs.gameclosure.com/](http://docs.gameclosure.com/)

~~~
lazerwalker
Does Game Closure provide / require you to use its own game engine, or just
provide a canvas-compatible rendering context?

I'm trying to improve performance of my ImpactJS-based game on Android, but
none of the other canvas reimplementations I've played with (e.g. Cocoon,
Crosswalk) are meaningfully more performant than a regular old web view.

If Game Closure will let me drop my existing canvas-based game into an
optimized canvas context, a la Ejecta on iOS, I'd be super interested in
checking it out. The docs are making it hard for me to figure out what it
actually provides.

~~~
rogueSkib
That would be tough; the accelerated piece in native is mostly coupled to the
JS API - specifically the view hierarchy and animations. It's pretty
straightforward to port games to it though, and it's generally easy to pick up
and move fast. The easiest way is to take a look at some example code. Here's
a game I built for the Global Game Jam 2015. Cheers!

Source:
[https://github.com/rogueSkib/orcrun](https://github.com/rogueSkib/orcrun)
Playable:
[http://rogueskib.github.io/orcrun/](http://rogueskib.github.io/orcrun/)

~~~
lazerwalker
Is that supposed to control via the arrow keys? Seems to not respond to
keyboard input on my machine (macOS 10.12.1, both Safari and Chrome)

~~~
rogueSkib
Oh no, it's just swipes. We were designing for mobile, and desktop suffered
O.o

------
Waterluvian
I felt the same kind of hesitation getting into Swift and C#. But last summer
I finally set a 6 hr/wk schedule to learn the meat and potatoes of 2D game
development using both, just to better understand what's out there.

I learned a lot. But the most interesting lesson was that learning new tools
was easier than I expected it to be. XCode and Unity, along with a lot of
great tutorials and example code made it fairly painless. The hardest part was
pushing past the expectation that learning a new language would be time
consuming and difficult.

The most useful lesson I learned was to embrace new tools sooner. I think
there's a natural gravitation towards using a language/tool because that's
what you know. Of course we don't all have the luxury of the same amount of
free time to learn new things, but I think you'd really surprise yourself,
like I have, at just how much you _can_ learn.

~~~
majewsky
> The most useful lesson I learned was to embrace new tools sooner.

Is that really your take-away? If anything, your story reads like one can
safely hold out on learning new tools, given how quickly and easily one
becomes productive with them.

Of course, that reasoning does not apply to things outside your comfort zone.
If game development was new to you, then I won't argue that the time spent
learning was not well-spent.

~~~
Waterluvian
I was a huge gamer but I've never made a game before. Not that I made anything
too special. I made a breakout clone on swift and a 2d space shooter roguelike
in unity.

I more meant, instead of using the tools you know, don't be afraid to invest
sooner in the tools that are right for the job.

~~~
majewsky
Okay, that's definitely something that I agree with. :)

------
SunboX
"However, the real take-away here is: if I had built the game natively, I
don't think I would have had to worry about this kind of stuff at all."

There are a lot of limitations using JavaScript, that's true. But "using
native" you will have to "worry", too. I don't like these kind of Blog posts,
that only investigated one side. The gras on the other side isn't always
greener.

------
swsieber
I'd you're doing games, you might try experimenting with Haxe - it compiles
down to native, and doesn't does use web views. As a plus, you can generate
versions for other targets (Windows, html, Linux, etc.)

~~~
zengjie
Kha ( [http://kha.tech/](http://kha.tech/) ) is close enough to metal and can
be compiled to almost every mainstream platform (iOS, Android, HTML5, Windows,
macOS, Linux, Flash and even Unity) .

------
pcwalton
One elephant in the room that is never mentioned with these types of posts is
that the 2D canvas API, like all immediate mode 2D vector graphics APIs, is a
terrible fit for games (and for most things besides games too, but I digress).
It makes it very hard to get the kinds of batching optimizations you need to
make good use of GPUs, especially mobile GPUs, and all the vector graphics
stuff is overkill for sprite blitting. From a performance point of view, WebGL
would be much more appropriate. (Of course, WebGL is also much harder to use,
which is unfortunate.)

~~~
doublerebel
Pixi.js supports WebGL with Canvas fallback and I've found it to be very
performant on mobile devices. It's the easiest way I've found to get WebGL-
accelerated 2D.

------
bayesian_horse
If you care about 60fps performance on a single platform, then yes, Cordova
isn't for you.

If your app doesn't need extreme performance, and you don't have the time to
learn and develop for multiple platforms, and things like unity/kivy etc don't
give you enough UI, then Cordova is suddenly much more attractive.

~~~
brentvatne
I think 60fps is not "extreme performance" but rather expected performance for
a mobile app. Only one part of this article was about performance, anyhow.

------
bdcravens
> I'm never going to develop a webview app again

That'a a bit of a broad brush stroke, suggesting that you only build games or
you think issues you ran into would apply to all app types.

> Not having to learn a new language was great, but it wasn't worth the
> performance hit and quirks I encountered along the way.

Couldn't you gain many of the same advantages using NativeScript or React
Native? (though I think those would still be bad choices for a game)

~~~
darod
exactly! why would anyone try to develop a game with a hybrid tool especially
when performance is a consideration. you have to right tool for the job and he
should have thought it out a bit more.

------
wishinghand
> Background activity such as push notifications can slow everything down for
> a few seconds

This is sometimes the case with native games too. I can sometimes get a few
hundred millisecond warning when a text is incoming because of a sudden uptick
in lag, even on an iPhone 7.

------
Bahamut
I came across these quirks too at a prior job while using Cordova as well -
I'm largely convinced that these sort of hybrid tools are just not good
enough. I haven't used alternatives like React Native, NativeScript, etc. -
those sound a lot more fundamentally sound than Cordova/PhoneGap/etc. since
they aren't leveraging a WebView to do everything, although I have heard
complaints about those as well.

It would be nice if these platforms use just one language, but unfortunately I
doubt Apple would ever play nice there. It costs companies a lot more money to
maintain separate codebases or resort to subpar solutions...or just go iOS
first/only, which is an insidious consequence.

~~~
MBCook
Language doesn't necessarily matter, at this point you can use C or C++ and
many other things for iOS.

The system libraries and interface paradigms are completely different. You'll
never have a write once run anywhere thing. Games can come the closest since
they generally have their own completely custom UI is, but there still bits
that need to match each platform.

------
vermooten
I once made an app with Phonegap. The performance was terrible despite months
of optimisation and even a review from Big Nerd Ranch. The new Swift and Java
implementations are much MUCH nicer for users - the Swift version is really
responsive.

------
placebo
Use the right tool for the right task. Using the wrong tool for the task does
not mean that there is something wrong with the tool.

You want to develop graphic intensive games using a single code base without
learning native iOS or Android app development? You could probably do that
with open source platforms like Gideros (there are good commercial
alternatives too). Since iOS can't run LuaJIT, in particularly resource hungry
games you might have no option but to code in native.

A few years ago I developed a game for both Android and iOS using Cordova and
was very happy with the results. It was a Scrabble clone against the CPU with
nice animations and no one could tell it was not native. I knew it was way
below what the web view could handle so I wasn't surprised it succeeded. I'd
have never tried it in the first place with a 3D game or a game with many
entities and hope to get 50fps.

I also use Cordova to get native looking apps (not games) by using Framework7
([http://framework7.io](http://framework7.io)) - I'd like to see how many
users would really notice the difference (I'd guess about the same amount of
people who would complain about mp3's not giving a good enough quality for the
music they listen to)

I do agree that Cordova apps will probably continue be treated like second
class citizens (and perhaps worse) mainly because I assume it runs mostly
against the interests of Apple and also Google who would prefer you invested
your time getting locked in to their specific platform...

~~~
LeoNatan25
It only takes one look at the transparent navigation bar or popup or non-
spring transition animation to notice something is "off". Further looking,
things like inconsistent margins across devices, non-standard controls, etc.
give it away on a fundamental level. This kind of disrespect for your users'
ability to notice crap is what I dislike most about lazy cross-platfom
developers. At least have the decency to admit your are churning a
technologically and experience-wise sub-par product for this and that reason,
but that almost never happens. It's always the "no one notices this" nonsense.

~~~
WA
I've seen too many native apps with strange user interfaces, colors, margins,
wrong transitions to still believe that people really care.

Most non-dev users want to get some stuff done via apps and don't care about
design details.

------
epx
I have tried to grasp PhoneGap/Cordova many times and the thing just doesn't
make sense to me. Seeking a pet project to try React Native whose concept
seems saner.

~~~
gman83
I'm currently trying out Flutter, so far it seems pretty great.
[https://flutter.io/](https://flutter.io/)

------
sandstrom
Native apps has many upsides, but also downsides. The same goes for
Phonegap/Cordova. In general I'd say that games and performance-sensitive apps
aren't the strength of Cordova.

But having used Cordova for several years I'd say that overall it's an
excellent framework that can power large, complex apps.

I'd also wish Apple would give the web-views some more love, but overall they
work really well for many things.

------
jtchang
Quick question but are most graphics intensive games written in a single C++
code base for both iOS and Android? For example I use to play sim city on both
ios and android and noticed it was virtually the same. Is it just a shim onto
OpenGL and everything else is done inside C++ with a custom rendering engine?
Or are they using some type of Unity style environment?

~~~
kayamon
I don't know about Sim City, but it's very _very_ common for games to write
everything in C++/OpenGL and just use a thin layer to bind against the
underlying platform where needed.

In fact, other than using a premade engine like Unity, I'd say that's the only
sane way to do mobile development.

------
tapirl
IMHO, Adobe AIR SDK is still the best tool to develop mobile games.

All my 3 games (and one app) were made in one and half months each.

[https://play.google.com/store/apps/developer?id=Tapir](https://play.google.com/store/apps/developer?id=Tapir)

[https://itunes.apple.com/us/developer/xu-
liu/id578025970](https://itunes.apple.com/us/developer/xu-liu/id578025970)

In each the one and half months, most part of time was spent on design my
games/apps, only a small part of time was spent on device related debugging.

The biggest benefit by using AIR SDK is you even don't need to buy a
mac/iphone to develop ios apps.

------
tigershark
Seriously there are really people that don't want to learn any language other
than JavaScript??? The world seems upside down to me.. :(

~~~
malloryerik
JavaScript, well, too bad it's JavaScript, but look at what you can do with
it: build servers, webapps, mobile apps for Android and iOS, and desktop apps
with Electron and others. Does any other language compete in this way? And
then, it doesn't seem like a great choice for machine learning but, as you
know, you can use it there as well...

~~~
pikzen
Obviously webapps are a thing apart because browsers only support JS. But
otherwise... C++. .Net-based languages. JVM-based languages. (although I am
not aware of any tool that works on iOS)

Hell, in most of the platforms you can use your language of choice and
P/Invoke C++ components.

------
maffydub
Interesting read!

I wrote a (simple) 3d game using WebGL and released it on the Android app
store using Cordova, and found the performance was pretty solid.

This might be due to Android vs iOS, WebGL vs plain HTML or something else
entirely - any thoughts?

In case anyone is interested, the Android version is at
[https://play.google.com/store/apps/details?id=com.github.wil...](https://play.google.com/store/apps/details?id=com.github.williams.matt.ld29)
and an earlier web version is at [http://matt-
williams.github.io/ld29/](http://matt-williams.github.io/ld29/)

~~~
Too
I don't know if it's due to the video or the game but the trailer video on
play store is certainly far from 60fps.

~~~
maffydub
Good spot, but that's just the video. Unfortunately most screen recorder
software (at least free screen recorder software) for Android is very low
frame rate.

------
agmcleod
I build my current game with Cordova, and really the only major breakage i ran
into with updates was iOS 9 audio changes. Patched howler, and it worked fine
after that.

I realize this is anecdotal, it would be interesting to see his/her game, what
was so demanding to cause performance problems. Many platforms have their
quirks and SDKs that you need to learn.

I've had a lot more breaking changes with my React Native app. Opened the
other day, and text boxes were overflowing their container. Didn't happen
before. React Native is younger, so I find it's to be expected.

~~~
taejavu
What's it called? I'd like to try out some Android games built with Cordova.

~~~
agmcleod
Not released yet :). I have my old one out for iOS only, built ontop of
CocoonJS

------
fjrieiekd
Agree with the author. I tried out the game and while it's a fun little game
and a neat concept, there were a bunch of small glitches and issues that cause
it from feeling -great-, and it doesn't feel native or perhaps the author just
didn't bother to add specific support for the iPad.

To me the issue is clear cut -- if you're selling direct to the market and you
care about your users at all, UI should always use native components. The
choice of language is secondary, but personally I don't see how it would ever
be better to deal with differing and inconsistent web view standards -on top
of- the differences between OSes and devices. On Android, these alone provide
more than plenty of enough grief.

The advantages of coding direct to the platform are many:

\- higher efficiency and lower battery consumption, \- smaller downloads, \-
better performance, particularly on older devices, \- fewer glitches, \- and
finally, an app that just "feels right".

Code reuse can still be achieved by using C++, Rust or another layer to share
code. If most logic lies in the UI, writing it twice may be OK along with
tailoring the UI more closely to the platform paradigm.

There are different tradeoff so involved here, but to me, the increased user
satisfaction is worth the additional effort, and seeing how glitchy these web
apps can be, I'm not at all even convinced that it -is- additional effort.

------
edblarney
This is a good pots ...

But - the issues mostly boiled down to performance. As he noted, the issues
were with older devices.

The landscape is changing quickly - and within 2 years, that equation will
look quite differently.

It's not just that native will 'always have an advantage' \- which is true -
it's that JS will reach the 'decent threshold' for small game performance.

You only need 8Kb/s reliably for voice. After that it's just improvement. So
once radios could cross 8K/s reliably - we had mobile phones. From there it
just gets better.

I see this in those terms.

~~~
MBCook
That's what people were saying about PhoneGap three or four years ago when we
considered using it at my job. The iPhone is DRASTICALLY faster now than the
iPhone 5 (or so) was. Yet the same issues exist.

What was the old adage? "What Moore gives Gates takes away?" I'm sure that's
part of it. As more and more processing power is available the OS start using
more of it to do other things. So not all that's going to go to the
application.

And then you have the bigger problem of lack of access to new functionality.
When Apple or Google adds some new piece oh functionality it takes a while
(possibly years) for it to appear for webpages. I'm going to take a wild guess
and say Apple will never provide Metal to webpages. I would be pretty
surprised to see Vulcan for webpages on any platform.

How about using other new things? What about 3D Touch on my iPhone? I'm
guessing you're never going to have access to that. Things like PhoneGap may
be able to try and work around that, but it still sort of a hack.

You'll always be behind. Waiting for access to the newest technology, the
newer interface stuff, whatever optimizations get pushed into the web browser.
For certain simple apps it may work fine but if you need any kind of
performance or want to do anything especially interesting it's going to be a
no go.

Fundamentally the web view suggest to make it easier to display certain kinds
of content in your app. All of this is essentially a giant hack. It's never
going to be a first class app platform.

~~~
edblarney
I see your point - at the same time I don't quite agree.

The 'threshold' for web apps is closing in on regular apps.

80% of interactivity is pretty basic stuff. Very few apps leverage advanced
features such as 3d touch.

I do agree that many apps might need that 'one thing' in order to be great ...

But most don't.

Yelp, Facebook, Twitter ... none of them really need 3d touch ... though maybe
that feature will take root.

------
cloakandswagger
This seems less like an indictment of PhoneGap, it's more of a warning not to
build games in JavaScript.

Had the author used an appropriate tool for making games--a game framework
like Unity--they wouldn't have run into all of these performance problems and
it would've still been cross platform. Hell, Unity even has a JavaScript-esque
scripting language if you're so set on learning only one language (although
it's vastly inferior to C#)

~~~
gurkendoktor
As far as I know, Crossy Road is built with Unity and it often skips _many_
frames on my iPhone 5s. I'm not sure how Unity works, but it also felt like
garbage collection - a single, long hang every few minutes of playing the
game.

(Maybe things have improved, this was when the game was pretty new.)

~~~
derFunk
Never experienced frame lag with Crossy Roads, and I played it a bit.
Something like this _can_ happen with Unity, but if it happens it's 99,99% bad
programming, and not the engine's fault, unless you do graphically extensive
things, which Crossy Roads certainly didn't.

------
mschuster91
If it helps anyone: if using Cordova/Phonegap on Android devices, include the
Crosswalk Webview, especially if you plan on supporting anything below Android
4.4. Either as a dependency or static - the former keeps your app slim (but
unfortunately yet another dependency you cannot fully control), the latter
adds 44MB to your apk-size but offers you full control over the experience.

~~~
fgpwd
This can't be done in iOS though. I think crosswalk uses the default iOS
WebKit because of an apple restriction.

------
tuanway
Recently tried this route with a game as well. As the OP pointed out this
works decent for newer and more powerful devices.

Both platforms have annoying quirks and for Android I used the Crosswalk
webview which helped to keep things somewhat consistent. For IOS the WKWebView
was more than fast enough for this simple game.

My main reasons for going with phonegap/cordova was the ease to port to
multiple platforms and not having to learn another language. Hopefully support
for phonegap continues!

links to my game below:

[https://play.google.com/store/apps/details?id=com.tuanway.ti...](https://play.google.com/store/apps/details?id=com.tuanway.tienlen)

[https://itunes.apple.com/us/app/tien-len-pro-
tsd/id116761625...](https://itunes.apple.com/us/app/tien-len-pro-
tsd/id1167616250)

[https://tuanway.com/prj/tienlen](https://tuanway.com/prj/tienlen)

------
murukesh_s
I don't think it's a problem with JavaScript. Why isn't webgl in the same
range of performance as opengl? It need not be 100% closer to native but
60-90% is good enough for use cases like simple 2D games. Of course why would
the browser makers do that when both of them are also OS makers who benefit
from tighter control of the appstore?

------
freefal
As others have pointed out, your mistake was trying to develop a graphics-
heavy game with the wrong toolset. I'm one of the devs that works on the
Android and iOS apps for lichess.org and we've had a lot of success with
Cordova/PhoneGap. It's allowed us to do all our development once with
occassional workarounds needed for platform specific issues.

[https://play.google.com/store/apps/details?id=org.lichess.mo...](https://play.google.com/store/apps/details?id=org.lichess.mobileapp&hl=en)
[https://itunes.apple.com/us/app/lichess-free-online-
chess/id...](https://itunes.apple.com/us/app/lichess-free-online-
chess/id968371784?mt=8)

~~~
MBCook
Did you look at the video of his game? I'd hardly call it graphics intensive.

------
lazerwalker
I'd be curious to hear _when_ the author's experience was. They mention off-
handedly that using Ejecta didn't improve performance meaningfully compared to
switching to WKWebView.

Ejecta formerly used its own compiled version of JavaScriptCore, and thus
couldn't execute JS in the same sandboxed context as WKWebView (gaining
performance through JIT execution, etc). The most recent versions of Ejecta
does in fact use the system JSCore, which means it should see the same JS
performance characteristics of WKWebView.

Given that Ejecta also replaces the HTML5 canvas implementation with its own
native implementation, I'd assume that modern Ejecta is much faster than
WKWebView, particularly for games where the performance bottleneck is graphics
rendering.

~~~
ptx
Does using the system JavaScriptCore as a library, as Ejecta does, in fact
allow you to make use of the JIT? I thought WKWebView could do it only because
it runs in a separate process which doesn't have the same restrictions applied
to it as the app's own processes.

The Ejecta release notes[0] don't mention anything about the switch to the
system JSC library enabling JIT (which would be a big deal!), just that it
makes the apps a lot smaller.

[0]
[http://impactjs.com/blog/2015/12/ejecta-2-0](http://impactjs.com/blog/2015/12/ejecta-2-0)

------
h_r
Has anyone tried Xamarin for building mobile apps? Not Xamarin Forms but the
lower level tool kit? It sounds pretty good on paper. At work the only
negative I heard from one team who tried it is it added too much bloat. But
that might just be their coding...

~~~
yareally
If I were going that route, I'd probably consider using monogame via xamarin

~~~
derFunk
Monogame is impressing and open source, also for PS4 development. Also Xamarin
is awesome if you're into .NET.

~~~
eropple
MonoGame is rough code with a rough build system and a lot of strange
behavior. Frequently undocumented, too. I would suggest investigating FNA (a
significant fork of MonoGame used in 40+ shipped titles) instead; I have had
my tangles with its primary developer but the code quality is significantly
improved and it's really worth your time. Doesn't support the PS4, but you can
code to the XNA baseline and then hack around MonoGame for the PS4 later.

~~~
LyalinDotCom
Is this the FNA you're talking about? [https://fna-
xna.github.io/](https://fna-xna.github.io/)

------
seanwilson
If you wanted to use JavaScript, use something like Cocos2D JS:
[https://github.com/cocos2d/cocos2d-x](https://github.com/cocos2d/cocos2d-x)

The game engine is native and you communicate with it via JavaScript.

PhoneGap was just an unsuitable choice to make because it's not built with
games in mind at all. Over a normal webview, it gives you a way to communicate
with native mobile features but that's about it. You should have looked for a
dedicated game engine. There's plenty built around HTML5 as well but you're
likely still going to deal with browser quirks.

------
partycoder
Cocos2d-x is in my experience very solid, well documented and productive.

------
drvdevd
For me, with the only PhoneGap app I've worked on, there were required
extensive bridge code to Native APIs, anyway. So adding in the webview
components just meant having a mess of different languages/frameworks in the
codebase where I don't think it would've required very _much_ native code
anyway.

Is there a good meta-compiler solution targeting native APIs across mobile
platforms that people are using lately?

~~~
MBCook
> Is there a good meta-compiler solution targeting native APIs across mobile
> platforms that people are using lately?

I guess I just don't see why everyone is so dead set on trying to find a way
to not make native applications. No matter how long this goes on, no matter
how much more advanced these library seem to get, native apps always feel and
work better.

I understand you don't want to do a complete rewrite for each platform, but
I'm not sure that trade-off is worth it for the quality of apps you tend to
get out of these middleware solutions.

(Games are something of an exception)

~~~
bayesian_horse
It's a very attractive trade-off when you're "profit" plan doesn't involve
massive adoption by discerning gamers/users.

~~~
MBCook
I just don't think many people realize just how many people are actually
sensitive to issues of non-native apps, they just couldn't name or put their
finger on what the problem was.

Frankly I'm about to give up on Google because of their AMP pages and how
terrible they work on an iPhone. It's to the point where I can't use half the
search results. All because they decided to make it act non-native and
implement their own special behavior in I-frames on their website.

------
bluetwo
As he points out in the article, Safari works better.

It occurs to me that games like this could be collected into a portal that
could run in Safari, could be added as an icon on the home screen, and could
even be cross-platform.

But, people are so used to using the app store for discovery, so it seems
important to package up games so they can be dropped in there and downloaded.

Is anyone creating a useful portal for html-only games?

~~~
estel
> As he points out in the article, Safari works better.

What he points out is that Safari's JS optimisations were almost entirely
provided by the WKWebView that he was able to use with PhoneGap.

------
derFunk
I used PhoneGap professionally 4 years ago for hybrid apps. Since I stopped
using it my sentiment is "Cordova has to die".

~~~
yesimahuman
4 years ago might as well be a lifetime in Cordova/PhoneGap land. Things have
changed quite dramatically, even the web APIs available alone have evolved
quite a bit. We launched ionic beginning of 2014 and it wouldn't have been
possible before as the browser runtime just wasn't ready.

Also everyone had to build UI from scratch before Ionic and other frameworks,
and that was just crazy.

~~~
johnyzee
I tried to get back into PhoneGap after a two year absence. This was after the
PhoneGap/Cordova split and it seemed to me like the entire ecosystem was in
smoldering ruins.

Figuring out if you need to use either the PhoneGap or the Cordova binaries,
and then finding correct documentation for the respective forks, was in itself
a big hassle. But no more than trying to get the toolchain up and running.
Holy backflipping cow was that a nightmare. I have managed to repress the
details but it was something with installing NPM and then typing in magic
commands and hoping some byzantine series of effects would occur correctly,
which they never did.

I somehow managed to hack and slash the platform into a working configuration,
only to discover that performance (for games) was still far from adequate. I'm
sure it has its (non-game) uses, but the developer experience was probably the
worst I have ever experienced.

------
nipponese
After watching the gameplay video, it seems like Unity would have been a
performance-friendly way to achieve the goal.

------
DonHopkins
>... "alleged" ... "terrifying" ... "unnerving" ... "supposed" ... "should"
... "unable to reproduce" ... "maybe" ... "unsettled" ...

Some people are saying: [https://webkit.org/blog/6784/new-video-policies-for-
ios/](https://webkit.org/blog/6784/new-video-policies-for-ios/)

"Speaking of audio, there's some alleged iOS behavior where audio won't play
in a webview until the user interacts with it by tapping something. Sounds
bad, right? There are ways to work around it but the terrifying part is: I
couldn't trigger this limitation at all. Everything just worked like you would
expect it to, contrary to what the Apple docs or anyone on StackOverflow said.
So, I just kind of rolled with it, but this was very unnerving."

RTFM:
[https://developer.apple.com/reference/webkit/wkwebviewconfig...](https://developer.apple.com/reference/webkit/wkwebviewconfiguration/1851524-mediatypesrequiringuseractionfor)

mediaTypesRequiringUserActionForPlayback Determines which media types require
a user gesture to begin playing.

Use WKAudiovisualMediaTypeNone to indicate that no user gestures are required
to begin playing media.

"Case in point: the iOS 10 beta introduced some new behavior where WebKit
ignores the user-scalable viewport meta property. This "feature" is supposed
to be for accessibility reasons; anyone should be able to pinch to zoom any
web page. That's fine and all, but this would completely and totally break
most webview-based apps. However, I again was unable to reproduce this
behavior at all in Super Flipside. Maybe it's the way I'm handling touch
events or something, but I just couldn't get it to break in the way it was
supposed to. And again, I rolled with it, but felt very unsettled."

RTFM:
[https://developer.apple.com/reference/webkit/wkwebview/14149...](https://developer.apple.com/reference/webkit/wkwebview/1414983-allowsmagnification)

allowsMagnification A Boolean value indicating whether magnify gestures will
change the web view’s magnification.

Discussion The default value is false. You can set the magnification property
even if allowsMagnification is set to false.

------
forrestthewoods
Hacking layers on top of layers just doesn't work well for games. The
requirements of high throughput, low latency, and no hitching is too much for
such hackery.

Keep it simple (C++ and OpenGL or Unity) and you'll be much happier imo. Leave
the constricting frameworks and dependencies at home.

------
supermatt
"if I had built the game natively, I don't think I would have had to worry
about this kind of stuff at all"

Actually you still would have had to worry about this stuff. A mature game
library would likely have helped but the choice of language isnt the issue
here.

------
brendanr
The perf issues sound suspicious. At least in the past, canvas sprites on iOS
can get very slow if you don't render to integer coordinates.

Hopefully the author attached macOS Safari to his iOS device to do some basic
debugging and profiling.

------
ourcat
If learning native isn't/wasn't your thing, I would have suggested
Appcelerator Titanium.

I was in the same boat as you. But thanks to Titanium's failings, I eventually
learned how to make iOS and Android 'modules' which could do anything the
native Java or Objective-C couldn't do for the apps I was building.

I wasn't dealing with fps WebView performance at the time, but I was
scratching an itch. But I have been up against that before and have dealt with
it with WKWebView too. It is faster, for sure.

I feel Swift and Java are closer these days. So I hope to soon ditch these
hybrid frameworks and do everything native.

(Though I will say that after 12 months working with AngularJS for the web,
I've recently discovered Ionic, and will be using that for a big job coming
up).

------
paulddraper
I've had the same experience as the author.

Though in fairness, I didn't see where an Android or Windows version was
released.

If you're not going to release on multiple platforms, what the heck are you
using PhoneGap for?

~~~
MBCook
If you try it and it doesn't work too well on the platform you care about most
(I'm making assumption here) then do you really want to try and optimize for
two or three more?

~~~
paulddraper
No, but your comparison will be flawed.

PhoneGap isn't comparable to native development on one platform; it's
comparable to native development on multiple platforms.

Until you've done the latter, you don't have a baseline.

~~~
MBCook
I was explicitly referring to trying PhoneGap.

------
jordache
I don't get it.. PhoneGap is not new technology. Its pros and cons were well
understood. The author making this pronouncement as if it was a notable
insight

------
joeblau
The one think I'm thankful for is that the OP did a thorough investigation
into PhoneGap. I've tried 5 cross platform build systems for iOS/Android
(PhoneGap, Appcelerator, Adobe Air, Corona, and just rolling my own Web based
app using Sencha Touch). I gave up trying to build anything other than native
in ObjC/Swift and it seems like even 6 years later, the same problems are
still prevalent.

------
thewhitetulip
Does this mean that we shouldn't use JS for making games for mobiles or does
it mean not using JS at all?

------
awqrre
or "I won't use python for apps that should be done in C", etc...

------
spdionis
This sounds like "I made a desktop game in javascript and won't do it again".

------
gkafkg8y8
Can anyone say what the easiest development platform is to use to write a 2D
game that uses code instead of a GUI, has tutorials that don't expect that you
know the language/API/environment that well, and is free to use?

I've looked at several, but either I can't develop for iOS/Android for free
(beyond the charges to get setup as a developer by required by Apple, Google,
etc.) or the barrier to entry always kills my time, then I go onto something
else. LÖVE [https://love2d.org/](https://love2d.org/) was the only one I
actually got anything playable with, but Lua/LÖVE was a little finicky and got
frustrating. I want to be up and running and deploying to an emulator with
something interesting in no more than 30 minutes, and I don't care how blocky
it looks.

Years ago I wrote homebrew games, so I'm not new to concepts required, but I
don't want anything too complex.

~~~
Rabidgremlin
Unity is pretty much free if you make < $100k. I have a tutorial series for
writing a 2D game in Unity up on Youtube if you are interested:
[https://www.youtube.com/watch?v=3Vpf6vFOXTQ&list=PLvUqRm2B9R...](https://www.youtube.com/watch?v=3Vpf6vFOXTQ&list=PLvUqRm2B9RRBgJipfDmFR7sFhEwBn7aGT)

Otherwise I'd suggest you brush off you C skills and use SDL.

Or just tinker with Pico-8 if you want some oldskool nostalgia
[https://www.youtube.com/watch?v=ZuaLuMhwcc8&list=PLvUqRm2B9R...](https://www.youtube.com/watch?v=ZuaLuMhwcc8&list=PLvUqRm2B9RRDzHgd4o7mcvHI5pI7Qp2rq)

