[HN Gopher] Show HN: Svelte NodeGUI, a lightweight Electron alte...
___________________________________________________________________
Show HN: Svelte NodeGUI, a lightweight Electron alternative with
native UI
Author : LinguaBrowse
Score : 203 points
Date : 2021-03-05 20:10 UTC (2 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| f430 wrote:
| How do you deal with zero day vulnerabilities? To me the biggest
| concern using browser-as-a-desktop solution is that there will be
| quite a lag between when Chrome patches zero days vs when it gets
| released.
|
| ex) nw.js, electron.
| ZachS wrote:
| What sort of vulnerabilities are you worried about? You're
| running trusted code, connecting to a trusted service via
| https. Not browsing arbitrary websites. I doubt many
| vulnerabilities would affect this.
| endisneigh wrote:
| Is there a way to have some small application that talks to the
| machine via a set of HTTP apis?
|
| I envision something where you can just use your regular web app,
| have the user install the "Desktop Connector" which would be
| listening at say, port 8000 - then your web app can talk to the
| desktop via those APIs, instead of installing an Electron or
| related.
|
| I must be missing/forgetting something crucial since that seems
| like the most straightforward solution imaginable.
| beaconstudios wrote:
| the HTML5 JS APIs provide most desktop functionality you could
| want to access from the browser - does that cover what you
| mean? Reading location, video & audio, interacting with local
| files, that sort of thing.
| frosted-flakes wrote:
| Stuff like global keyboard shortcuts still isn't possible
| though. And you're stuck with the browser's notification
| system.
| danenania wrote:
| There's nothing stopping you from doing this with a server on
| localhost. You just need to think a bit about security (and be
| _extra_ careful if you 're running a websocket server since
| they don't do origin checks by default).
| LinguaBrowse wrote:
| Yep, you could make an HTTP server using Express.js, and a
| minimal GUI to go with it!
|
| Of course, it could run headless, too. But there is attraction
| in making it an app that opens like familiar executables.
| julienb_sea wrote:
| I mean you are basically just describing a standard local
| development setup, so in a lot of ways this is trivial. The
| trouble would be trying to package that up in user-friendly
| manner. It's definitely more work than it's worth, in a world
| where most people have computing resources to spare on a heavy
| framework like Electron.
| ficklepickle wrote:
| Dell uses this exact technique on Windows to launch/interact
| with their driver installation tool from the web. That has
| decent UX because it comes pre-installed. But, generally, users
| aren't accustomed to this pattern and any user education
| requirement is often a non starter in many market segments.
|
| It also has security implications if you are exposing OS
| functionality to websites. I remember Dell having a bad one a
| couple years ago.
|
| There is also an antivirus browser extension that works in a
| similar way. It installs a native C++ executable that the
| extension interacts with. That has a huge security footprint.
| IIRC they rolled their own parser (HTML?, JSON?) and it went
| predictably bad.
|
| There are lots of implications to consider. I'd like to see
| progressive web apps fill this niche on the desktop. They have
| various mechanisms for persistence of data and WASM will
| increase the practical use cases. Hopefully the APIs available
| to PWAs in the future will allow all sorts of new use cases.
| jackconsidine wrote:
| Very cool, I've been following React-NodeGUI for about a year now
| and I love Svelte.
|
| I especially love the idea of Svelte (compiling to imperative
| JavaScript code), but since it's technically a "superset" of
| JavaScript, IDE support has been an issue for me. Also I've cut
| my teeth trying to find a solid UI component library. These two
| things have restricted my use of the framework to smaller
| projects.
|
| Anyone have any suggestions?
| LinguaBrowse wrote:
| In terms of IDE support, VS Code with the Svelte extension is
| the best around!
|
| A component library is a bit much to come until Svelte NodeGUI
| gets a bit more attention. Even Svelte web projects are
| underpopulated on component libraries, I believe. But it's
| worth trying out the built-in primitives first!
| omneity wrote:
| It's unfortunate but the component library situation is really
| Svelte's weak point currently.
|
| At Monitoro[0] we bit the bullet and implemented the vast
| majority of our components from scratch. Apart from the obvious
| time to develop and test, and the trailing bugs that are hard
| to solve for small closed source projects, the experience
| wasn't that bad.
|
| Ultimately what helped us the most is writing our components
| using a state machine-like pattern, mixed with TailwindCSS to
| make styling easier.
|
| In our case, the effort was worth it as we anyway needed
| several super specific components, and now that we're over the
| hill we have complete control on our UX.
|
| (Also having built component libraries/design systems before in
| different UI frameworks, doing it in Svelte was one of the best
| experiences so far)
|
| There are some efforts in the Svelte ecosystem but they're
| small and do not have much firepower behind, thus limited or of
| relatively low quality.
|
| [0]: https://www.monitoro.xyz
| jackconsidine wrote:
| Word, thanks! I think it's interesting because Svelte
| community support is pretty big. The repo's consistently been
| on Github's Trending repos for the past 2.5 years and it has
| an impressive number of stars
| zeroc8 wrote:
| No suggestions, unfortunately. The lack of a comprehensive UI
| component library a la PrimeReact/NG/Vue really is a
| showstopper. Doesn't have to be free. But component providers
| do not seem to care about Svelte.
| danenania wrote:
| Looks really good! At first glance, this seems like probably the
| best Electron alternative I've seen posted on HN.
|
| Apart from the consistent GUI layer, I think an underrated reason
| that many teams stick with Electron is the mature tooling for
| cross-platform builds and upgrades. It's pretty painful to DIY.
|
| It looks like NodeGUI doesn't currently support cross-compilation
| --is that something that's on the roadmap? How about
| upgrade/auto-upgrade tooling? Code signing?
| davej wrote:
| Strongly agree. Hello World apps are great but it would be
| great to see a Hello World tutorial that can actually be
| distributed to customers. You probably also need auto-update,
| native installers, code signing (notarization on Mac) and the
| ability to build native modules cross-platform.
|
| This is a super-interesting project though.
| gigel82 wrote:
| I've been following react-nodegui since it was announced and I
| really like it. In terms of memory usage it's the cat's meow; now
| there's a question of adoption and component / UI libraries for
| the ecosystem.
|
| Perhaps a way to bootstrap that would be to align closer to
| react-native; at that point, we could use (js) components and
| libraries from react-native land.
|
| The QT licensing question is also somewhat iffy; you need to put
| front and center what that implies for users of your library (do
| they need to open source their use of react-nodegui by extension
| of QT's licensing requirements for example).
| jart wrote:
| I'm seeing a lot of Qt vs. Chromium in this thread. Here's your
| mindblown.gif of the day: Chromium is based off Webkit which is
| based off KDE which is based off Qt.
| https://en.wikipedia.org/wiki/KHTML
| anthk wrote:
| On GUI's, if Go had some GUI a la inferno (no, not the crap of
| node, the one from the Unix/C/Plan9 guys), it would be the best
| thing ever on interfaces.
| rado wrote:
| Calculator demo doesn't run, makes some cmake errors.
| gigel82 wrote:
| The react-nodegui calculator example runs fine for me; on Win10
| x64 it uses 14.4Mb of RAM and spawns a single process.
|
| Really impressive resource-wise, now let's get the UI
| components / frameworks ported...
| karteum wrote:
| This looks nice !
|
| However... "Low CPU and memory footprint (...) memory usage is
| under 20 MB for a Hello World program" : I am the only one who
| still thinks this is huge ? (->
| https://tonsky.me/blog/disenchantment )
| agumonkey wrote:
| It's probably to be put against Electron HelloWorld resources
| usage. If this project manages to cut it in half then it's a
| good step. Maybe competition will cut it in half once more.
| Considering the amount of Electron based apps around it can
| save quite a few GB worldwide :)
| lhorie wrote:
| That actually sounds kinda impressive, considering [0] says a
| minimal standard Qt hello world app is ~5mb and stock node.js
| is ~100MB.
|
| I'm curious what kind of magic is happening where node.js is in
| the picture yet the executable comes out at ~20MB. Is it simply
| a bundle of wrappers for most of Qt with Node.js being required
| to be installed separately? Is it purely UPX compression?
|
| [0] https://stackoverflow.com/questions/450455/minimal-qt-
| execut...
| mrwoggle wrote:
| I just made hello world window in qt. It's 28 kB. edit: typo
| jart wrote:
| 28kb? You're only seeing the tip of the iceberg. I just built
| Qt Hello World myself. It's about sixty megabytes in size.
| jart@debian:~/scratch/qtproject$ qmake -project
| jart@debian:~/scratch/qtproject$ make
| jart@debian:~/scratch/qtproject$ ldd ./qtproject | grep -Po
| '(?<==> )[^ ]*' | xargs ls -alH | awk '{x += $5} END {print x
| / (1024 * 1024.)}' 59.5916
|
| That's bigger than I expected to be honest.
| fabiospampinato wrote:
| The thing is nobody actually uses hello world programs, by
| the time you build a real application the difference in RAM
| usage between that and a good Electron app for example blurs
| significantly.
| inetknght wrote:
| I disagree. I remember using lots of GUI apps within a 96MB
| budget 25 years ago -- even browsers.
|
| Electron does not provide that much more desired features
| than apps from 25 years ago.
| fabiospampinato wrote:
| You can make a very decent Electron app with roughly
| (roughly = ~2x or less) that amount of RAM too if written
| well, for that you get pretty much a codebase that you
| can use everywhere, which on it's own is _massive_.
| ficklepickle wrote:
| I've noticed Signal Desktop only uses 100mb. That is
| quite good for an electron app. A simple server-side node
| process will use at minimum ~20mb, which obviously does
| not include a browser.
|
| It's open source, I've been meaning to poke around and
| see what they are doing differently.
| fabiospampinato wrote:
| There's no secret really, just don't import junk
| dependencies like most people do and spend some time
| inspecting your memory usage every now and then, with
| very little effort you'll probably cut down on your
| memory usage significantly by doing that. With a lot more
| effort often you can probably even make something faster
| than uses less memory than a supposedly native app (if
| they spent less time than you optimizing it).
| tuxychandru wrote:
| Signal desktop runs as multiple processes. Did you add up
| all their memory consumption? On my Debian laptop, Signal
| processes consume about 700 MB of RSS in total,
| immediately after starting.
| MaxBarraclough wrote:
| > Electron does not provide that much more desired
| features than apps from 25 years ago.
|
| That's true, but advanced GUI features aren't Electron's
| selling point. It's used because it offers easy
| portability and the ability to leverage web-dev skills.
| fouric wrote:
| What does Electron offer in terms of portability that
| SDL2 doesn't have?
| korijn wrote:
| NodeGui (which is used here) is also running on Qt.
| pier25 wrote:
| A couple of years ago we switched an Electron/Cordova
| application to the native OS Webview (WKWebView on macOS and
| iOS, etc). The UI was written with Inferno + MobX and the
| backend in Swift/C#/Kotlin depending on the platform.
|
| IIRC on macOS it consumed less than 15MB.
| pqb wrote:
| @tonsky is right about the huge memory footprint (in terms of
| RAM) but 20MB for Hello World GUI program is totally fine today
| [0]. In my humble experience there is really hard to fit in
| below 10MB with a GUI app that only displays "Hello World"
| text, while the next 10MB are often consumed for extra
| resources like font, rendering cache or custom textures.
|
| It might a bit rude to remind that, but the same person saying
| aforementioned words about huge memory usage promotes the Skija
| [1], Java-based GUI toolkit, which is even worse in memory
| consumption than electron (jb-compose provided examples, even
| in release builds).
|
| [0] Memory Footprint of GUI Toolkits -
| https://szibele.com/memory-footprint-of-gui-toolkits/
|
| [1] Graphics for JVM - https://tonsky.me/blog/skija/
| fouric wrote:
| 20 MB is less than 0.25% of my desktop machine's memory, and 2%
| of a 2010-era netbook. 20 MB, while much larger than what it
| has to be, is tiny even by the standards of decade-old
| computers.
|
| RAM is cheap and plentiful. If you don't use it, its value is
| almost zero (the "almost" comes from OS-level caching of files
| and CPU-level cache misses of code).
| mixedCase wrote:
| It's definitely not. It's just a different toolkit that the one
| you already have in memory, so it can't "cheat".
| afavour wrote:
| That blog post does speak to me, but 20MB for a program with a
| truly functional, modern UI doesn't outrage me that much.
|
| IMO there's a tradeoff: we could be writing all our programs in
| C, still. But it would be enormously difficult and there'd be
| way more bugs. On the other end of the spectrum we can be lazy,
| use web tech everywhere and never optimise our ballooning JS
| codebases. This feels like it's at least somewhere in the
| middle.
|
| OT but a bone to pick with that article:
|
| > Modern text editors have higher latency than 42-year-old
| Emacs. Text editors! What can be simpler? On each keystroke,
| all you have to do is update a tiny rectangular region and
| modern text editors can't do that in 16ms. It's a lot of time.
| A LOT.
|
| That isn't what my text editor is doing, though. It's doing
| autocomplete suggestions, linting code as I type... all sorts
| of things we never had a couple of decades ago and are huge
| productivity boosters. Sometimes I feel like people forget
| that.
| throwanem wrote:
| Emacs does those things too, these days. It's still snappier
| than anything else I've tried recently.
| unknown2374 wrote:
| _cough_ vim _cough_
|
| I'm just kidding. Don't want to start a fight here.
| unknown2374 wrote:
| As mentioned in the other comment, emacs does those things,
| and so does Vim (with plugins of course).
|
| I moved from sublime to atom to VS code, but eventually
| settled on Vim because I was able to get the same features
| (that I used) while getting almost instant response. A
| feeling that has completely changed how much I enjoy writing
| any sort of text.
| anthk wrote:
| >all sorts of things we never had a couple of decades ago
|
| We had them.
| setr wrote:
| However, most of that should be done in the background -- it
| shouldn't affect your actual text input speed. Auto-format is
| more along the lines of something that could be blocking, but
| we're not dealing with latex problems as to be significant
| andylynch wrote:
| Even putting that aside, just showing text on a screen is
| much slower on modern PCs then older ones, since you have a
| far more complicated graphics stack and latency at several
| added steps.
|
| I remember an article a couple of years ago where someone
| rigged up a camera to measure key press to screen update on
| different machines and the results were eye opening.
|
| edit: found it http://danluu.com/input-lag/. The Apple ][
| ties for first place with an iPad Pro.
| esperent wrote:
| > The Apple ][ ties for first place with an iPad Pro.
|
| * When used with an Apple Pencil (30ms). When used with
| touch it drops to 70ms.
|
| Also, it's worth noting that there's a very limited list
| of devices tested there and it heavily skews Apple.
| jart wrote:
| Are you referring to this submission?
| https://news.ycombinator.com/item?id=23369999 Outstanding
| article. Total shame it only got 100 upvotes.
| fao_ wrote:
| Related, my favourite thread to come out of the queer
| tech circles:
|
| "Almost everything on computers is perceptually slower
| than it was in 1983" https://threadreaderapp.com/thread/9
| 27593460642615296.html
| jart wrote:
| Help me build Cosmopolitan Libc. We're using modern compilers
| to build programs that are tinier and more portable than
| anything developers even as far back as the 70's or 80's were
| able to produce. https://justine.lol/cosmopolitan/howfat.html I
| built a LISP interpreter too, which makes Altair BASIC look
| bloated by comparison. https://github.com/jart/sectorlisp I
| will say that 20mb isn't too shabby if we judge the OP's
| project by Electron standards. If NodeGUI was pruned a bit
| more, it wouldn't be too far off from where Go is at right now
| for Hello World on the console. Although one does have to take
| into consideration that it assumes external dependencies are
| available such as V8 I assume? Does it statically build? One
| thing I'm curious about is I looked at the yarn lock file and I
| couldn't find Qt so I have no idea where it comes from.
| caslon wrote:
| If we're only interested in one/"not-Mac/Win/FreeBSD" of
| those platforms, how small could we get programs down to? Is
| forgoing certain platforms supported?
|
| Also, there was a really fantastic question asked in the last
| Cosmopolitan thread, but it wasn't answered; what's the
| answer to it?
|
| https://news.ycombinator.com/item?id=26294721
| jart wrote:
| If you uncheck the boxes on the "how fat" page I linked
| above, then static binaries for a single platform usually
| end up being 4kb. Most of that 4kb is padding nops to page
| size. The question you linked is now answered.
| kitd wrote:
| I can't remember the precise mechanism, but IIRC the base
| NodeGUI pkg downloads and builds a minimal QT, and then links
| into it using NodeGUI/qode which hooks up the Node and Qt
| event loops.
| anthk wrote:
| > built a LISP interpreter too,
|
| Some friend of mine like it :D.
|
| But I'd like that more if it was Scheme.
| davej wrote:
| It would be nice to have the ability to weave in WebViews with
| the native UI. I see this lib but it's still marked as WIP:
| https://github.com/nodegui/nodegui-plugin-webview
| tpmx wrote:
| So is it Chromium-based or not? "which makes it CPU- and memory-
| efficient when compared to other Chromium-based solutions like
| Electron"
| LinguaBrowse wrote:
| Its UI runtime is Qt and its JS runtime is Node.js. No Chromium
| here :) it makes super-small, low-memory apps.
| crazygringo wrote:
| Yes, I suppose people could be understandably be confusing V8
| with Chromium.
|
| It's using the same JavaScript engine as Chromium, which is
| of course developed by Chromium and is part of it, but
| without the rest of Chromium, as Node.js always has.
|
| It's a great example of synecdoche [1]. :)
|
| [1] https://en.wikipedia.org/wiki/Synecdoche
| tpmx wrote:
| V8 is tiny compared to the operating system known as
| chromium.
|
| Anyway, it was just a misunderstanding based on poor
| writing on the web page.
| danenania wrote:
| Looks like it's node + QT, not chromium.
| tpmx wrote:
| Yeah.
| nawgz wrote:
| Seems weird to slander a community instead of stating what
| happened, which is that the extraneous "other" made the
| meaning ambiguous.
| zachrip wrote:
| They're making use of yoga (a layout engine) so I assume that
| it is not web based (because why would you use yoga otherwise).
| mkl wrote:
| The word "other" probably shouldn't be there. It seems to wrap
| Qt. From the NodeGUI page: "it is a wrapper for a native C++
| widget toolkit QT".
| butz wrote:
| Would it be possible to use Deno for JS runtime? That should add
| some sandboxing limitations for apps.
| LinguaBrowse wrote:
| I'd need to pass that question on to Atul (who made the parent
| project, NodeGUI). As long as Deno supports the same native API
| bindings as Node does (does it?), I imagine that it wouldn't be
| out of the question.
| crazypython wrote:
| Styling with CSS is interesting.
| Gys wrote:
| > core set of platform agnostic native widgets
|
| This is confusing for me. I think such a framework is either
| 'platform agnostic' OR 'native'. Maybe the API is platform
| agnostic and the rendering is done natively?
| LinguaBrowse wrote:
| That's the case, yes - the UI runtime is Qt5 (which is rendered
| using low-level graphics APIs, so we class it as "native" -
| mostly in contrast to WebView-based UIs), and it's the same API
| regardless of which platform you're running on.
| ComputerGuru wrote:
| I saw Qt and immediately understood what you were trying to
| say, but for the record: That's not what native means. Native
| means "uses the platform widgets and drawing/theming api" and
| Qt is not native: it actually draws its own widgets (for the
| most part with certain exceptions on certain platforms) that
| are drawn to mimic the system UI with subtle differences. If
| the system UI implementation suddenly changes (say with an OS
| release) the Qt UI wouldn't magically change with it.
|
| An example of native UI is libui or WxWidgets.
| jart wrote:
| Yeah but Qt does it well enough that I consider it de facto
| native. It's not like Swing Java where they totally went
| their own way with the widgets.
| avel wrote:
| Is Qt considered native when you use KDE and not native
| when you use GNOME? Is Qt 3 considered not native when you
| use a KDE release that uses Qt 4 under the hood?
| flipcoder wrote:
| Native usually means standard or specific to the
| particular system. I would say yes to those questions.
| quarantine wrote:
| I would say so. Just like GTK is native on GNOME but
| definitely not on Windows. "native" (to me) really just
| means whatever the system is designed for.
| nine_k wrote:
| Then Windows 10 apparently lacks a native GUI toolkit,
| because it's certainly not "designed for" just one.
|
| A similar thing happened to Android.
| gigel82 wrote:
| One could argue Win32 is still the de-facto GUI toolkit
| in Win10. Things like .NET Windows Forms and (non-WinUI3)
| UWP are actually rendered with Win32 common controls.
| jart wrote:
| WIN32 isn't de facto it is the canonical API for Windows.
| It always has been, since like the 1980's.
| MaxBarraclough wrote:
| > Then Windows 10 apparently lacks a native GUI toolkit,
| because it's certainly not "designed for" just one.
|
| Windows 10 has several native GUI toolkits. The same
| thing happened in MacOS, which transitioned from Carbon
| to Cocoa.
|
| If the widgets are drawn by a toolkit that isn't bundled
| with the OS, it's a non-native GUI. Of course, this isn't
| always a bad move.
| mrwoggle wrote:
| Real question, what do some people mean with native C++? Or
| stuff like react native? Seems like it just equals more
| performance / peels away an abstract layer.
| LinguaBrowse wrote:
| React Native does extend from platform UI components such
| as UIView, so that one at least is uncontroversially
| "native".
| heleninboodler wrote:
| Part of the point of "native" is that each platform gets
| its own consistent look and feel and behavior for its own
| UI widgets. Back when I worked at Adobe, we had our own
| internal cross-platform UI framework for
| Illustrator/Photoshop and they were consistent across the
| supported platforms, but they didn't look like "native"
| controls, and that can end up being a pretty big headache
| (e.g. when accessibility and keyboard navigation don't
| just automatically work the way the native controls do,
| that's your problem to fix or punt). They also just
| generally look "different" and a lot of people consider
| that a bad thing.
| dschuessler wrote:
| Not necessarily. This expression probably refers to Qt's
| capability to use the subset of native widgets that are
| functionally equivalent across platforms. This blog post has
| some images of this feature in action:
| https://www.qt.io/blog/desktop-styling-with-qt-quick-control...
| LinguaBrowse wrote:
| Maintainer here - Happy to answer any questions!
| mrwoggle wrote:
| I know QT is dual licensed for application development. How's
| the licensing here?
| LinguaBrowse wrote:
| Some clarification on that from the maker of the parent
| project, NodeGUI, here:
| https://twitter.com/a7ulr/status/1225498258233053184?s=21
|
| Atul is licensing NodeGUI as MIT, so I'm licensing Svelte
| NodeGUI as MIT accordingly.
| flipcoder wrote:
| From Qt's page https://www.qt.io/licensing/open-source-lgpl-
| obligations:
|
| "In case of dynamic linking, it is possible, but not
| mandatory, to keep application source code proprietary as
| long as it is "work that uses the library" - typically
| achieved via dynamic linking of the library."
| boromi wrote:
| Any Win 10 fluent examples? Perhaps WinUI integation?
| LinguaBrowse wrote:
| The parent project, NodeGUI, has some Windows screenshots and
| examples - I'm not familiar enough with Fluent or WinUI, but
| basically the UI runtime is Qt5, so integrating it into
| genuine Windows apps is out of scope (but may well be
| possible with the right expertise). I assume it would involve
| some kind of Qt-hosting view. I'm unsure whether Qt5 can host
| Windows UI components.
|
| Edit: NodeGUI here: https://github.com/nodegui/nodegui
| ComputerGuru wrote:
| WinUI 3 improves the ability to embed fluent UI "xaml
| islands" in Win32 apps (like Qt processes) but it's
| extremely convoluted and requires a lot of boilerplate
| (that I believe Qt could theoretically abstract over being
| at a high-enough level).
| jjcm wrote:
| Does this use the native OS's current default browser renderer?
| If so is windows using edge or chromium under the hood?
| nguyenkien wrote:
| Off topic, any plan to make ot work with react native?
| LinguaBrowse wrote:
| No plans, but what kind of integration would you have in
| mind?
|
| I actually happen to be struggling to get React Native in the
| NativeScript runtime right now - running it in the Node.js
| runtime would be if anything even more challenging. But there
| are other ways to make the two work together.
| bsaul wrote:
| I've always been wondering what nativescript really was
| about, and how it compared to react native and other
| platforms (and also, why do i barely read about it on HN or
| elsewhere, as it seems to offer a cross-platform dev
| environment).
|
| The project's webpage has way too many tech listed to be of
| any help, and the video mentions a framework, an IDE, a
| debugging environment...
|
| Do you have a good link where i could get a better
| understanding of the tech, and how it's used in real world
| project ?
| glutamate wrote:
| There are other projects like this - But what would really set
| it apart would be mobile (iOS and Android) support. Can we do
| anything to support that happening?
| LinguaBrowse wrote:
| Qt does have an implementation that targets mobile. I don't
| know how the licensing works, but in theory there should be a
| way to rely on Qt for mobile to extend support to iOS and
| Android. Way out of my own expertise, though!
| heavyset_go wrote:
| Qt for Android and Qt for iOS can be used under the
| LGPL[1]. The issue for iOS, though, is that Apple's App
| Store violates the terms of the LGPL. To comply with the
| LGPL, you must make available to iOS users versions of your
| app that can be linked against user-provided Qt libraries.
|
| If you use the Qt commercial license for either, then you
| don't need to worry about your app conforming to the LGPL.
|
| [1] https://wiki.qt.io/Licensing-talk-about-mobile-
| platforms
___________________________________________________________________
(page generated 2021-03-05 23:00 UTC)