For Electron apps it's all much easier because all native code is heavily tested by other commercial software and there is even on-the-fly updates possible.
PS: I shipped C++ apps built using Qt and cross-platform part is huge time sink.
>If your Qt app has single C++ line of code cross platform builds become much harder.
As I mentioned, Qt has an extensive cross-platform API; indeed that API is Qt's value prop. If you've the need to write arch/platform-specific UI code, then it's very likely you'll find the solution to that problem somewhere within Qt's docs. If not, then you cannot expect to be able to write such code using Electron/JavaScript.
>Also regardless you still have to solve packaging and updates for Windows, macOS and Linux.
What's to solve? Qt has had these capabilities. If you describe a specific issue, you may have an argument, otherwise this statement makes no claim.
>Also it's much harder to do QA and it's take much more effort to maintain cross platform Qt app in general.
How so? This is such a broad and unspecific claim to the extent it isn't possible to form a counter argument. State specifically the issues making it much harder to complete these tasks using Qt.
>For Electron apps it's all much easier because all native code is heavily tested by other commercial software
Qt's testing suite is extensive. Qt is and has been deployed and "heavily tested" around the world for years. Qt is also deployed as an embedded technology.
>PS: I shipped C++ apps built using Qt and cross-platform part is huge time sink.
I'm not sure you spent much time doing this because Qt makes shipping cross-platform software so simple it sometimes feels like I'm cheating (there are exceptions when dealing with very specific platform/arch-specific items as I mentioned above; there is no solution in JavaScript.). There must be some specific issue(s) you came across, but without specifying what specifically made you perceive using Qt a huge time sink, the statement makes no claim.
What is a Qt app without a single C++ line of code? Is it written in PyQt? Or did you mean a single C++ dependency? I assume you meant that, based on your later comment saying "if you take single external non-Qt library it's will make builds, deploy and testing so much more harder".
> For Electron apps it's all much easier because all native code is heavily tested by other commercial software and there is even on-the-fly updates possible.
I've had the opposite experience; if you can build your own application code using CMake, and link it with prebuilt Qt on a set of platforms, bundling extra libraries vendored with your program and built from source each time is not significantly more difficult than making your own "build from source" work.
On the other hand, in my experience with Python's native modules and observing others working on Electron Node native modules, if you're depending on prebuilt native binaries (the alternative is building native extensions from source, requiring everyone building your app to have a JS/Python toolchain plus a C++ toolchain that the JS/Python can find), you are at the mercy of the maintainer of the native extensions to fix bugs for you and release prebuilt binaries. That's unless you build and host your own native binaries with your own bugfixes and tweaks.
Can you see any issues with this on either Electron or QT? At first glance it feels like both should ok.