Moving away from Cordova?

Post reply
1 favourites
  • 6 posts
From the Asset Store
Neves's Multiplayer Move click + directions + Skins
$12 USD
This is a code so you can see the same skin on all screens (peers). Each peer gets a skin, in addition to 4 directions t
Nevesbr's avatar
Nevesbr

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

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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