Moving away from Cordova?

Post reply
Not favoritedFavorited Favorited 1 favourites
  • 15 posts
From the Asset Store
Device Detector
$4.99 USD
Cordova device Info mobile and browser modules detect-gpu
EMI_INDO's avatar
EMI_INDO

  • I think it‘s well established that Construct 3 games don‘t run that well on android and iOS. Partially, this is because the System Webview for android suffers from performance issues, such as a frame scheduling bug.

    I feel like it might be worth it to transition away from Cordova in the long run. I don’t think performance would be a lot better on a new platform, but significantly so with more modern APIs, less plugin related bugs (have experienced so many loading bugs, memory leaks etc. coming from Cordova plugins) and overall a smoother experience.

    An option that I found to be interesting is Capacitor, which is backwards compatible with Cordova, has full PWA support if needed and uses far more up-to-date APIs in many areas. It‘s also open source and well maintained.

    Regarding TWAs that don‘t use the System WebView at all, I‘ve discovered that Google has released a billing API that might be worth taking a look at. Trusted Web Activities are significantly more performant than Webview Apps at the moment and it could be an interesting option to add to the Construct Export window.

    My hopes are still up that Google will update the Webview to be on par with the Chrome browser and fix the jitter issue. Moreover, I sincerely hope that WebGPU will become useable for Construct games in the near future, as it‘s basically non-functional (iOS) or extremely sluggish (Android) as of now.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Great suggestion!

    It definitely got worse at least from the iOS side. Every iOS update there are several issues. And also they dont even replay the bugs as you found out in your last bug report about the canvas shift down that we reported long ago. This led me to postpone the iOS release for quite some time till it's fixed. It becomes very unreliable.

    Another idea if they dont want to get away from Cordova, is why not support one more platform from the ones that you pointed out so we can test it and then if it works better then you can always remove the Cordova platform in the future. This at least will give a few alternatives.

    Scirra always say resources are tight so not sure if this ever gonna happen.

  • Thank you for your reply, I fully agree on that one.

    Though, I feel like iOS is quite a big platform that shouldn’t be overlooked by Scirra. Probably, most Construct games are being developed for PC, but part of that certainly is due to the lackluster compatibility with mobile platforms.

    I‘ll plug my feature request for adding a Capacitor export option here:

    github.com/Scirra/Construct-feature-requests/issues/382

  • I agree i does have a bug.

  • You can of course already now use capacitor instead of cordova for your construct games. But it has absolutely no advantages.

    Ionic built Capacitor on the Cordova libraries. Thats why you often can use the same plugins.

    So if you claim you have memory/performance issues with cordova you will have the same with capacitor.

    Just try it.

  • We could try moving to Capacitor, but it would probably be months of complicated work; if we dropped support for Cordova it would probably be highly disruptive as there would be a bunch of difficult backwards-compatibility issues; if we kept support for Cordova now we're maintaining two mobile exports which is a permanent drain on resources and focus; and then, as no software is perfect, we'd probably find Capacitor has a bunch of its own quirks and issues. In a worst-case scenario we have to do months of disruptive work, and the end result is no better, or even possibly worse. Often it can seem the grass is greener on the other side. We do occasionally shift between technologies, such as our current effort to move away from NW.js, but that has literally been years in the making (Windows WebView2 came out about 3 years ago) and it's much clearer there are significant gains to be had after completing the transition.

    Meanwhile bugs can be fixed - I expect Google will sort out the frame scheduling in the webview sooner or later, and if anything else comes up, make sure the issue has been filed and reported well (following all the guidelines). Fixing even a whole bunch of difficult bugs still likely works out as less work than moving to a whole new mobile framework. I think you can also try out TWAs already - they're based off web exports - see the TWA documentation here. It would be interesting if people tried that out and reported how it worked. For example if lots of people are already using TWAs and reporting that it works great, then we could more seriously consider improving support for it. But that approach doesn't support Cordova plugins - so what happens to all the advertising plugins for example? If we move to Capacitor, it still uses the Android Webview - so bugs with the webview would still need to be fixed. So it's not clear that any other approach will actually be better - which is why I think it's better to focus on making sure any bugs are fixed.

  • Hi there,

    I wish they'd ditch CORDOVA. I started making games with a Mac version of GAMEMAKER (GM), but you couldn't do anything. Back then, CONSTRUCT version 2 was available, and it wasn't compatible with Mac. Then I "discovered" BUILDBOX, bought it, and made some money off it, but it's very limited. I tried UNITY (very good, and its community is large), but I wanted to focus on making games and not learning to program, and although they say C# is difficult, I found it fun to learn.

    I always wanted to try (GM), but it wasn't available for Mac until GMSTUDIO. I bought it, but I didn't like its workflow. CONSTRUC 3 came out, and boom! Very good and intuitive, but since not everything in life is perfect, it uses CORDOVA to export to iOS and Android. That's my niche. I even pay $99 from my Apple developer account because that's my target.

    I know the CONSTRUCT team is small, however, I think the BUILDBOX team was smaller and didn't use CORDOVA. I understand how difficult it is to change a program; you can see it in banks or government agencies that use programs with older programming languages.

    I'm thinking of stopping my CONSTRUCT 3 subscription. I only paid it last month, and I'd lose the discount I have because I'm only paying $99, not $129.99. Everything comes with its own risks.

    I've seen Godot, which is very good, and its programming language is simpler than C#. Although I feel more comfortable with C#, I'm thinking of going back to UNITY and using Playmaker or another similar tool. I'll learn it well. I'll have a year to think it over. I'm very grateful for CONSTRUCT 3, though. I've learned a lot, and I congratulate the team for making the dream of creating video games a reality for many.

    Very respectfully,

  • I don't really get your point. Construct 3 is a JS game engine, so you can't compile the code and just ship binaries like with some other languages. You'll always need a WebView, which isn't necessarily a problem – the situation on iOS and Android is far from perfect, but it has been improving for a long time.

    I just feel like Cordova is no longer being properly maintained and many of the plugins start to break. On the other side, CapacitorJS is what everyone is moving towards, which has amazing first-party plugins, fast updates, and modern code. No Swift version issues, better and more modern plugins, simpler project structure. A lot of wins in my book.

    But it still uses a WebView (there's no way around that).

  • I filed a feedback request in the feedback repo:

    github.com/Scirra/Construct-feature-requests/issues/382

    Feel free to give it an upvote :D

  • I filed a feedback request in the feedback repo:

    https://github.com/Scirra/Construct-feature-requests/issues/382

    Feel free to give it an upvote :D

    No! I don't want CapacitorJS neither. Maybe the Construct Team gets the point. I prefer that they continue using Cordova, the day they abandon Cordova, let it be for something much better than Cordova and (for sure) CapacitorJS. I'd rather they continue using Cordova; the day they abandon Cordova, let it be for something much better. Something native. By using Cordova (Construct 3, GDevelop, and Phaser 3), they're creating a hybrid file/app, and that's why they use WebView (Hybrid apps)... Unity, BuildBox, Godot, etc... They don't use WebView in their exports. It compiles the game into a native application. That's a big difference in my book.

    But as I mentioned earlier and used the example of bank and government software, they're old, and rewriting a program from scratch isn't easy, and it's even more difficult when the current one works. That's why I understand the Construct 3 team. Sometimes, when you fix one bug, you discover five more.

  • I think you don't understand the issue at hand. They can't move away from WebView as a JS based engine. Construct 2 used a different programming language and an entirely different tech stack.

    JavaScript being an interpreted language isn't the issue. It's the graphics API that historically kinda sucked for browsers. WebGPU is a big step in the right direction but still not quite there yet. I'm confident that at some point, performance will be like native through the browser graphics APIs.

  • I'd like to share a bit of my experience: I have been building projects with Construct 3 using Capacitor and Framework7 since 2023. If anyone is interested in experimenting with this setup, I plan to create some brief documentation.

    Compatibility and Configuration

    All Cordova plugins are fully functional in Capacitor. However, it's important to note that Capacitor does not support variables in plugin.xml. You can manipulate these Cordova variables using hooks/scripts instead.

    Capacitor also replaces config.xml with capacitor.config.json. My workflow is as follows:

    1. Export the project from Construct 3 as a Cordova project.
    2. Use a hook/script to port the package.json configuration into capacitor.config.json.

    For example, the script would take this data from your Cordova project and automatically generate a capacitor.config.json file like the one below: 

    {
 "appId": "io.cordova.hellocordova",
 "appName": "HelloCordova",
 "webDir": "www",
 "bundledWebRuntime": false,
 "plugins": {
 "AdMob": {
 "APP_ID_ANDROID": "ca-app-pub-3940256099942544~3347511713",
 "APP_ID_IOS": "ca-app-pub-3940256099942544~1458002511"
 }
 }
}

    Additionally, the icon URI paths are different in Cordova and Capacitor, so the hook/script must be designed to handle this automatically.

    Differences in Plugin Installation

    The way you install plugins is also different. For example:

    • Cordova: cordova plugin add plugin-name
    • Capacitor: npm i plugin-name

    For simple projects, the difference between Cordova and Capacitor might not be very noticeable. However, on larger projects, the difference is quite significant. I personally prefer Capacitor because its code is based on JavaScript modules, which feels more modern and structured. It took me over a month to get used to the Capacitor workflow, but the results have been well worth it.

  • Challenges and a Suggestion for the Future

    As a suggestion for an initial step, it would be very helpful if a future version of Construct 3 added a direct export option for Capacitor. At a minimum, this option could generate a basic capacitor.config.json file. For the rest of the process, such as building the app, users could then proceed locally/manually.

  • By the way, is that WebView jank issue fixed now? They said the rollout was supposed to happen at the end of July.

  • As a suggestion for an initial step, it would be very helpful if a future version of Construct 3 added a direct export option for Capacitor. At a minimum, this option could generate a basic capacitor.config.json file. For the rest of the process, such as building the app, users could then proceed locally/manually.

    I highly agree, I think this solution is easier than fully supporting Capacitor (hence doable by Construct team) while also gives something to the advanced users. Win-win.

Post reply
  • 15 posts
Index icon Return to board index
Jump to:
Active Users
There are 0 visitors browsing this topic (0 users and 0 guests)