Hacker News new | past | comments | ask | show | jobs | submit login
I made an iPhone game with PhoneGap and won't do it again (bokstuff.com)
363 points by bok on Nov 26, 2016 | hide | past | web | favorite | 235 comments

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.

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.

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:


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


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


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.

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.

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.

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.

Hi, are you claiming say a re-natal app wouldn't have those quirks? Or at least fewer of them? Any writeups/experiences you'd like to share?

Yes, I believe so. I'm working on an app at the moment which uses ClojureScript on top of React Native. When I finish it I'll write something up. You can see an existing writeup on using React Native with JS here:


It basically works by running JS in a separate thread and doing the usual virtual DOM diffing algorithm to determine when to update and swap out native view components. The fact that it uses native UI components is what matters here. You don't have to recreate the behaviors in JS. It simply determines the tree of elements to display, it doesn't do the actual work of displaying them in a canvas. Then the underlying OS will take care of rendering from there.

And then you get the niceness of slicing up data and making network calls in JS or ClojureScript. And if you use re-natal in particular, you get a really simple but powerful application model. You can read about that model here:


I'm sure I'll run into quirks and other weird behavior as I go, but I seriously doubt it will be anywhere near the magnitude of problems you see with JS-canvas frameworks.

Maybe save your judgement once you have successfully deployed your app on multiple platforms and dealt with myriad of issues that arise from your users.

Of course. But you can't deny there are classes of problems you completely dodge by using native UI components instead of a web view, especially when it comes to touch events and scroll accelerations.

I'll shut up now and write something up once I deploy an app to multiple platforms ;)

Sorry, didnt mean to be rude, it's easy to get defensive when talking about your work. I would like to read about your progress.

Not rude at all! I was a little aggressive with the app UI quirks I found.

If anything, your app is a great example that most users don't care or notice non native UIs as much as developers do. It shows the viability of using such a framework. So don't let me get you down, I just enjoy breaking software :)

Mind sharing a link to the app?


Im an Aussie, my 'flagship' version is specific to Australian weather. I have weather apps designed for other countries as well.

Cross-platform support was very important for my app, and I was the only developer. The app is an offline file sharing utility (1) with no servers involved. I wanted to support iOS, Android, Windows Phone, Windows Desktop, Mac OSX and Linux.

Initially, I built the offline file sharing app natively on each platform. That approach was tedious to build and maintain. It was scary adding new features because I had to do the same thing on every platform the app supports.

Then I did a major rewrite. I wanted at least 90% of the code to be shared across all platforms (desktop and mobile). Looking at React Native, it wouldn't have served my purpose. I ended up with C/C++ (for logic and network) and HTML/CSS/AngularJS (for the UI). Best decision ever.

The app needed a more advanced file browser for users to select files. The app's file browser performed very poorly when I tried implementing it with an HTML UI, and frankly would have required more work to optimize across all platforms. So I implemented the file browser natively on all platforms the app supports.

Overall, this approach has worked pretty well for me. And even though it is not as optimal as going native on each platform, I can fix bugs and implement new features much faster now.

(1) http://www.feem.io

That's fantastic! C++ is totally the right call for that situation, React Native is mostly focused on Android and iOS it seems.

Do you have any articles about your experience developing Feem? I have a project underway that also targets Android, iOS, Windows, Mac, and Linux and I'd be curious to hear how you have things set up in terms of build systems, what was the most painful platform to work with, etc.

Core - C++

UI - HTML/CSS/AngularJS (1.x)

Git - Separate repositories for UI and Core.

iOS - Cordova (just for the initial setup). Modified XCode project to include changes from the Core and UI git repositories. Added some native iOS code. Bridge between Core, Native and UI done with objective C++.

android - Cordova (just for the initial setup). Modified Android Studio project to include changes from the Core and UI git repositories. Added some native Android code. Bridge between Core, Native and UI done with NDK/JNI.

windows UWP - Cordova (just for the initial setup). Modified Visual Studio C++ project to include changes from the Core and UI git repositories. Added some native UWP code. Bridge between Core, Native and UI done with C++/CX.

Mac, Windows Desktop, Linux - Qt. Modified Qt Creator project to include code from the Core and UI git repositories. Added some "native" QT code. Bridge between Core, Native and UI done with Qt's C++.

Browser differences was a huge PITA. It was still worth it, though, compared to writing the same UI in different platforms and programming languages.

If you need more info on the build process, you can shoot me an email. My email is in my profile.

Thanks! Pretty clever to use Cordova to generate the initial project structures.

> Cross platform mobile games when you have C++ skills: Use C++ with OpenGL and share most of the code.

That's what we had done with our iOS game Dino Rush [1] back in 2010.

It was a lot of work to build our own engine, and the additional amount of work needed to port it to Android discourage us. Today even if you know C++ I will only recommend to use a commercial game engine like Unity, Unreal Engine, Lumberyard or Defold, to name a few. Build your own only if you have a lot of resources and very specific needs.

[1] https://itunes.apple.com/app/apple-store/id396101698?mt=8

I'd suggest:

Cross platform traditional apps when you have at least one poor soul who is willing to work with the Android NDK/JNI: shared C++ business logic + minimal platform-specific language for UI.

My view is that unless your app is trivial (say, less than 10K lines of code), it's never worthwhile to re-write the entire app for each platform. Share as much logic as you can with the "common" tongue, C++.

I would go a little bit further and say that, depending on which language you have your code, you can even use C/C++ to make a bridge between Java and some language interpreter. I've done something like that for integrating a lot of existing python code on a Android app I've done. There's a working sample in my github: https://github.com/joaoventura/pybridge

Performance is pretty good, and the UI is entirely native Android.

I've worked with the NDK/JNI and totally agree on the "poor soul" comment. If you're someone like Spotify who has enough money, supported platforms, and a complex enough app, then that method is likely a win.

But if you're only targeting Android and iOS, you'll likely get to market faster with something like React Native while still retaining native UIs. It'll certainly be better than Phonegap/Cordova/Ionic.

What is your opinion on Qt mobile?

I haven't personally used it so I don't have much to say. It looks like it requires a commercial license so that doesn't get me particularly excited about it.

I'm also not sure how hard Qt actually tries to give you UI components that look like what you would find in a typical app. If you have Qt experience then I'm sure you can make it work, I've heard good things from people who have used it.

I'm also guessing it has much more consistent and robust UI behavior compared to running things in a web view.

You'll have to find someone who has actually used it though to get a real opinion, I'm just speculating here.

For games when you want fast and cross platform with limited dev resources including browser; Haxe. Works well for producing fast and flexible code for games.

Would you be willing to elaborate on the reasons that make Haxe useable for games only?

I have been thinking about using it for some cross-platform UI components and would love to hear about the limitations that make it unsuitable for "normal" apps in your point of view.

What about Qt/QML, Xamarin.Forms and in fact Adobe Air/Flex?

For games? Or in general? I worked with both Qt and Xamarin (Forms ane Native) and both work well for apps as you get to know them. For games I would not use them although maybe just an OpenGL surface on either but that is not actually using them.

For regular apps. For games there are actually a lot better and more choices.

what do you think about libgdx?

I forgot about libgdx! It's a great framework and probably would have been perfect for the OP's use case. I'll add another clause to my list at the top.

EDIT: Nevermind, can't edit my root comment now so I'll just put it here:

Cross platform mobile games when you don't want to deal with C++, you don't need a full-blown engine + editor, and you're comfortable using lower-level APIs to get stuff done: libgdx

I view libgdx kind of the same as XNA, if anyone remembers that framework. It gives you the cross-platform abstractions you need (file system, audio, input, graphics) and even goes a little further by wrapping some popular 2D and 3D physics engines. Since it's Java, you can use it from your favorite language that runs on the JVM (looks like you can use Clojure, Scala, Kotlin, even python).

I've personally used it for a small game, and although I never finished it, developing with libgdx was a pleasant experience. You can develop it on desktop so you don't always have to deploy to a phone, and when you're ready it's easy to get it on a device.

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.

Your comment sounds very confused. Obj-C and Java are not "assembly language", and nobody writes games for iOS that don't use any sort of OS-level functionality. That's completely ridiculous. Especially because iOS provides multiple different APIs for high-performance graphics, such as Metal/OpenGL for 3D rendering and SpriteKit for 2D rendering.

Really the advice should just be don't use JavaScript and web technologies for mobile gaming.

I took "assembly language layer" in the parent comment to mean the "lowest-level high-level language" commonly available on the platform.

In android c++ binding is used to create high performance games and not Java entirely.

The fact that you may have understood what the grand parent meant does not mean he formulated it correctly.

I personally would recommend developing games in C++ for both platforms. You're not going to be heavily using any of the APIs that necessitate using Obj-C or Java. It's just OpenGL ES and other low level APIs. Additionally, it's easy to port between iOS and Android and you can use a much wider variety of libraries.

I always recommend Unity3D because the devs that would be comfortable starting in C++ with "raw" OpenGL already know their options and generally aren't looking for recommendations.

Usually when someone asks me "What should I use to make a cross-platform game", what they're really asking is "What tool can I use that won't get in the way of me making my game, that additionally allows me to target multiple platforms"

Yup, you can do things that'll start getting close to the metal with Java(arrays to keep caches warm, avoid allocations). However at the end of the day it's a huge pain and you lose the portability you get with C++.

>> you lose the portability you get with C++

Wouldn't Java be more portable than C++?

Not on mobile. You can embed compiled C++ code in both iOS and Android apps, but there's no easy way to run Java on iOS.

Is that the reason unity 3d is popular. Never thought c++ would be more portable than Java. But it makes sense now.

Maybe not "easy" but certainly quite possible (x2):

https://github.com/google/j2objc https://software.intel.com/en-us/multi-os-engine

Not if you don't have a JVM on your target platform.

> Cross platform mobile games when you have C++ skills: Use C++ with OpenGL and share most of the code.

I would recommend MOAI - gives you the best bang for the buck, as long as you're willing to learn Lua to do all the app-layer stuff, and leave the MOAI engine to manage the performance-critical resources...


But isn't this project dead? MoSync also comes to mind. It had a nice cross-platform C++ API.

Dead? No, far from it. Its still quite a powerful engine.

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.

C is always going to be faster than almost anything you compare it to, of course. But the V8 interpreter is also not 5000% slower; for computationally intensive tasks it's not actually significantly slower. The problem in OP's case is that JS lacks an interface to interact with the display and render that is as "close to the metal" as their "native" counter parts. You are drawing sprites on a html canvas which is then rendered by a web view, which just not that great no matter what language you use to get there.

What I'm getting at is that it's easy to blame Javascript, but really that's not the whole picture, and if Google and Apple chose to support Javascript natively it wouldn't have these dramatic performance issues.

> Google and Apple chose to support Javascript natively it wouldn't have these dramatic performance issues

What would "supporting Javascript natively" mean? If you mean AOT, classic AOT (without some pretty fancy research-level PGO or something) is not a viable compilation strategy for JS.

I do agree heavily with your overall point that the JS blame is misplaced. People often forget that JS is faster than Objective-C at important things like method calls for systematic reasons.

By supporting natively I mean provide a layer of APIs that let developers interact with the phone and in particular with the display at a low level, while still writing JS; I imagine that if you could draw on the screen bypassing canvases and html views entirely it would solve most issues.

You mean like NativeScript?


How would that differ from WebGL?

I assume the grandparent means access to UI APIs, not just drawing. I think there would still be significant performance drawbacks to "native JS".

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

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

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

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.

> That would be like benchmarking a language by seeing how fast it can add up integers.

So you mean like most language benchmarks. :)

WebGL has really high draw call overhead compared to native OpenGL. The rough rule of thumb is that you can do 2000% [0] the draw calls in a native app per frame than you can do in WebGL. It's not about execution performance it's about overhead of leaving JS and converting data to the format the GPU needs.

0 - http://floooh.github.io/2016/08/13/webgl-next.html

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

Probably because that's completely untrue, and would be irrelevant even if it were true.

If you're doing "drawing" (which in this case means blitting) on the CPU to begin with, you've already lost.

But this is beside the point. Firstly, I've been doing demos for years, so

1) it is possible, even at high resolutions

2) anything worth doing in opengl can't work in javascript for other reasons (mostly data size). And yes, you could download hundreds of megabytes worth of data files just to show an intro screen and then a few gigabytes for a game over an internet connection. I hope you have patient customers and a huge webhosting budget.

So let's be honest here : for small games, the effort of doing it with OpenGL/WebGL is not worth it. For large games it cannot be done, but for other reasons (that actually also apply to small games: 50 megabytes is incredibly oversized for a webpage, but still rather small for a game, so these problems actually overlap)

I myself feel guilty for stating this, but it actually works better to render the entire game server-side and videostream it to the client. Yes, javascript (and the web ecosystem) is that bad.

Is there no use for it ? Well, I appreciate the speed at which I can try out shaders locally. None of the niceties of javascript such as debugging or any sort of development process work, but it's still nice that you can get up & running in an hour or so.

But any reasonable game on javascript or the web platform ? Doesn't work and at this point it's so far from working it's a bad joke.

Who makes that argument? No one suggests that.

It's a cargo cult.

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

That only makes sense if the graphnics performance is actually the bottleneck of your game.

99% of the games I've seen have game design as the weakest link though, and sometimes art (it's not amount of polygons on the screen — it's how beautiful those polygons are). And if you actually want to improve on your game design, the metric you have to optimize is iteration speed — and the "assembly language layer" is rarely the best for this purpose.

Being a person who programs actual ARM/Neon assembly for both iOS and Android, your post is hilarious. ObjectiveC and Java are anything but assembly.

> get down to the platform's assembly language layer which for IOS is ObjectiveC

The assembly language layer for iOS is assembly language.

C combines the power and performance of assembly language with the flexibility and ease-of-use of assembly language.

Most high end games are developed in C++ for both iOS and Android with Java and Objective-C wrappers for things such as IAP's and Game Kit/Play Games integration.

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?

I'm currently using NativeScript and react-native for app development and I have to comment because items like <ListView> [1] and Grid-Layouts [2] can be done using both technologies which use native rendering and achieve 60 FPS. They both have listeners for common UI gestures. If you're building a normal app (no video game) with some forms, list views and maybe some diagrams, just use those. They give you a native experience and you don't have to build it for each platform - we're currently not in the state of "write once, run everywhere", but we're close. It's really easy to get started, please read about those if you're not satisfied with the current level of Cordova and Web apps.

I used Framework7 for a PWA (Progressive Web App) and it has a very lean learning curve if you already know web stuff and it was very easy to integrate e.g. Chartjs, so if you don't like react or NativeScript's XML you can also use HTML and plain Javascript, although the iOS 10 change is a bit troubling. I don't have any problems like a scrolling titlebar with it. Try and see if it fits your use case.

[1]: https://facebook.github.io/react-native/docs/listview.html [2]: https://docs.nativescript.org/cookbook/ui/layouts/grid-layou...

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.

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

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.

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.

Thanks. I assumed iOS was like Windows. Although Windows also has scroller controls that you create on the UI thread but delegate the actual event handling to the compositor.

A compositor can only do scrolling if the app is written with a retained mode API. The low-level APIs in Windows are immediate mode, whether GDI or Direct2D.

For most of time, ScrollWindow / ScrollWindowEx was how you scrolled. It doesn't know what to draw in the invalidated region because it's an immediate mode API.

In Direct2D you can use e.g. a translation to get the renderer to draw a bigger bitmap in a different section of the window, but you need to render the bigger bitmap (i.e. assemble your own retained mode). There's no free lunch.

I'm talking about the UWP/XAML/DirectComposition world, which admittedly is not game-related.

This app has nude images but I solved the "stupid rubber-band scrolling problem" be setting the <html> and <body> tags to fixed position.[1] I just wanted to share an example of this working in the wild and I only discovered it last week. I'm using Angular Material Design with a <md-content> tag which has overflow: auto and position: relative. This creates a scrolling bar inside of the fixed position body. It also creates some pretty weird side effects because HTMLElement.offsetTop remains static so none of the smooth scrolling JavaScript libraries work, so I had to role my own with a scrollToTop method.[2] I think it is because HTMLElement.offsetTop is computed relative to the parent which is fixed.

When it comes to scrolling two images they are jigging because the browser is handling the repainting instead of passing it off to the graphics card or chip. The only way to have smooth scrolling is to use translateX or translateY.

(Note: I don't know what I'm talking about and honest I just don't care.)

[1] https://github.com/adam-s/playboy-fm/blob/master/client/sass...

[2] https://github.com/adam-s/playboy-fm/blob/master/client/publ...

Ionic has done a good job of implementing standard UI idioms atop Phonegap.

Agreed, they've done a really great job and pushed it to the limits. Unfortunately they do not have support for even simple gestures, so the parent comment still applies -- afaict it's not possible with WebViews currently.

JavaScript lets you listen for multi touch events just fine with touch starts, ends, and moves, and lets you keep track of each finger separately. What gestures would it not be possible to implement with that?

The browser has a bunch of behaviors that get in the way. The Ionic team could speak better to what is preventing them from implementing these gestures, or you could browse their issues to get an idea too: https://github.com/driftyco/ionic/issues?utf8=%E2%9C%93&q=ge...

Here's the correct search link, which gives better understanding: https://github.com/driftyco/ionic/issues?utf8=%E2%9C%93&q=is...

10 open, 40 closed issues related to gestures in v2. It has not yet reached release stage, but already good enough to start the development of the new apps.

Do they have a ViewPager? A DrawerLayout? Swipable rows in lists (eg: to delete an item)?

Also v2 is not the best thing to point to because it's very new and I don't think many people are using it compared with v1. And closed issues don't necessarily mean fixed, eg: https://github.com/driftyco/ionic/issues/9052 -- I believe all WebView based apps suffer from the problem described in this issue.

ViewPager: if I understand it correctly, yes: https://ionicframework.com/docs/v2/components/#slides DrawerLayout: yes https://ionicframework.com/docs/v2/components/#menus Swipable rows - yes: https://ionicframework.com/docs/v2/components/#sliding-list

Every new technology is used initially by less people than something older. It does not say anything about it.

Regarding the issue you've mentioned, I think it can be fixed by HTML/CSS means.

Check out Framework7:


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

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.

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

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?

Part of the answer is that the App Store review process checks for sufficient text size. Web pages aren't subject to this process, and so are more likely to have overly small text. Certainly that's been my experience as a user.

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.

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.

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.

Blogger is the worst example. I'm basically unable to scroll an article without it interpreting it as a swipe, sending me to a different page, and losing my progress.

Because it's an expected feature of the web that has been in every browser since at least IE 3. If anything it is nasty that you can't pinch and zoom in apps, because there's no really good reason not to have it.

That said I prefer my text smaller, have my phone at the smallest font size and rarely zoom in on text. I also wish there was a "remove the pointless whitespace" option and that other ui elements got smaller along with the text, but I'm rambling.

You can actually adjust the font size on Android now, and it affects pretty much all apps.

You can increase the text size in accessibility settings.

I think this is something where webpages people open in safari and web-technology based apps people install as a little icon on their phone should probably be treated differently. I have run into unintended zooming as an app usability disaster as well.

It's great if there is text to read. It sucks if you built an HTML5 gesture-based game and pinching just zooms you into the middle of a <canvas> showing already-blown-up pixel art.

Now if it would only wrap pages when they zoom in the web might be readable without opera on an Android.

I agree this was a necessary step, and understand apple's justified aversion to adding more options/switches for their users, but maybe the website could pop up something that asked the users for permission to make the viewport unresizable?

Or make it an accessibility option in the settings (which is what chrome does on most platforms)

100% this. Blocking zoom was an annoying user-hostile behaviour that I'm glad is overrideable now.

Why outcry? I wasn't aware of the change, but if I had been, I'd have applauded Apple. Blocking zoom on web pages was super annoying, and I'm not sure why it was allowed in the first place.

This functionality change affects web apps running within Safari. If you care about accessibility on the web, you're likely to view this as a feature rather than a bug.

If you're building a "native" app that happens to uses web views as an implementation detail, as in this article, Apple explicitly exposes a property in the WKWebView API to revert to the former behavior. See: https://developer.apple.com/reference/webkit/wkwebview/14149...

Like others said, blocked zoom was the first cancerous tumor we had to remove. Now, time to get rid of those nasty autoplay ads.

Autoplay anything, in fact.

I love news sites that think a tiny window with a couple of video bobble heads commenting on something they're clueless about is content absolutely everyone must see. Whether they want to or not.

The same web based apps they originally saw as the future.

They never saw it as the future. Jobs just didn't want to give up control and they didn't want to release the real API too early as it was probably in serious flux.

I'm sure if web apps worked Jobs would hav been happy to leave it there. He was against iTunes on Windows, the move that made the iPod what it was.

It was in a flux. Dig back to look at the then remove brine headers to see the mess that the API was. It improved significantly for the official / iphoneos 2.0 release.

Good. Those web based apps suck. I want to be able to override whichever fool decided users shouldn't be able to zoom in on a mobile screen.

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.

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

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.

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.

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

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

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

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

In that example they are animating the "left" prop, which won't be hardware accelerated. Using "transform: translateX" will allow the animation to be hardware accelerated.

Agreed, when I first heard about PhoneGap it sounded amazing, then I tried and the performance hit is just too great, even for simple apps. Maybe in the future it'll be better, but not yet.

This is what people have been telling since 2010. In the future with faster phones the difference will be negligible or something along these lines.

This reasoning has been a bust for many years. As hardware specs go up, so doES the native UI become more demanding. Compare iOS 6 to iOS 10, from translucency to animation complexity to text rendering complexity. Now take web technologies and try to emulate the same complexity - it becomes more and more prohibiting. If anything, it gets worse and worse, not better.

So battery usage doesn't matter to you?

This is good advice. From the article:

> So I added a few more entities to the world. Suddenly, it was running at around 30 FPS. Yikes.

If your framework can't do simple OpenGL draw call batching, it's unsuitable for games. I'm not a huge fan of Unity (though it'll be a lot better when their version of C# is finally updated), but it's probably the best thing available for cross-platform game development.

Personally, after playing around with all kinds of game engines and frameworks, I always go back to Unity. It has a lot of warts and issues, but for me it's the most productive way to focus on actually creating games.

Have you tried SpriteKit? I chose SpriteKit with Swift for my first game and like it quite a lot, but I keep wondering if it was a good choice to limit myself to iOS.

What I'm interested in mostly is if I at least got a significant performance gain from chosing SpriteKit over Unity.

Try Cocos2d-x which is a multiplatform C++ implementation of the old Cocos2d-iPhone, SpriteKit was, at least partially, inspired from Cocos2d-iPhone.

The same author is working in Cocos2d-x and Cocos2d-iPhone, although Cocos2d-x is not owned by him.

    The same author is working in Cocos2d-x and Cocos2d-iPhone
That was in the past, AFAIK Ricardo works only on Cocos2d-x now. Cocos2d-iPhone is community driven now.

I'm not sure about the performance differences, but there was a different reason that kept me away from switching to Unity. I've built a couple games in SpriteKit doing it entirely programmatically in code and realized Unity is not setup to work that way at all. If you have experience using SpriteKit Scene Editor then you might not be bothered by that, but I was. Instead of Unity I'm using MonoGame now since it is meant to build the game using just code and I find it was a lot easier to jump into using my existing knowledge from SpriteKit

The problem is that JS perf is so much worse on Android, and adding insult to injury, the single threaded perf of the very fastest Android devices are less than half an iPhone 7. Worse still, Apple devices get upgraded aggressively, whereas Android devices don't, so the long tail of very old very slow devices (mobile devices age in dog years) is enormous. Sad but true.

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 Docs: http://docs.gameclosure.com/

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.

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 Playable: http://rogueskib.github.io/orcrun/

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)

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

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.

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

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.

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

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

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

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

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

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.

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.

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.

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

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.

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

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.

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.

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.

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

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.

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.

Disrespecting your users has very little to do with the tool you use and everything to do with how you use it. One can also be pedantic/fanatic about going by the book to the letter in order to conform with every one of the platform UI's "laws" and still generate a crappy application due to lack of insight on what will be intuitive or useful to the end user. No - a sub-par product will mostly have a sub-par developer responsible. Quality and craftsmanship will come across no matter what technology you decide to use. That's not to say that a good developer couldn't produce an even more polished experience with native programming, but as mentioned before, I doubt the difference is noticeable enough for many applications to justify the dramatic increase in learning curve and maintenance.

"This kind of disrespect for your users' ability to notice crap is what I dislike most about lazy cross-platfom developers."

A lot fewer people actually care about UI minutia than you imagine.

Why Framework7 and not Ionic 2?

Frankly, because I didn't want to learn Angular when I first encountered Ionic. Ionic might be great though, it's just that I have no experience with it yet to say one way the other.

I had similar concern, but after trying F7 switched to Ionic 2 and learned Angular 2: F7 architecture isn't flexible enough and it's not production ready overall.

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.

I'm currently trying out Flutter, so far it seems pretty great. https://flutter.io/

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.

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?

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.

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.



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.

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

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

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.

C# and F# are the first two that I can think of that can do all the things you mentioned pretty well.

If you're just breaking into a new topic (such as game development), I find it very understandable to not want to learn a new language at the same time.

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... and an earlier web version is at http://matt-williams.github.io/ld29/

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.

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.

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.

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

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

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.

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.

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.

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.

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

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

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.

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.

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

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:




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?

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://itunes.apple.com/us/app/lichess-free-online-chess/id...

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

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.

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

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

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

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

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.

Is this the FNA you're talking about? https://fna-xna.github.io/

If you wanted to use JavaScript, use something like Cocos2D JS: 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.

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

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?

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

Well, personally I'm not dead set on non-native code, just thinking of ways to make something "cross platform" this is close enough to native code to make other team members comfortable. Personally, I'm the type to just write native code first as I believe it skips lots of the quirky situations as mentioned in the post. So I completely agree.

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

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.

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?

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

How is running in Safari better than using WKWebView?

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

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.

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.

Native APIs were not standing still either.

Ionic is doing pretty well (basically Cordova + Angular + standard UI directives)

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

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

Some people are saying: 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...

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

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.

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.

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

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.

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

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?

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?

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.

I was explicitly referring to trying PhoneGap.

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

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.

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

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

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

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

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

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

I just tried out Defold engine and it was super easy to get started with and well documented.

Try the Godot engine, you could be up and running in less than one hour.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact