Hacker News

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

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

do you have a link? my google-fu failed me

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?

This only targets Gtk3 and not Gtk4 or libadwaita though. Seems a little end-of-life.

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

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.

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.

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

> 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?

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.

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.

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

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?

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

Oh, I meant the Arc Browser[0]. Wraps Chromium with a Swift GUI layer

[0]https://arc.net/

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.

It says the runtime is under GPL3. Does the copyleft apply to all Flatpak apps written using Swift?

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)

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.

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 hate Qt, the apps look non-native and don't obey Ubuntu's appearance settings and fonts.

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.

And it's a Google project, which means as soon as the low-hanging promo fruit is harvested it will immediately go EOL.

I would argue that Qt with QML is the best combo. See: 39848069

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 love the internal/external labeling. With a little thought it can make for code that reads more nicely than is possible otherwise.

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) { ... }

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.

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.

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.

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.

Why doesn't Swift run on other Linux distributions?

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?

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.

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

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.

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.

Top comment: "don't follow this tutorial [because it's outdated]" :(

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.

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

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.

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.