I made an iPhone game with PhoneGap and won't do it again
bokstuff.com
bokstuff.com
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.
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.
Im an Aussie, my 'flagship' version is specific to Australian weather. I have weather apps designed for other countries as well.
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
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.
http://cmichel.io/lessons-from-building-first-react-native-a...
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:
https://github.com/Day8/re-frame
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.
I'll shut up now and write something up once I deploy an app to multiple platforms ;)
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 :)
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.
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.
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++.
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.
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.
Performance is pretty good, and the UI is entirely native Android.
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 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.
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.
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.
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.
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.
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.
Wouldn't Java be more portable than C++?
https://github.com/google/j2objc https://software.intel.com/en-us/multi-os-engine
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"
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...
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.
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.
...that's not how graphics benchmarking works. That would be like benchmarking a language by seeing how fast it can add up integers.
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.
So you mean like most language benchmarks. :)
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.
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.
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.
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.
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.
The assembly language layer for iOS is assembly language.
Really the advice should just be don't use JavaScript and web technologies for mobile gaming.
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?
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.
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.
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.
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.
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.
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...
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...
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.
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 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.
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.
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.
But I've never seen an app present me with the equivalent of 3pt text by default.
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.
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.
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...
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.
What I'm interested in mostly is if I at least got a significant performance gain from chosing SpriteKit over Unity.
The same author is working in Cocos2d-x and Cocos2d-iPhone
> 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.
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.
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 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.
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.
Github: https://github.com/gameclosure/devkit Docs: http://docs.gameclosure.com/
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.
Source: https://github.com/rogueSkib/orcrun Playable: http://rogueskib.github.io/orcrun/
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.
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 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.
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.
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.
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)
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.
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.
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.
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...
Most non-dev users want to get some stuff done via apps and don't care about design details.
A lot fewer people actually care about UI minutia than you imagine.
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.
In fact, other than using a premade engine like Unity, I'd say that's the only sane way to do mobile development.
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://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.
Hell, in most of the platforms you can use your language of choice and P/Invoke C++ components.
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 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.
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.
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.
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.
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.
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#)
(Maybe things have improved, this was when the game was pretty new.)
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://itunes.apple.com/us/app/tien-len-pro-tsd/id116761625...
https://play.google.com/store/apps/details?id=org.lichess.mo... https://itunes.apple.com/us/app/lichess-free-online-chess/id...
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.
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.
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.
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)
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.
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?
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.
Also everyone had to build UI from scratch before Ionic and other frameworks, and that was just crazy.
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.
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.
Keep it simple (C++ and OpenGL or Unity) and you'll be much happier imo. Leave the constricting frameworks and dependencies at home.
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.
Hopefully the author attached macOS Safari to his iOS device to do some basic debugging and profiling.
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).
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?
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'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.
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...