hckrnws
For another SwiftUI-like wrapper, see also https://github.com/stackotter/swift-cross-ui (used by Adawaita to generate widgets, and mentioned in other comments).
The key premise of this approach is to provide a SwiftUI-like declarative wrapper around Gnome functionality. It's unclear what it adds over swift-cross-ui.
SwiftUI itself has growing pains mainly around being on the right thread for processing/updates and getting data binding right.
Blog entries on swift.org or from Apple tend to be little demos that show the happy path, but when discussing new frameworks (like a Gnome wrapper) or platforms (like the recent embedded), I'd like more demonstration that the authors understand and address key issues and will sustain development. Cross-platform UI frameworks get complicated quickly and have a long tail of issues (cf Flutter, Java/Eclipse, et al) that can be blockers for clients/users. For Swift it doesn't help to have multiple concurrency models and obviously different behaviors on apple platforms and Linux (where UI is not officially tested).
I’ve never struggled with being on the right thread. It’s always main to update UI. Grand dispatch makes this trivial, and the recent actors work also extends this. I’m also not sure how this is SwiftUI specific as UIKit and most other UI frameworks are the same. What are the growing pains here?
Aside from UI updates, processing includes view-model derivations (e.g., calculating errors), persistence, and loading, all of which are offloaded to dispatch queues or actors and then brought back to the UI/main thread. wrt granularity, there's @State, @StateObject, and @Observable, with different binding reaches. So understandably a lot of choices reflecting legacy and new API's, integration with UIKit and web/media services -- and probably AI recognizers in the background. To me the pains are that the approach taken needs to be consistent application-wide (async is pretty viral, queues are designed to be shared e.g., per subsystem, etc.), making it hard to manage or migrate a code base. Also many features build on macros which can make builds almost intolerable. Also saving on macOS vs integrating with update manager on iOS. It can be hard even to find documentation on stdlib feature support e.g., Regex. It's good they maintain both the legacy support and go full-steam-ahead on new features, but developers (i.e., I) need more guidance on tip-toeing around pitfalls and managing platform differences.
Well, I've been fighting with an extremely simple Navigationsplitview for ages. Put a list in the sidebar, put 100 items in it, and render almost anything else in the detail on macos (one version back). Then select an item in the nav and hit the down arrow.
Depending on implementation, scrolling will get clipped to the visible area, it'll hold onto multiple selections if the first has been scrolled off screen, or the main thread will get thrashed and performance will be about what the current settings menu is.
I haven't found something that I don't have to accept a really mediocre experience with, but next I'm going to try rewriting it with NSTable
Swift is such a delightful language to use, well suited for general application development. It's awesome to see it gaining traction outside of the cocoa ecosystem. If you haven't given it a fair chance yet, I would highly recommend you do!
Other things worth checking:
https://github.com/stackotter/swift-cross-ui https://github.com/TokamakUI/Tokamak
I’m also working (slowly) on native Flutter channels:
https://github.com/PADL/FlutterSwift
But this is really targeted at embedded use cases.
TIL Sony maintains a Flutter eLinux embedder project[0]
And there's also SwiftUI for Android: https://skip.tools/blog/bringing-swift-to-android/
Will have to try it to see how well it works in practice, but very cool. I can see this being popular for side project apps written by iOS devs that otherwise wouldn’t have an Android port.
Very nice
Do any of these have a good wkwebview equivalent
Yes, web views (backed by WKWebView on iOS and android.webkit.WebView on Android) are one of the Skip modules under active development: https://github.com/skiptools/skip-web
Looks amazing.
As an indie dev who quit my job to try to make it solo, I'll either need to wait until I have more revenue to afford this, or hopefully you add some indie-friendly tier for bootstrapped pricing (such as a discount on team size, or ARR like Apple does with its small business program).
Looks like it is free for your use case. Pricing page[0] shows $0 annual cost for small businesses, which is defined as
> Educational institution, nonprofit, or business/individual with less than 250K USD annual revenue
Thank you! It is temporarily free with application
arc released a windows ui for swift lib but it's imperative
do you have a link? my google-fu failed me
corrected link: https://github.com/thebrowsercompany/windows-samples
I'm having Deja Vu from about 20 years ago of writing Gnome apps in C# using Mono.
Which ended up having such a community backslash that Miguel de Icaza decided to focus his efforts on Xamarin instead, followed by Microsoft's acquisition, and nowadays he is focused on Apple's ecosystem, Swift and Godot on Apple platforms.
"Miguel de Icaza and his ostracization from FOSS" https://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bru...
"What killed the Linux Desktop" https://tirania.org/blog/archive/2012/Aug-29.html
"How I ended up with a Mac" https://tirania.org/blog/archive/2013/Mar-05.html
One might wonder how things would have turned out instead if the community had been more welcoming of his efforts on GNU/Linux.
While I found the MonoProject interesting, I was skeptical using it. Sure, it is an Open Source .NET framework but .NET is Microsoft at the end of the day. I do not (and still do not) want their fingerprints inside my GNU/Linux machine.
What I mean by this is the legalities behind it.
Remember, my comment above is based on views 20 years ago. My perspective is that Microsoft cannot "beat" Linux purely as competition. It isn't going anywhere. While it may not be a concern in the Desktop market, it certainly dominates on servers! Microsfot are not stupid and see CONTROL through other means.
Imagine if most programs that come default in Linux distributions being C#? If more and more programs are written in C# (whether Mono or not) gives them power over the Linux user.
Today, Microsoft has .NET core (recent release .NET 8) and also replaces Mono. We still have Xamarin of course but that is getting replaced with MAUI. A lot of Microsofts software is now cross platform, like Powershell, SQL Server, etc. This "concern" I was having 20 years ago is still just as big of an issue today.
Imagine Microsoft getting the marketing right and SQL Server starts gaining momentum on Linux boxes. This means less using MySQL or Postgres.
Imagine is Powershell starts gaining more traction in Linux land rather than Bash.
Now -- I think this is EXTREMELY UNLIKELY to happen but you can garantuee this is a strategy. They have the money and manipulation skills to help make it happen. Big companies can easily eat this up and it starts with "but we can support you!"
Think about it -- WSL is easy to setup on Windows machines! More and more C# applications can easily be tested for Linux. Microsoft just gave you the tools, and letting developers/companies do the rest for them. Soon it is sheep follow sheep.
Bit of a long winded comment/reply - and while I do not share targeting hate towards anyone (I do not know Miguel personally but he seems like a cool guy) -- I just think efforts should have been elsewhere. Dlang could have been a really, really good replacement. My guess as to why Dlang didn't take off back them was the compiler was not open source. Who knows?
I think that most of what Microsoft does today on the developer front is focused on getting enterprise developers ever more integrated into azure. I live in a very Microsoft heavy part of Denmark, and the result is that virtually everyone uses azure and so do we. Take SQLServer as an example, a lot of FOSS database frameworks and orms don’t support it, even though there are some pretty decent Microsoft drivers for most languages. The result of this, when you use azure, is that you’re going to be using a different SQL server, or a different set of tools. It’ll often be the latter because on many enterprise subscriptions running SQLServer is quite a bit cheaper than running any other SQL DB in Azure.
That’s the developer side of things, then on the more operations side of things it’s hard to justify not using Powershell if you’re running a lot of Microsoft products. It integrates very well with everything your IT operations department does anyway from EntraID to Azure Automation, where you may be able to use Python as well, but Python is often not what Microsoft IT operations people “grew up with”. So unless other cloud providers have a strong Powershell presence on their IT operations side of things, using them, instead of using Azure, because a huge change management issue… Often one you can’t really solve, because a lot of IT operations people will rather find a different job than switch away from their Microsoft focused talents, and why wouldn’t they? Good cloud operations people are harder to find than basically anyone else in IT.
Given Azure's support for Postgres is pretty good, I would push hard for this in any new projects. Makes you more portable in future, and you can spin up local environments more easily.
Well, many folks on the FOSS space are to blame, Microsoft has learned by the hordes buying Apple hardware, that what a large majority cares about is POSIX experience and very little about GNU/Linux itself.
As usual, while Microsoft has its own actions to answer for, it isn't alone in making everything happen.
The Year of Desktop Linux comes packaged in desktop VMs, regardless if it is on Apple, Microsoft or Google's hardware.
You may have started with Vala. An object oriented language inspired by C# complied in straight C.
Oh wow, I forgot all about that little detour.
I remember making some rudimentary accounting software for which I'm sure now the source is long gone.
You still can! (even easier now since it will run on CoreCLR instead)
This only targets Gtk3 and not Gtk4 or libadwaita though. Seems a little end-of-life.
I feel like a cross platform Swift GUI would be a great thing for the world. Swift strikes a great balance between ergonomics and performance, and seems to be the only other mainstream language to have absorbed some of Rust's key features around borrowing references.
For the record, borrowed references are only going to be really usable in Swift 6 which isn't released yet.
That said, Swift's implementation of borrowing seems significantly more user-friendly than Rust's. While this is very much an advanced feature, I'd expect it to be actually used in many cases where in Rust folks would resort to working around the borrow checking (via things like indexing into arrays and such). As a result I expect it to be significantly more useful.
Browser Company sort of built this themselves for Arc, but its really a separate SwiftUI-like Windows implementation (Windows UI is separate code written in a similar style). It still feels like a technical preview though unfortunately.
I recently wrote a small side project using vala + gtk4.
I tried blueprint, and while I liked the format, I struggled with a lack of documentation on how to do some more advanced things. Gtk's .ui files are ok, but you still end up writing a lot of code to hook everything up.
While I really like vala as a language, I think it'd be great to write all my logic and models in vala, then use this swift library for the UI.
> While I really like vala as a language, I think it'd be great to write all my logic and models in vala, then use this swift library for the UI.
At that point, why not just do everything in Swift? What does Vala give you that Swift doesn't?
In the context of Gnome/GTK development, there's almost nothing more stable and comprehensive than Vala, as it's been around a very long time and was created specifically to occupy that space. Can't speak for OP about why to combine it with Swift handling the UI, but certainly Vala still has far better support for the Gnome data model and APIs outside of those specific to the GUI.
I get that, but if you're going to deal with the impedance mismatch anyway, I would just go all in and use Swift for everything. But I guess that's assuming that GTK/GLib is fairly easy to wrap in a language like Swift, which I assume is true given all the different language bindings out there.
I think a difference between Vala and everything else is that Vala has been written with gobject as its "native" object system whereas everything else uses the glib bindings.
Kinda like using COM from Visual Basic 6 vs using it from plain C.
Writing UI code layouts is suboptimal in any language. Delphi had it right - place whatever controls you like in a GUI, set up basic behavior via properties, then just quickly write handlers in code.
Perhaps, but as a counterexample, the SerenityOS people implemented the Delphi approach with Visual Builder but then realized that they preferred working with text, so they replaced it with a declarative DSL and live preview (GML Playground).
Here's Andreas Kling briefly demoing both and talking a bit about it: https://www.youtube.com/watch?v=1QYBvTy9QKE&t=519s
I don't know about Visual Builder, but judging from this screenshot[0] it doesn't look like the Delphi approach, but the "Windows resource editor" approach. Yes, both allow you to place things visually, but one works with live instances of serialized objects in an IDE that also understands the edited source code and can modify the code to -e.g.- introduce a new event handler for the OnClick event when you doubleclick the button (even with the cursor placed just right where you can start writing the actual logic of the event handling code), while the other has you draw the UI, assign some IDs and then expects you to do all the plumbing of loading the UI, associating it with code and handlers by hand.
The difference might sound trivial but in practice it is like trying to dismiss editing text with Emacs by experiencing editing text in Notepad.
[0] https://adkaster.github.io/images/build/VisualBuilder.png
I also admire the simplicity of this approach, but it has several downsides:
- Code-based UIs tend to work better with existing tooling, like comments and source control. You can freely customise your development environment, rather than being at the mercy of a single GUI app.
- Most serious UIs need code-like features, such as "for-each" to render a list of objects, or "if" to reveal a form when a checkbox is ticked. The easiest way to access code-like features is to write your UIs in code.
- You'll need to write some backing code in any case. Defining the UI tree and its "code-behind" in the same file could be considered more DRY.
- Live preview (or alternatively, hot reloading) will give you very quick iteration when writing a UI in code. It's not quite as good as drag-to-resize, but it's close.
- Automatic layout (which is non-optional nowadays) isn't necessarily a great fit for WYSIWYG editing.
- As React has demonstrated, the ability to quickly throw together custom components is extremely useful. Visual editors tend to make it more complicated and bureaucratic to define custom components.
In addition:
- WYSIWYG editors are bad about making small unintended changes that can easily slip by undetected (Interface Builder in Xcode for example often changes XIBs/storyboards just by viewing them)
- WYSIWYG editors bury bits of configuration in inspectors that are only visible in certain conditions, e.g. a control being selected, making them less evident and more difficult to find
There are circumstances where I think they still work alright — for instance I still enjoy building Mac apps with XIBs in Cocoa, but there’s a reason for that: traditional desktop UI has much less of a need for flexibility and generally speaking, has far fewer moving parts since it doesn’t have to hide things as a result of limited screen real estate. Additionally, these apps will only ever run on Macs which further reduces need for flexibility/adaptivity.
For mobile and multiplatform on the other hand, I strongly prefer code. It just works better.
My immediate though of the Swift Example Code was "but where does the business logic go".
This trivial example lacks it, and places it simple logic inside the UI code. But what if we want to protect against negative numbers? Or want to increase the number with larger increments if we hold the button pressed? Etc.
Your Delphi setup isolates business logic from UI. Which may seem "overly complex" in trivial demoes, but will help you the very moment you write the first test or add some business logic.
It's also why I see so many React apps spiral into an unmaintainable mess within days after their "git init".
You would just use some architecture pattern. I would say the most natural one for SwiftUI is MVVM so the logic would go to viewModel.
Do I understand it correct when the UI then calls methods or functions on a model layer?
> It's also why I see so many React apps spiral into an unmaintainable mess within days after their "git init".
This is true for any library/framework/architecture, and the same problem is very prominent in Svelte/Vue/React/Backbone/Angular and everything else.
> and everything else.
No. It's true for any library or framework that lack isolation or decoupling concepts.
In react (and many of the ones you mention) there is nothing on place that guides you into decoupling. It has nothing, not even conventions, that help a junior to put stuff in the right place (or to prohibit or make it difficult to put stuff in the wrong place).
Part of that is due to how in TS/JS everything can grope around in everything else. But the bigger part is lacking conventions, primitives and structure in the libs and frameworks.
Sure, a library (which react is) doesn't provide structure (it's a distinguishing trait from frameworks). But the many frameworks on top of React don't do a good job either. They either become some Enterprise Ready amalgamation of saga's, redux, message-bus, setups, or they offer too little guidance. And in all situations, it's still possible to just fire a fetch() or put data transforms or business logic within the UI. Only discipline keeps people from taking this "much easier" route.
And when only discipline stands between us and "the easier way for now", that "easier way for now" will be chosen, and pain in future will be felt.
>They either become some Enterprise Ready amalgamation of saga's, redux, message-bus, setups, or they offer too little guidance
At least Redux provides a semblance of immediately grokable data flow, this all gets worse with mobx which gives you all the flour you need to make spaghetti for the whole village. Worked on a codebase where you might have to chase down references across all sorts of files you wouldn't expect because everything is 'observable' so people, working 2-week sprints, just stop thinking about any kind of coherent structure cause it works anyway.
TBC. I don't mean that "redux == bad" just that it's often part of a large swath of systems that somewhat work together. And then still does not prohibit developers or libraries or mui or whatever from also keeping their own state in some `useEffect()` or `useState()`.
I've seen too many react projects that employ all sorts of enterprise patterns (amongst which redux) yet also wrangling-spagetti of useEffect and useState, often intermixed. There's one thing worse than having to unknot a mess of useStates: thats having to unknot a mess of useStates that is sometimes synced to and sometimes from and sometimes both, a redux global state.
> Your Delphi setup isolates business logic from UI. Which may seem "overly complex" in trivial demoes, but will help you the very moment you write the first test or add some business logic.
So basically, the same as Cocoa/obj-C?
But then what if the UI changes dimensions? Then you'd need an underlying set of rules, and isn't it best if you can set those rules yourself? How would that work graphically?
And then how about version control? Sure there could be (and is) underlying machine code, and you could try hard to make it human readable. But... IDK seems like a lot of effort to me for some small benefits.
Disclaimer: I have only very little experience with UI programming.
> But then what if the UI changes dimensions? Then you'd need an underlying set of rules, and isn't it best if you can set those rules yourself? How would that work graphically?
I don't know about current Delphi, but in Lazarus (which is kind of an open source and crossplatform Delphi) you set those rules visually. For example you can "draw" the UI by drag-and-dropping controls in a window/containers/etc and then you can add rules like "this button's left side will be 5 pixels from that label's left side and will be placed vertically so that it is centered relatively to the label". You can also set things like "this control (or container or whatever) will always be at the top/left/right/bottom edge of its window/container". This is done in the visual editor with immediate feedback (you can even resize the window/container while you are editing its layout to see how it behaves).
This allows you to make UIs that work not only across dimensions, but also handle different fonts, texts (for localization), scaling (for DPI) and themes. Especially important for Lazarus since its GUI framework has various backends that often look very different from each other.
> And then how about version control?
Lazarus (and Delphi - with the exception of some earlier versions - and really most GUI designers) save UIs in a text based format with a tree-like structure of key/value pairs, e.g. (i edited it a bit for brevity):
object Main: TMain
Left = 625
Height = 505
Top = 393
Width = 903
Caption = 'World Editor'
Menu = MainMenu1
Position = poScreenCenter
object plRenderContainer: TPanel
Align = alClient
BorderStyle = bsSingle
object plRenderWindow: TPanel
Align = alClient
BevelOuter = bvNone
end
end
end
> But then what if the UI changes dimensions? Then you'd need an underlying set of rules, and isn't it best if you can set those rules yourself? How would that work graphically?
Look into how various design tools handle flexible layouts. Usually a combination of flexbox/something similar to flexbox or slightly more old-school; constraints.
Here is an example with Figma: https://gdwn.medium.com/how-you-can-create-really-flexible-a...
You solve this by using a layout control (a UI control specifically for managing the size/position of its child controls). For example using a visual form builder you could drag-n-drop a "vertical layout control" and then drag-n-drop controls inside it to be resized/positioned in a vertical stack.
The window itself can have a layout control that stretches to fill the window regardless of resizing. Layout changes would cascade down through the tree of UI controls and everything would resize/reposition accordingly.
That's what mac/iOS development has had since before it was even mac, back in the NeXTStep days... But it doesn't work very well for very custom stuff.
My thoughts exactly.
Generally writing UI code in Xcode (and presumably before that on NeXT as well) is a breeze and a joy. Work with your delegates, connections, outlets etc.
And that's a good thing, because it discourages "very custom stuff" that made mobile apps such a usability disaster.
It is the same approach as declarative UI programming like SwiftUI or QML, but with an extra GUI abstraction on top of it. An artifact of this GUI-driven development process (like Xcode or Glade) is still a file with some declarative markup (sometimes even human-readable).
> An artifact of this GUI-driven development process (like Xcode or Glade) is still a file with some declarative markup
Not really in the case of Cocoa's Interface Builder (nib/xib files). There the artifact is basically a marshalled object tree of the actual UI objects, not declarative markup.
There is a big qualitative jump when one can arrange and play with UI without writing a single line of code, even if the user's decisions about component placement are recorded in a declarative file.
The old fashioned screwdriver has it right. Why fiddle with charging batteries, using a chuck and selecting direction when you can just pick up a ol’ screwdriver and get going!
… assembles an appartments worth of new Ikea furniture…
Oh!
Try Delphi/Lazarus for just 10 minutes, then come back with a better metaphor. The productivity difference in comparison to React, Qt, GTK etc. is enormous. When was the last time you built the whole UI of a large app in 1 day?
How well does it handle having repeating collections, or complex state interactions that something like React can handle beautifully. Or reactivity (for example a feed of live production system information updating a display with lists if controls with buttons and actions that depend on that state)?
If you answer “brilliantly” I am genuinely curious to give it a go!
Delphi is not limited by crappy web limitations so reactivity is a moot point as one can develop whatever one likes with it. Play with FL Studio DAW, that one is written in Delphi, and see if it satisfies your definition of a "feed of live production system information updating a display with lists if controls with buttons and actions that depend on that state".
See it in action e.g. here:
Wow I had no idea FL Studio was written in Delphi.
Anyway, I went pretty deep on SwiftUI from the announcement, and started programming with Delphi 7 / Visual Basic 6. While I enjoy SwiftUI, it has some rough edges still, and it's been 3 or 4 years. Hopefully Apple can put things together this year, especially for macOS apps.
I agree that Delphi is leaps and bounds better than the web technology in popular use today, and every reason I've heard for why (increased DPI, variable screen sizes, etc.) are just poor excuses.
The web is where the money was, development approaches forked, and now the worse approach happens to be more popular.
I can't decide whether it's sad or funny what Microsoft is trying to do with Blazor. They solved their Desktop UI problems by offloading them to you with a browser (now you have the problems).
Just to note Reactivity vs. event handling soup and web/desktop are orthogonal.
It is not. macOS/iOS had it for a long time with AppKit, UIKit. But the progression is usually this: you start with Interface Builder and storyboards or .xibs, then you see the problem with that and gradually move to code-only UI and then start looking at SwiftUI with it's declarative UI like a guy in that meme. GUI for layout just does not cut it, especially when your app runs in very different environments - it can be macOS, it can be a phone or just a smartwatch/widget.
> especially when your app runs in very different environments - it can be macOS, it can be a phone or just a smartwatch/widget.
But the question here is also if it makes sense to basically have the same UI or even UI paradigms for such different types of environments.
Alternate take: macOS/Qt/MFC/React etc. got it wrong, Delphi got it right.
I’ve recently noticed Swift sneakily becoming an interesting option for desktop dev. On top of this example I’d add Arc for macOS and Windows.
Will be interesting to see where it ends up, yeah :)
> On top of this example I’d add Arc for macOS and Windows.
Didn't development of Arc stop like a really long time ago? Anarki seems to be where development is at nowadays.
I believe the references to “arc” here and elsewhere in the thread is referring to the new web browser and not the Lisp-family language. There’s a GitHub link to a Swift ui bindings for Windows elsewhere by another poster here.
This is correct
Oh, I meant the Arc Browser[0]. Wraps Chromium with a Swift GUI layer
Oh yeah, in hindsight that makes perfect sense. Guess I've spent too much time on HN...
Something like SwiftUI but open source and targeting GTK4 would be pretty close to my "dream framework" for cross-platform desktop UI.
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.
FWIW I very much enjoyed using SwiftUI once I got the hang of it!
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 :-)
Rewriting an app from UIKit to SwiftUI not only eliminates storyboards but also reduces the code base. So once again: you have code plus storyboard XML vs. just code that is smaller! My jaw dropped when I first discovered this while rewriting something.
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 remember a few years ago, a few really cool cross-platform UI libraries were starting to emerge such as libui [0] that got me excited. I've kind of lost track of them since then (libui itself went dormant for a while before this fork) so I am not sure how mature/useful they are now, but the potential for writing native desktop UIs in basically any language seemed like an absolute dream. Perhaps it's feasible for very basic things?
> Linux support isn't as good as on Apple platforms
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...
It says the runtime is under GPL3. Does the copyleft apply to all Flatpak apps written using Swift?
No, it is the runtime, it's not a part of your app, it just runs it. You can basically think of it as a Docker container (but specifically for desktop apps). You don't have to make your app GPL, the same way as you can run a proprietary app on Linux even though the Linux kernel is GPL
It isn't that simple. If your application links against the runtime, be it dynamically or statically, then it is a derivative work and thus must be distributed under the GPL. This is why Java, also being under GPL, has an explicit exception for the runtime library despite even being a VM.
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.
> If your application links against the runtime, be it dynamically or statically, then it is a derivative work and thus must be distributed under the GPL
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
I thought that Apple actively avoided GPLv3
It looks like the runtime is owned by the author of this article, who (from his bio) doesn't seem to be affiliated with Apple. Either way, I agree it seems like an odd choice.
a. It's the author using something which is GPL b. GPL is allowed as long as complied. c. GPL mostly limits ability for use within iOS / AppStore.
There is Relm (https://relm4.org/). Which is in Rust is just GTK (through it's Rust bindings) with a nice reactivity layer on top.
Sounds like Compose and Kotlin, although multiplatform still being more in a beta stage.
If I had a nickel for every time I got excited about something with experimental multiplatform support...
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)
Take a look at skip.tools. It's pure SwiftUI on iOS and Jetpack Compose on Android, with the tool automatically handling the translation from Swift to Kotlin as part of the Xcode build process.
We had a Kotlin app written with view bindings and the various other bits and pieces of Android app stack “no now this thing” detritus over the years. I hated it. I cut my teeth on 20 years of smalltalk, so it wasn’t even the “let’s hate on OO now” thing. It was just so much unfinished/inconstant things.
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.
The first two paragraphs has been my experience on Android too. Android Framework is an incredibly disjointed mess that leaves you neck-deep in half-baked APIs.
Compose is better for sure. I’m still figuring it all out but it’s a marked improvement.
Kotlin is probably the most similar in syntax to Swift out of the languages I’ve written, but it’s somewhat quirky and opinionated and I’m not sure I agree with its opinions (lack of guard statement, no ternary ifs, etc). Also it involves Java ecosystem stuff like Gradle which can drive a person mad sometimes.
My dealbreaker for kotlin is that it’s possible to call a throwing function with no indication it will throw. In swift, the compiler forces every throwing function do be inside a try/catch block or be called by another throwing function.
I also am extremely unhappy that those functions can be 16 layers deep somewhere in a lib and cause your app to blowup.
Yep, this is a problem I’ve encountered several times. Even if none of your own code has unhandled throws, you’ll inevitably get crash reports coming in from fooLib throwing an exception somewhere because the moon was in the wrong phase.
There are entire languages built with unchecked exceptions, Python, Ruby, Nodejs and most recent ones. Even with checked exceptions you can write code and miss to throw or declare an exception somewhere so ultimately the developer has to deal with exceptions somehow.
>Also it involves Java ecosystem stuff like Gradle which can drive a person mad sometimes.
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.
Gradle combines the inscrutable magic of Maven with the unpredictable structurelessness of Ant in one bundle of pain.
What really irritates me about gradle is that they have significant API churn but there's still five ways to do everything.
I will never pass up an opportunity to heap scorn on Gradle. I agree with everything said so far, except I would argue Ant was easier to use.
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.
Oof. Thanks, guys.
ooh where do I start... Let's see:
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
>4. Speaking of which, did you know that gradle, being designed to build java projects does not even manage multiple JDK versions?!
What about toolchains?
There is only one reason to use Gradle instead of Maven, being stuck on Android.
Gradle has fast build times and a lot faster incremental ones.
I agree that Maven is nicer to use, but the faster compile times are worth it for me to use Gradle
Why not go with Qt's QML?
As someone who works with QML daily, I had the same question. The work is already done. Why write a common UI backend in swift when you can have the whole thing common using QML/Qt.
It’s the best way to write native Multiplatform apps at the moment. It just is.
I’m not entirely convinced that multiplatform UI is a good idea for anything other than the simplest of applications. It always ends up looking out of place on at least one platform and sometimes all of them.
It just takes an effort to make Qt apps look and behave native. This has been one of the goals with my new note-taking app, and I think it looks pretty native (at least on macOS): https://www.get-plume.com/
Hey, I don't use your app because it's too limited for my "PKMS" needs (I use trilium notes instead), but I appreciate that you make being "native and fast" a distinguishing feature (vs all the other electron based alternatives boiling the oceans).
Thanks for the feedback, although the app isn’t released yet so you should at least give it a shot once it’s out.
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 think Notion is too complicated
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".
@ezst I've come across a couple of your comments noting the benefits and shortfalls of the current crop of PKMS. Lots of head nodding going on over here on the "sure you can define your tags/categories/types, but after page/note creation you're on your own for management" theme. That had me jumping with enthusiam towards Trilium, only to see it's gone into maybe-discontinued mode (https://github.com/zadam/trilium/issues/4620). What are your thoughts on it's viability for someone who is not a current user but thinks they might want to be?
(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. ;-)
Just read this comment of yours[1]. Plume is aimed to be much simpler than Trilium, I want a non-tech-savvy 40-year-old mom that doesn't know what Kanban is to be able to happily use it as someone that is tech-savvy that knows all about Kanbans. Something that just works for many people, like Apple Notes but with a more advanced editor and features.
You seem to have your objectives (and non-objectives) clearly stated, which gives Plume a fair fighting chance :)
Good luck with your project!
Thanks!
Which kind of supports my thesis. It’s not so much the underlying tech stack that matters, but the attention to platform conventions. I would expect text input on a Mac, for example, to support ctrl-a and ctrl-e shortcuts for beginning and end of the line (Microsoft is a gross offender on this front thanks to their wanting to accommodate Windows users on a Mac who will be used to using ctrl instead of cmd for keyboard shortcuts).
> I’m not entirely convinced that multiplatform UI is a good idea for anything other than the simplest of applications.
Well, I disagree with that. Again, it just takes a lot more effort, but I believe this is achievable (to a large extent).
Looks gorgeous. Is it QML or pure Qt?
Thanks! It’s both. The model side and logic is written in C++ while the view is written in QML. That way I get the best of both worlds, the performance of C++ with the ease of use, flexibility, animations, etc of QML. It’s worth noting that most Qt Quick components and much of QML code is compiled to C++, so even code on that side is performant.
Amazing. This is very inspiring, thanks.
For me, QML, while expressive, had a lot of rough edges.
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?
> If most of your logic is inside the C++ backend, its JS engine is just useless overhead.
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
It just is is a relative term, for example - I already know SwiftUI.
I hate Qt, the apps look non-native and don't obey Ubuntu's appearance settings and fonts.
Qt apps arguably look more "native" on average than anything else I've seen, considering that it mimics the native look and feel of the target platform for a wide range of them. Now compare that to Gtk, which just leaves you with gnome-style shortcuts and controls on Windows/Mac, and nothing in the area of desktop integration if that's a feature gnome doesn't have (e.g. tray).
Nobody bats an eye when apps built for Windows don't adhere to its design patterns. Some goes to a large extent for MacOS. I swear Linux users have the strangest obsessions..
To be fair, even Microsoft isn't consistent on what people feel like native should look like. I'm primary a linux/mac user as home, but at work I have to use Windows 11. It is surprising that Microsoft gets paid the Windows given that the control panel has a new updated UI that meshes with Windows 11 fairly well, but then you open up something in control panel and need to access more advanced features and your greeted by a UI that I am pretty sure is from Vista or 7. A standard winforms UI looks totally different from a WinUI. Yes, technically they are all native, but they all look completely different.
Mac users are worse than ordinary Linux users I think (writing this as a Linux user who right now uses a Mac :-)
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?
Longtime mac users definitely have a preference for apps that are not only native, but designed to be good citizens of the mac desktop by abiding by its UI conventions, feature progressive disclosure of power user features, etc.
I mean, most Windows UIs look like shit, they look like something that would be at a DMV.
We Linux users do like our desktops to be sleek, badass, and sci-fi ...
> targeting GTK4
> cross-platform
??
Do you know of any GTK4 app that runs well on non-Unix platforms?
Flutter Linux targets GTK3 and is currently investigating a GTK4 migration. Flutter also supports Windows and macOS.
But it doesn't use GTK widgets, it just uses GTK to make a window.
That said GTK on Windows and macOS is very meh. You don't choose GTK for making a cross platform app.
Deluge and Transmission are good cross platform GTK apps.
Transmission uses Qt on Windows, either GTK or Qt on Linux, and something AppKit on macOS.
Evidentially it is possible to make GTK apps work at least somewhat nicely on Windows and Mac since there are a few out there. But it's clearly a ton of work. If you just make a standard GTK app it will be terrible. Most toolkits (e.g. Qt or even Flutter) work much nicer without having to fix them.
Transmission has Qt and Win32-native GUI clients as an alternative to its GTK client.
I don't think Transmission is a good example.
Transmission only uses GTK on linux.
There is a Qt and CLI client, too.
And a web UI! (My preferred method as I run it on my home server)
And it's a Google project, which means as soon as the low-hanging promo fruit is harvested it will immediately go EOL.
Like golang? Dart? Or Angular? They kill consumer products not programming languages or major frameworks..
> Angular
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.
Isn't Wiz internal only at Google? How can it replace Angular (honest question)?
These folks built their whole business on DartAngular only to be dropped when some manager decided that it’s time to push Flutter. https://medium.com/wriketechclub/wrike-is-sunsetting-its-ang...
Hardly anyone used the Dart Angular bindings so it was not surprising they got dropped. They were an early adopter and got bit.. this happens everywhere especially in frontend web development, and is certainly not specific to Google's frameworks.
Sometimes there's a lot of low hanging promo fruit! Generics were a Significant Engineering Challenge!
That looks really nice! A healthy balance of reactive UI, expressiveness, and sanity. I wonder if there's a similar Swift binding for Qt... Ubuntu Touch and KDE could really benefit from that, as QML proved to be a total typing nightmare from my experience, often even slightly worse than regular JS thanks to its quirks...
Has anyone been able to get this running on Mac. Followed the instructions, but I always get a missing adwaita.h in some shim.h
Adwaita is - I believe - closely tied to Gnome. SwiftUI (obviously) already has bindings for macOS’ window server. Not sure what this project gets you on macOS that you don’t already have?
You will need to install libadwaita. Try "brew install libadwaita"
This is really cool! I love the JSX-like approach to UI and it's a shame it's not so common on desktop. https://github.com/can-lehmann/owlkettle is the only thing I find comparable.
And Nim is pretty handy for DSL approaches like that! I've never got to try SwiftUI stuff, but it looks great for desktop UIs.
You could say "writing Gtk code in X language where I implemented a DSL for this special case is easy!" in any PR piece.
You could do it in Python using contextmanager which packs after adding the widget to HBox to save a line, you could do it in Ruby using do/end blocks, you could do it in C with the help of some pretty macros.
I wonder where the pulse is with current GTK app development. I've noticed some of the newer core apps are in Rust like the new camera app and the image viewer, also the public transport app railway (not a core app afaik).
Is this the only declarative way to write desktop app UI? (Maybe Kaitlin multiplatform, but not sure how that works on Linux). I mean GTK/Qt
So, the elephant in room, what's the best way/framework today to write desktop apps for linux (no electron)?
Qt of course, hands down.
Qt (without QML). Has been around for ages and works beautifully. GTK is more complicated. I have no experience with libadwaita, but if in doubt I'd always go for Qt on Linux. It's stable, has great tooling and good documentation. And it hasn't changed much over the years, so most information you find - even on Qt 3 - is still mostly accurate today.
I would argue that Qt with QML is the best combo. See: https://news.ycombinator.com/item?id=39848069
Love the idea of Plume; signed up to the mailing list. Btw the website layout breaks on very wide browsers (images in the .features-section overlap text). Maybe consider some max-width for the page.
And I also have to say that my days with Qt are quite some time ago. I never really got into QML, so if you say that QML is a great choice I'd put more weight on your word than on mine.
Thanks for letting me know! I'll fix that.
Qt Quick (The Qt Company's library that is exposed in QML) is very advanced today. I'm able to do things that would be considered very difficult with Qt Widgets. For example: true drag and drop between items in a virtualized list: https://twitter.com/plumenotes/status/1772599295243440137
Also, they started to work well on native widgets (at least on macOS), for example they support native dialogs, context menus, etc. Very helpful.
I'll probably write a blog post about the development and architecture (some said they'd be interested).
Imo libadwaita apps are the best, but I haven't found a perfect solution for writing them.
Flutter
That's neat!
But how is everyone testing their Swift codebases? We've found the story around testing to be... lacking. The [docs](https://developer.apple.com/documentation/xctest) on the subject are pretty bare and don't offer strategies for mocks, stubs, reporting, code coverage, etc.
And good luck if your app uses a Network Extension... those must be tested on a live physical device due to the signing restrictions!
On that note, does anyone know of a good physical device CI service that supports both iOS and macOS devices?
Take a look at https://github.com/apple/swift-testing It is under active development as Swift first replacement for xctest. For CI service, Xcode cloud does support running tests on mac and iOS hardware. https://developer.apple.com/xcode-cloud/
Xcode Cloud doesn’t actually support running tests on devices. Some of the marketing tries to imply that it does, but it’s simulators only.
I always thought that introducing keys in function parameters was a mistake.
Not having keys in function parameters is a mistake.
Swift does have an unconventional approach to function keys though, wherein you can specify an "external" label and an "internal" label:
func greeting(for person: String) -> String {
"Hello, " + person + "!" // the argument is "person" inside the function body...
}
print(greeting(for: "Dave")) // ... but it's "for" when calling the function
I love the internal/external labeling. With a little thought it can make for code that reads more nicely than is possible otherwise.
JavaScript has that with:
const hello = ({ for: person }) => `Hello ${person}`
hello({ for: "Dorian" })
'Hello Dorian'Javascript's one is a little bit different in that you are renaming the destructured variable - it's not a function-specific thing - whereas Swift's version is a property of the function.
e.g.
const user = {id: "123"};
const { id } = user; // This extracts the `id` field
const { id: userId } = user; // This also extracts the `id` field, but renames it to userId
console.log(userId)It does indeed, but the cost is an object allocation for every function call.
it's one of those small things that are also brilliant in hindsight
Objective-C sort of had it unofficially through how methods tended to be named.
I’m glad they found a nice way to do it in Swift.
Named parameters and nothing new and I like them. To this day I don’t understand why swift/objc have two names. I get that one is external, one internal so changing external breaks APIs. So is the only advantage that you can rename the parameter name for function implementation? So what? You can do that by a variable at the top of the function. Those two names make function signatures hard to read (which one is which etc)
crystal has it too, and i agree, it's a very nice feature
For me, I felt the same way initially, but I found it depends on the case. The case you gave is probably now one I would do, I would probably have the external be 'for' if I expected the caller to pass in a list that I was gonna iterate over inside of the method.
An example I like to use to show when and how I used it. I have been playing with Metal. If I write a function called translate, I will have it's external parameter as 'by' with the internal parameter being 'vector'. As a simple example:
func translate(_ origin: simd_float3, by vector: simd_float3) -> simd_float3 {
// do some stuff
}
let newVector = translate(originalVector, by: translatingVector)It’s one of the things I miss most in Kotlin.
Even C/C++ have the internal/external mismatch:
// in greeting.h
void greeting(char* for);
// in greeting.c
void greeting(char* person) { ... }
I disagree, I think the more self documenting the code is, the better. It's also nice with code completion because when I start typing a function, I'm given a list of all the overloads for that function, and when I pick one I get all the arguments sitting there ready for me to fill in.
You still get that with traditional languages that don’t use keywords like java. With Swift you have to read a lot more to get the right function since many vary in the number and type of parameters.
I disagree. It makes the code readable.
It's still a tradeoff: in a previous team switching languages it openned the door to function with 5+ parameters, when that was highly throwned upon otherwise.
It's a tool to help better manage complexity, and that naturally invites more complexity as well.
is that an issue of the language or of the team?
adding additional names does not add additional complexity. complexity arises in interactions between components.
I see it as mostly influenced by the language and tooling. From there, some people will be more attracted by one side or the other, but when moving stack you tend to follow the stack's natural incline.
For instance ruby helps to have shorter, less verbose code, but with more hidden components. Rails rose from there, tooling tends to support that style. I've seen java devs moving to ruby and naturally writing less verbose code.
In contract Java tooling makes it a lot more manageable to write 40 character long classes, deeper dependency trees and injections and potentially auto-generate half of the needed methods. The cost is low, and there's less incentive to fight that trend when tools help you abstract part of it.
i agree but you discuss verbosity and not complexity
Fair point.
You're right that total complexity across the system fundamentally doesn't change (it's up to the devs and the problems at hand). Local complexity in each part of the system can vary, but the whole will probably always be least as complex as it needs to be.
The best function calling syntax I've ever used is the video scripting language AVISynth, which is mostly key based. It's basically Swift but more flexible and informal.
http://avisynth.nl/index.php/Grammar#Functions.2C_Filters_an...
How is the 3D story on gtk4 am I still stuck to opengl contexts?
Comment was deleted :(
I don't understand why there are so many negative comments. Writing GUI in C looks like a stone age programming, and people are simply wasting their time to do routine work that can be diminished by using another language. One might use Python, but it is slow and memory-hungry.
Isn't it good that now there is an alternative to C?
I used common lisp in the past to interface with GTK via the cl-cffi-gtk library. Performance was good I think (I did not benchmark but the UI was responsive and did not consume much resources) and dev experience was great because of the REPL. But it did take quite a bit of suffering to get the resulting artifact working on Windows which was a definite requirement sadly. It can be done though.
> Isn't it good that now there is an alternative to C?
It's not exactly the first alternative, GJS (Gnome JavaScript) have existed for a long time and is also a C-like language, so doesn't seem this would give too much value compared to just using GJS, unless you know Swift a lot better than JavaScript but the languages are similar enough that even that doesn't provide much value.
AFAIK, GJS is an official Gnome project too, so there will be a vast difference in ecosystem support compared to Gnome apps written in Swift, which I'm not sure is so popular outside of Apple circles.
JavaScript is non static-typed and you'll spend time fixing bugs that can be prevented by static typing. Also, GJS is not well documented, as far as I remember.
> JavaScript is non static-typed and you'll spend time fixing bugs that can be prevented by static typing.
Use TypeScript if types are so important for you. Others find their own way of handling those issues without getting tripped up on it. Hardly a reason to completely switch between two languages in my mind, but of course it's alright if it's reason enough for you. Luckily there are acceptable workarounds for both groups of people :)
> Also, GJS is not well documented, as far as I remember.
What exactly is missing here? There are guides for the basics, API reference exists and there is a ton of apps you can look into for inspiration and/or figure out specific implementations.
Is that really worse than what exists for writing Gnome apps with Swift? Seems like a really weak argument for using Swift instead of GJS.
Swift is compiled, static-typed language and without tons of legacy like JS (for example, it has real objects, not dictionaries). Doesn't require an interpreter. It seems to be better than JS in every aspect.
One mans gold is another mans trash :) Static typing seems to be a neat addition for lots of people, that's great! Doesn't mean it's a silver bullet that improves development for everyone, and that's OK.
I still don't see how a language (GJS) with an already existing ecosystem of writing Gnome apps, lots of examples, API references and more is worse for writing Gnome apps than Swift, that seems to have been launched just some days ago?
Edit: I realize now that the "Adwaita for Swift" this blogpost is about isn't even an official Swift project, is the output of a student interested in Swift and Gnome.
I think you are vastly overestimating how good and current the GJS documentation and examples are. Without touching the fact that it is NOT a stable API and breaking changes are very common.
Even the gold standard of GTK coding in C is still very undocumented outside of the happy path and confusing due to the Gtk 3->4 migration, and the only approach to learning it is by reading what other Gtk apps do.
Honestly I used to think the same way about JS, because not having types allowed for very concise code sometimes. But the more I used Swift I realized how powerful type inference can be, and the difference in conciseness shrunk to basically nothing.
Heh, yeah, everyone's journey is different :) I started out being a big fan of static typing but eventually found that I'm usually hit by different issues than "this was a int but I expected a string" that were more important to be solved, so I'm mostly using dynamic languages nowadays.
But that's what so great with programming languages, there are so many that work so differently, so there is at least one language for everyone, no matter how different your brain works :)
By the way, if you're a fan of "conciseness" you should give a lisp-type languages a try if you haven't before, will show you a completely different level of conciseness! Clojure is a great introduction to lisps. And if you still need validation of data somehow, clojure.spec et al works great and will introduce you to some cool new things you probably haven't come across before :)
Doesn't TypeScript – as mentioned above – solve all JavaScript type problems? I have, in 6 years, never encountered a single type error originating from a TS file.
Biggest problems with TypeScript IMO are that it’s a layer rather than a language proper and that untyped JS problems can too easily worm their way in if you’re using any libraries at all. Also depending on the group of developers involved, the ease at which one can pull the escape hatch and opt out of TS is a liability and can render much of its benefit moot.
> I still don't see how a language (GJS) with an already existing ecosystem of writing Gnome apps, lots of examples, API references and more is worse for writing Gnome apps than Swift, that seems to have been launched just some days ago?
I mean, you said it yourself:
> One mans gold is another mans trash :) Static typing seems to be a neat addition for lots of people, that's great!
For those people it is definitely better than GJS!
Well, I mean if the difference was only about static typing, I definitively see what you're talking about. But the difference between GJS and Swift for Gnome app development is greater than that, so personally just that one "feature" wouldn't push me towards Swift.
But yeah, probably for some it's worth it, so that's pretty cool :)
> legacy like JS (for example, it has real objects, not dictionaries)
Could you explain the nature of problems that occur due to javascrript's treatment of objects? What makes it a big and important issue?
In JS you can delete properties, assign anything to them (no typing), cannot add comments to them, cannot restrict access from outside. Also you can access non-existing properties and no error will be thrown.
[dead]
>Isn't it good that now there is an alternative to C?
Rust has had endorsed language bindings for GTK for a long time: https://www.gtk.org/docs/language-bindings/rust
Some official Gnome applications are written in Rust.
Swift only supports a small number of linux systems (Ubuntu, CentOS, Amazon Linux) which makes unsuitable for general linux application development.
Swift run on almost every linux desktop (Arch, Debian, Ubuntu etc. have even their own packages) I hate when people are writing false information with such a confidence.
See https://www.swift.org/platform-support/ for a list of supported distributions.
You seem to have hallucinated that I said that swift cannot be made to run on other systems. You can even make windows-only games run on linux so that is not a surprise.
What distinguishes swift from gcc, clang, python, bash, go, rust, and so on is that languages other that swift aim to support linux in general.
Swift only supports a small number of linux systems. which is at most half-truth cause this is just official installers and most likely you'll use some sort of rustup (rust wasn't working on every system few years ago if you use official installer not some sort of rustenv installer or building from source etc.) you can use https://github.com/kylef/swiftenv you can use community packages https://wiki.archlinux.org/title/Swift etc.
"and so on is that languages other that swift aim to support linux in general." -> again not true linux distro dosen't change swift usage it is just official build is run for few most popular distros and you can use prebuild swift-bin on any linux repo. (arch, debina, ubuntu, centos etc. etc.) You can say the same stuff about rust/nim/go every other language that didn't have official release for some niche linux distro.
I don't think that, say, rust, offers any explicit support for any particular linux distro?
Swift here are basically saying they'll endeavour to make sure it works on those particular distros, but in general you're probably going to install Swift on Linux the same way you install rust; via your distro's package manager, and supported by your distro, not the Swift or Rust project.
It might run but support and packaging is missing, compared to gtk oficially supported for other languages and packaged on distributions that matter (e.g. Debian).
"runs" would be different than "supports". AFAIK, there still isn't an official package for Swift in the Arch package registry, so to say Swift is supported by Arch sounds like "writing false information with such a confidence".
> Install swift-bin [AUR]
Notice the [AUR] tag, that means it's in the Arch User Repository, not in the official repository.
https://wiki.archlinux.org/title/Arch_User_Repository
https://wiki.archlinux.org/title/Official_repositories
Slightly ironic given the whole "confidence" side-note you made earlier...
almost no smaller/newer language is added to official repo so i don't know what are you taking about it is kinda expected? (even if this languages are fully supported on linux)
https://wiki.archlinux.org/title/MATLAB https://wiki.archlinux.org/title/Scala etc.
Be that as it may, the initial claim was "Swift only supports a small number of linux systems" which you tried to refute but moved the goal post from "supports" to "runs". One of them are true for Swift + Arch, yes.
Supporting languages isn't the arch maintainers job I srsly don't understand your argument if all language stuff (LSP, language, debbuger etc.) work on every linux distro without any modifications is this distro "supported"?
If rustup will be removed from official repo we can argue that rust isn't supported in arch?
Why doesn't Swift run on other Linux distributions?
It runs just fine comment above is lying if you can run llvm/clang you can run Swift.
I don't know if I would say, 'just fine.' Technically yes. The issue comes in with that not everything in Foundation is quiet yet there on the Linux platform. But it is getting better and better and probably good enough for 90% of stuff. It seems more of a problem of just getting the last bit done to push Foundation over the finish line.
to be fair and looking at how closed is the apple ecosystem, I would not put my open source eggs in swift
My feelings exactly! It's frustrating the lack of viable alternatives though. Just typing on my japanese flip phone is a pain and i think the T9 could be improved. That said i don't think adopting apple tech would help much as far as fixing any deficiencies in ui imho.
Swift is open source.
How does the App Store affect Swift?
Yeah, I'll happily take GUIs written in a fairly fast and memory efficient language that are using a full GUI toolkit. It beats Electron, Python, Java or Go programs any day.
Gtkmm exists since GNOME 1.0 days.
As do bindings for Python, C#, Lisp, Scheme, Vala, JavaScript (since GNOME 3)...
> Isn't it good that now there is an alternative to C?
There’s this new kid in town, IIRC it’s called C++
Comment was deleted :(
>The primary motivation for this package is to enable the use of Swift when writing GNOME apps, for all the reasons outlined above
The only problem I have with such projects is when they are unmaintained, in various stages of immaturity, and have little adoption (vicious circle).
You find them, they promise exactly what you need, and then you fell into issue after issue in practical use (*).
It would be amazing if there was (perhaps this is or will be) well maintained bindings for Swift/Rust/Go and co for Gnome.
* Yes, it's open source and you can fix some of the issues yourself. Doesn't mean you have the know-how or time to fix all of them, especially when there are lots of things to fix or features missing. Ideally a big community must exist, so that each can just work on or fix a small part and the problem still get lots of fixes/improvements incoming, as opposed to "fully replace the single overworked maintainer yourself".
This. Over the years I've seen so many cool projects aiming to ease native desktop UI development, but most became unmaintained at some point, for what I am guessing is due to the difficulty and complexity associated with actually making this work in practice. It is less sexy, but a solid language binding to the existing libraries is likely the more practical and maintainable way to go
After so many years of seeing cross platform stuff come and go I can’t help but think it can’t be done well enough for mass adoption. It just has too many gotchas that make things feel out of place on every platform in different ways. At least outside my first demo app territory.
The only thing that really seems to be succeeding is web stuff like Electron, which usually throws the baby out with the bathwater and does its own thing of emulating the web (itself, basically) instead of trying to feel perfectly native.
Idk I've been developing with Qt for idk, 15 years now, it's stable and keeps chugging along with constant improvements. And is used in more than enough mass-adopted apps, e.g. Telegram
This is spot-on. Though I think the interesting thing here is just demonstrating that you _can_ build this kind of thing at all and a cross-platform-SwiftUI-like framework isn't a pipe dream.
For production use-cases at this moment in time, I'd probably lean towards using Swift's pretty-good C++ interop functionality to thinly wrap a more battle-tested C++ library.
I don’t get these kinds of complaints about open source projects..
Seems like you guys want either 0% or 100% ..that something either not exist at all or perfectly does everything you ever wanted without any effort or cost on your part.
You want a process and commitment, a clear distinction between which things are first-class and which things aren't. If this is just an experimental project that may not go anywhere, fine. If this is meant to be the new way of writing Gnome apps, displacing Vala, and they're going to support it in LTS releases for at least the next n years, fine. But it should be clear which it is.
It doesn't have to be 100%, but nobody wants to invest a ton of time/energy into a project just to hit a wall a little ways down the road when something at the very core of it breaks or becomes unmaintained. Of course it would be nice for users of such projects to help and contribute, but this isn't always practical. Not because the users are being entitled assholes, but often times they aren't even the same skillsets, and I think this is especially true of some of this complicated, low-level UI stuff. If I'm a user of PyGObject writing GTK apps in Python, I'm not necessarily capable of contributing to the underlying C bindings, even if I wanted to be helpful.
This dynamic presents a legitimate problem for pretty much any open source project that aims to abstract away something very complex to enable more developers to use it. Any project that does this is going to have more developers relying on it than are capable of contributing to it.
You should never feel entitled to continued development of a project you don't contribute to, and you should always assess the community around tools you want to use in order to make good decisions. But this doesn't mean you can't be super frustrated if something you rely on goes dormant. I personally avoid using any library/package that doesn't appear to be very active, but nothing is foolproof. Even a seemingly healthy project die can fairly quickly in certain circumstances.
I think the discussion is valid, I don’t see it as complaining. People can create cool things, but you have to weight whether that can actually be used in practice. After all, until AI start writing software for us, maintaining a project takes time and effort. No one wants to see it go to waste.
>Seems like you guys want either 0% or 100% ..that something either not exist at all or perfectly does everything you ever wanted without any effort or cost on your part.
Or, you know, that's a strawman, and we just want something that exists and is mature, like hundreds of other FOSS people are fine with, as opposed to basing our code on something that is immature, has little community, and will probably be abandoned when the authors get bored with it.
Which has nothing to do with it being "100%" or "perfectly doing everything we ever wanted".
Comment was deleted :(
Really something we needed.
Swift has such low memory usage, that it's an order of magnitude easier on resources, than those Electron wrappers. At the same time, it gives what you loved about React - expressiveness for UI.
I wrote a lot of apps in SwiftUI, and it strikes a good balance between type safety and expressiveness, it's cool that we have something similar for GKT/Gnome now.Comment was deleted :(
Is there a language server for Swift that does not suck?
I believe swift is a good language, however its ecosystem being steered by apple is a massive red flag. It also suffers a bit from being a commercially developed language in that its developers are clearly incentivized to add more features.
> a commercially developed language in that its developers are clearly incentivized to add more features.
Do you have any evidence this is true? Most programming languages are developed either by a company (C#, Java, Swift, Go) or heavily influenced by many companies (Python, JavaScript, C++). Java had been criticized forever (until very recently) for it's slow pace of development and it was 100% controlled by either Sun or Oracle.
Comments like these show just how little developers investigate the reasons why features they personally dislike were introduced to a language.
As a professional Java developer its new feature pace is still slow. It’s a little better but it hasn’t been fast in a VERY long time.
But that’s OK. They do an amazing job of maintaining backwards compatibility and making things fit in the language well as well as trying to get it right the first time.
Some languages are more willing to remove things that don’t work. Others are willing to have multiple different attempts that all work completely differently every few years.
In many ways that’s just not Java’s style. And that’s OK.
If you want to move faster in JVM world use Kotlin. There is no alternative in .NET world- that’s why JVM ecosystem is much better (and bigger)
I’m actually quite happy with how it’s done, but I know many others aren’t.
F# would be the alternative.
F# is not mainstream lang - it’s more like Clojure for .NET. My point was - you don’t have that variety in .NET as in JVM (Scala, Kotlin, Groovy are all relatively mainstream)
Kotlin is only mainstream on Android because Google says so, Groovy is barely kept alive thanks Gradle, and if it wasn't for Kafka and Spark, Scala would have been long gone.
Hardly any better than F#.
Well you are clearly out of JVM world. See supported langs here https://start.spring.io/ (most popular JVM framework)
Kotlin is especially popular on backend if you can’t jump out of JDK8
F# is functional - by definition not mainstream
I am on JVM world since 1996.
Spring supports anything that can bring them support contracts.
Kotlin, popular outside Android?
Reality check over here,
https://spectrum.ieee.org/the-top-programming-languages-2023
Don’t get me wrong F# seems like a nice lang but definitely not mainstream (non geeks don’t use purely functional langs).
You can’t deny Kotlin is bigger lang than F# by any ranking from those popular (Tiobe) to unknown ones and is build on top of much bigger ecosystem (JVM) - that’s IMHO much more important factor for anyone doing commercial projects.
Additionally there is a big incentive to use it over Java (if you are stuck with older JDK) contrary to using F# over C#
Kotlin as a lang is better than C# (which is normal - it’s newer) and has better default IDE (IntelliJ) than anything on the market.
This is like discussing which homeless has better clothes, while the society doesn't care about both of them.
Well a bit exaggerated. Seen two Fortune 500 companies moving all never stuff to Kotlin on backend on my own eyes (for the reason I mentioned above) in some branches.
sourcekit-lsp works really well, VSCode integration is solid[1]. I've been using VSCode+dev-containers+sourcekit-lsp for a couple years now for Linux development on macOS and it has been really nice.
I agree that this is a must-have for idiomatic Swift. It is really hard to write the long-named-functions and get all the variable names correct without reasonable autocomplete.
I was curious and noticed that this looks reasonable: https://github.com/emacs-lsp/lsp-sourcekit
Emacs + lsp-mode + sourcekit + company-mode etc looks reasonably close to what I get with Rust in Emacs.
If I were doing application development I'd maybe consider Swift.
VS Code isn’t too bad, it after ~20 years of Xcode/Project Builder, muscle memory for keybinds and UI in general is strong. Hoping that someone uses the LSP to write a cross platform “Xcode Lite” or something along those lines.
It wasn't too bad to switch for me, but the problem is going back and forth. I don't love over-customizing my IDE but I've created my own keybindings for the commands I mis-type most (Command-R to run being the main culprit). Both Xcode and VSCode support custom key bindings and this isn't something that the LSP is responsible.
UI is a different matter. Xcode is still miles ahead in performance tooling.
It’s not a commercially developed language; it’s open source and many of its features have been developed outside of Apple.
Comment was deleted :(
Flutter desktop app support has been on Ubuntu since 2021, but not sure if that ever got anywhere.
I quite enjoyed following a Flutter/Dart tutorial[0] a couple of years ago. Quite enjoyed the combo. If anyone fancies trying it, it's probably also the best tutorial I've ever seen. Really well structured and just the right amount of detail based on the place in the tutorial.
[0] https://www.youtube.com/watch?v=1ukSR1GRtMU (video)
Top comment: "don't follow this tutorial [because it's outdated]" :(
I don't see that one. There's one from 3 weeks ago that liked the course. I did do it years ago though, so it could be outdated now.
I had to use Flutter and Dart for a job a couple of years back and found this video series an excellent guide when learning about them too. Would recommend to anyone looking to learn either too.
Yes flutter works on Linux. In fact the Ubuntu installer/OOBE is written in Flutter.[0] Not sure how this is related to the OP though.
[0] https://ubuntu.com/blog/how-we-designed-the-new-ubuntu-deskt...
Comment was deleted :(
The article doesn't summarise the differences between developing these cross-platform apps vs only targetting Apple and that is the most important information really.
Did I miss it?
Comment was deleted :(
[flagged]
[flagged]
I spent 3-years with Swift recently
Makes me want to ask: Why? Why do this?
It is a decent language for 2005. But it has some serious shortcomings (reference counting garbage collector? Really?)
The worst thing IMO is its dreadful support for threads. The "DispatchQueue" seems to be a wrapper around "fork/renice". There is no attempt at memory protection.
But it is full of little niggles that get very irritating in this day and age.
I never used Objective-C so it may be a vast improvement on that.
It is no longer 2005, and we deserve, and we have, better languages.
My time as an Apple developer left me with the overwhelming sensation that Apple hates its developers. So much cool looking stuff that mostly worked...
ARC is for classes, structs use don’t have that and classes are heavily discouraged.
DispatchQueue is anything but fork/renice. Also there is async/await now. GCD should be used for concurrent work only now, not async work.
Memory protection is fully implemented in Swift 5.10, but compilation only warns, enabled by default as errors in Swift 6.
I really like the struct-based method of modeling data in Swift. The language makes this very convenient. Unfortunately the new Observation framework which is at the center of SwiftUI requires classes.
https://forums.swift.org/t/any-future-directions-for-support...
This makes sense, observation requires a durable identity, which structs don’t have.
Two struct might be the same, but when I observe for changes in one, but not another, a distinction arises which is best captured by object-based identity
I did obj-c on a popular consumer app about 10 years ago. Recently had to make an app. I used async/await and SwiftUI heavily. Used observableobject and actors as well. It’s very nice, much like a React/typescript app. UIs used to be torture
I did have to build some things that I felt should have come standard. For example, I had to build a class that provides a thread-safe way to enqueue objects and process them in a background task, which used DispatchQueue internally.
By and large, it’s a world of difference from what it was and my experience has been joyful. Xcode cloud just worked so that’s cool. Profiling is wonderful (signposts etc). Could there be improvements? Sure. Are there other languages with better features? I think so. But I haven’t found myself longing much for something provided by other languages and platforms
Point is, I no longer dread iOS development. In fact, it’s quite fun.
I'm coming back to iOS development after years of doing web stuff. SwiftUI will feel very familiar to anyone that's done React and massively reduces the amount of boilerplate and ceremony it takes to build for Apple platforms. It has some rough edges but overall feels like the most modern mainstream UI toolkit now.
> I did have to build some things that I felt should have come standard. For example, I had to build a class that provides a thread-safe way to enqueue objects and process them in a background task, which used DispatchQueue internally.
That is DispatchQueue. Or NSOperationQueue. Or preferablly Swift concurrency.
Most wrappers around dispatch queues are unnecessary and use it incorrectly. (I would say this is true of operation queues themselves.) Swift concurrency is better than dispatch, though.
> Swift concurrency is better than dispatch, though.
For some things, sure.
FWIW the concurrency story has been getting substantially more attention over the past couple of years with first-class language support. Swift 6 aims to be data-race-safe by default.
2005? Swift is from 2014.
I'm not sure where you get your references from but Swift is one of the most modern and advanced languages out there.
The documentation of Apple is worse than hot garbage though. As in, at least with hot garbage you have something.
What do you mean? Apple has lots and lots of documentation saying that function signatures exist! (/s just in case)
I've gotten better at navigating the Apple docs, but yea, they are not the best. The one thing I will say, when they give code snippets in their docs, the code snippets are really good. But you just need to read the API of a framework or see the functions tied to a type, it could be a lot better.
It's an interesting value proposition. But can I take my existing SwiftUI app and have a path towards porting them to Linux and windows? How foreign would they look since Apple's patterns aren't the same.
I had an extremely negative experience creating apps in Swift.
I can't see any logical reason why people would not use Electron/Tauri.
Swift doesn't allow you to have full control of what you want to do.
I built a whole macOS [ fixkey dot ai] app in Swift, and it was a very painful development experience.
Were you new to Swift? It for sure has its issues, but lack of control wouldn’t make it on my list.
Crafted by Rajat
Source Code