That's definitely still a problem for libraries etc., but thanks to very recent developments (see the article) at least getting your app to users is super simple thanks to the new Swift Flatpak runtime: https://flathub.org/apps/org.freedesktop.Sdk.Extension.swift...
The Linux kernel allows you to run proprietary apps because the kernel code and the userland code exist in two separate "planes" connected by the syscall interface. The kernel even has an explicit exception for any code that may need to be shared between the kernel and the userland to make clear that this code is excluded from GPL.
As another similar case, the Free Pascal compiler is licensed under GPL including the runtime and almost all libraries/units that come with it but it also has an exception to allow linking without having the GPL extend to the programs the users write. AFAIK the GNU C library also has a similar GPL-with-linking-exception license.
Flatpak apps aren't linked against a runtime, they just run in a bwrap sandbox with that runtime. Again, think of it as a Docker container.
In Fact, Flatpak apps aren't even supposed to know they're running in Flatpak. They can know that, because the user agent string says so, but nothing in the app code specifically should be adapted to run in Flatpak
The Kotlin platform looks good and I've kept an eye on it, but the problem is, if I have to start working on an app now, it's still kind of scary, as you're basically just placing a bet on a horse race of which one will mature the fastest down the road.
At a previous job, I decided to adopt React Native in its early stages for a project. By some miracle (and with a lot of rolling-our-own) it managed to not hold us back and seemed to mature about as fast as we needed it to, but boy, even then it was still stressful, and I feel like we got a little lucky. (Just to be clear, I also knew this going into it and the choice was mine, I may just have a deathwish)
We have been porting to Jetpack Compose, and I really like it. It’s still got some growing pains. We don’t use ViewModels, hardly any Flow stuff, just mutable states and render trees and I’ve been pretty pleased. What makes me happiest is that it’s much more consistent. I don’t feel like I’m in a line at the DMV anymore; “oh you need that, go stand in that line and learn that stack, then come back”.
Like you, I’m extremely skeptical about the multiplatform siren. We tried it in Smalltalk land. The Java guys tried it and failed. I tried Flutter for a couple of apps, early testing iOS users were totally turned off (so fine for internal simple utility apps only). I would love it if someone really succeeded. We have 2 Swift UIKit apps I’ll have to convert to SwiftUI someday. So I will wish all that try well, but I’m not holding my breath at all.
Having a “write once run everywhere” pitch is about the same as politicians who run on “change”. It always sells; it never really delivers.
Compose is better for sure. I’m still figuring it all out but it’s a marked improvement.
Interesting. Why is that? I've been out of the Java loop for some years (although I did a fair amount of work with it earlier), so not up to date with this stuff.
Every single Gradle build system I have encountered in the wilds of GitHub has been broken on Fedora. I eventually realised it works if I run it in an Ubuntu container (using "toolbox"). So it's only portable if you bundle up the OS with your build system.
Now it should be portable. It's written in a JVM language and every Gradle project I have seen commits a copy of the Gradle JAR to its GitHub repo, which gives me those arbitrary code execution heebie-jeebies.
1. Every single gradle script is a unique snowflake of mishmashed plugins and custom functions
2. Gradle likes to pretend it is declarative, but as people very quickly learn it really isn't.
3. The one thing a build system is expected to do is be reliable in face of changing platform version, libraries and plugins. But gradle, being built on top a language on top of JDK itself has a Compatibility Matrix[0] that one has to be aware of. Often when upgrading a project you have to update JDK and gradle in explicit order, sometimes multiple times.
4. Speaking of which, did you know that gradle, being designed to build java projects does not even manage multiple JDK versions?!
5. untyped groovy means you're forever left wondering whether what you wrote is actually correct until you run it, at which point it fails with excellent errors that tell you nothing. Granted, this situation has improved in recent days, but a jump from 90th floor compared to 100th is still painful.
6. Every single fkin thing that gradle offers can be done in half dozen ways and nothing tells you which way is better or why. Ex.A: is it providedCompile or implementation? Yes, one is intended to be a replacement for another, and no, they are /not/ same.
7. The 'One Nice Thing' gradle had going for is that it bootstraps itself. But look, if want to add gradle to a 'new' project, you have to install it to your system first and use it to add the wrapper. But after that, you are expected to use the wrapper. Nobody tells you that, you just have to figure it out. Oh and when it comes time to upgrade the wrapper version, you're to use the wrapper itself, not the system gradle, again mentioned nowhere, and if you try updating the wrapper using system gradle, the error helps exactly not.
8. Gradle takes free reign in breaking APIs /between minor versions/. WTF!
9. gradle starts a daemon to cache stuff, which is nice I guess. Except when you don't want it to run a daemon, so you tell it with `--no-daemon`. Do you know what that does? It starts a daemon, runs the build and shuts it down. This may not sound like a big deal, but it is just cherry on top of this shitcacke that tells you just how thoughtfully and well designed gradle is. /s
/endrant
[0]: https://docs.gradle.org/current/userguide/compatibility.html
What about toolchains?
I also am extremely unhappy that those functions can be 16 layers deep somewhere in a lib and cause your app to blowup.
I agree that Maven is nicer to use, but the faster compile times are worth it for me to use Gradle
It’s the best way to write native Multiplatform apps at the moment. It just is.
I do try to strike a balance between flexibility and ease of use. I think Notion is too complicated (yet very flexible/powerful). With Plume, the focus is to be able to organize your thoughts in a powerful way, effortlessly. Sign up to the waitlist and try it once it’s out. Much more is coming soon.
I wrote about the problem space extensively on this site before, tl;dr, to me the issue lies in the fact that most of the contenders aim to manage data/knowledge/notes as "types" (for categorization, templating and derivation/re-purposing), but, to my knowledge, only trilium is enabling that with a "sound" design. Notion is exposing a lot of incidental complexity due to its "unsoundness".
Good luck with your project!
(if there's a better place to have this conversation than (ab)using this thread feel free to point the way. Assuming you wish to indulge me at all that is. ;-)
Well, I disagree with that. Again, it just takes a lot more effort, but I believe this is achievable (to a large extent).
If most of your logic is inside the C++ backend, its JS engine is just useless overhead. If you do something like lite data wrangling in QML, or worse, try to adapt existing JS libraries for it, it quickly becomes a nightmare of standard JS weirdness, non-compliance with normal JS, and just outright ridiculous and difficult to diagnose issues like data getting passed by reference from the previous page and that page getting popped off the stack, resulting in error.
And besides that, QML tooling is virtually non-existent. Major code editors don't even ship basic syntax highlighting for it out-of-the-box, the linter doesn't catch anything useful forcing you back into manual testing, and recently added language-server is at best a little useless and at worst impossible to get working correctly because your components live inside the build container and cannot be installed on the host without risk to system stability (Ubuntu Touch Clickable and Lomiri.Components).
If something like that was possible for Qt, I'd probably switch in a heartbeat. If our modern programing languages are finally expressive enough to write sane reactive UI and statically verify parts of your logic, why keep relying on the unverifiable and slow DSL?
Well, if most of your logic in C++, what's the problem then? For my app[1] most of the logic in C++ but there's still a good amount of logic in JS (out of laziness or ease). BTW, much of QML code is compiled to C++ these days[2]
> difficult to diagnose issues like data getting passed by reference from the previous page and that page getting popped off the stack, resulting in error.
This is very true, it's quite difficult to diagnose issues in QML, and it doesn't seem to me like Qt ships debugger tools for errors as available for C++ when a program crashes.
I relate to your issues with syntax highlighting (although the linter is good imo). Also auto-complete is pretty bad in Qt Creator for QML.
I wonder how feasible it is to integrate Typescript into QML rather than JS.
But I think that while all these issues should be addressed, developing with C++ and QML is the most joyful combination I've experienced so far for GUI development (I also developed in React and React Native).
[1] https://www.get-plume.com/
[2] https://www.qt.io/blog/the-new-qtquick-compiler-technology
As an ordinary Linux user I at least welcome all applications with bonus points if they are well integrated into KDE.
Maybe the Gnome crowd is more picky?
We Linux users do like our desktops to be sleek, badass, and sci-fi ...
That said GTK on Windows and macOS is very meh. You don't choose GTK for making a cross platform app.
I don't think Transmission is a good example.
Well, Angular is kind of dead now (or rather - will be). See https://twitter.com/sarah_edo/status/1770478763253379488
> Today we have some exciting news! We're merging frameworks! Angular and Wiz!
Wiz is awful and it's my read that a Wiz manager "won" a corporate battle and Angular (as it was) is dead.
I'd been out of iOS dev for a good long while, and was still thinking in UIKit and Obj-C.
Overall I've found SwiftUI to be the most productive and enjoyable declarative framework and developer experience I've used!
To be fair my experience is limited to React and Flutter, but still, Apple have done a rather excellent job IMHO!
YMMV :-)
Unfortunately though SwiftUI hasn't completely matured yet. Especially if you are targeting iOS versions prior to 16, you will encounter many of SwiftUI's shortcomings. Some (many?) UI components are still UIKit under the hood, scroll view and its derivatives are still not as flexible as you sometimes want them to be etc. For some custom UI tricks that would be a piece of cake in UIKit are impossible in SwiftUI and you often resort to wrapping the old components in your custom ones.
Oh and don't get me started on resorting to the main thread (because of the underlying UIKit code) in the age of structured concurrency.
All in all, the concept of SwiftUI coupled with structured concurrency is beyond amazing but its maturing process is still underway.
I will admit, Swift syntax is an acquired taste, but once you're familiar with all of the concepts (and understand that some design decisions were made for Objective-C interoperability), then it's a very usable language. To be frank, the only thing that stops me from using Swift is the fact that Linux support isn't as good as on Apple platforms. But if I am targeting nothing but Apple platforms, then Swift is probably the best choice, just for SwiftUI and SPM alone.