Remix.run Logo
SwiftUI After 7 Years: A Story of Mediocrity(ykvm.com)
71 points by mpweiher an hour ago | 32 comments
rayiner 30 minutes ago | parent | next [-]

The problem with complex systems is that you can be dead long before you realize you're dead. Things can continue to seem "pretty good" for a long time just from the inertia of past good decisions and built-up infrastructure. You see some fraying or cracks but everything looks fundamentally sound, until it isn't.

Apple's inability to deploy a new UI framework that's better than the previous one is troubling. This is the company that shifted from Toolbox to Carbon to Cocoa and each step was better than the last. Could Apple build MacOS X and Cocoa today if they didn't already exist? Microsoft's two decades of failure to ship a true successor to Win32 suggests that Microsoft (at least, the operating system side of the company) died a long time ago. I wonder if we'll say the same thing about Apple 10 years hence.

steve1977 6 minutes ago | parent | next [-]

I think the problem with SwiftUI in a way was (or is) that Cocoa was so good. And, at least IMHO, it didn't need replacing, just improving.

But I feel like Apple wanted to appeal to young web devs and tried to offer something more similar to what these are used to.

skydhash 14 minutes ago | parent | prev [-]

I think the main issue is the functional approach. Having a functional approach to state can be quite elegant, but ultimately the computer does not do functional. You have to implement a lot of plumbing to have stuff that is a bit performance (clojure), or just add a veneer of functional over what is essentially a normal state machine (emacs).

React works well, because it's only an abstraction over the real DOM. React only handles your app state. But the DOM mechanism is still very performant and very much imperative. But I don't think something like React would work well in a mobile app, because the UI tree is often very simple on iOS and macOS.

poly2it 9 minutes ago | parent [-]

Functional doesn't mean stateless. I'd argue functional programming is superior for representing state in user interfaces. For a success implementation, see Jane Street's Bonsai:

https://github.com/janestreet/bonsai

cosmic_cheese 21 minutes ago | parent | prev | next [-]

I'm sure many will disagree, but I have doubts that pure declarative-reactive is the "right" shape for an all-purpose native UI framework. In my experience, Kotlin+Compose shares many of the same warts… its main redeeming quality is that it's better than Android Framework (most of the time), which is low bar to clear.

These frameworks have a number of good ideas but they don't necessarily combine in a way that transcends high quality traditional imperative frameworks with declarative-reactive bits sprinkled throughout, at least for more complex apps. SwiftUI and its ilk work best for super simple tabs-and-flat-lists sorts of apps.

rumori 16 minutes ago | parent [-]

I think open source is the right move here. The great thing about Flutter is you get the declarative UI to build a lot of standard screens easily but you can always drop down to lower levels, inspect the standard components, mix and match with your custom implementation. You can mix UKit and SwiftUI but there’s way more friction due to the closed nature of the SDK.

norbert515 2 minutes ago | parent | next [-]

Fully agree (been an early Flutter adopter!). It's always the right too for the right job, declarativness makes a lot of sense for most UIs. UIs are surprisingly more complicated than one might think, there is accessibility/ theming/ keyboard traversal etc., just declaring UI and letting the framework figure out the rest has held up pretty well.

And because of the open source nature you can always drop down in layers, just a few weeks ago I made a very specific engine optimization, all while the application code on-top can stay declarative!

cosmic_cheese 7 minutes ago | parent | prev [-]

Perhaps. Certainly source visibility makes life easier as a dev who has to live with these frameworks on a daily basis. That said, I think frameworks should strive to have a wide and deep enough set of widgets that in most cases, devs won't need to resort to custom implementations to do what they need to.

It also doesn't fix problems inherent to declarative UI, like readability breaking down easily and certain things that would be a cinch in an imperative framework being extremely awkward to implement.

ardit33 7 minutes ago | parent | prev | next [-]

SwiftUI it is the type of framework that makes the easy things easier to accomplish but the harder things harder.

It is a newbie trap. It is great at producing simple apps, or things that don't require intense scrolling, or anything with heavy animations and precise layouts, but when you do something smooth, it is not it. It feels more of a React Native competitor, than a true UIKit replacement.

Also, almost everything that Apple has re-wrote with SwiftUI, came out worse as before (Settings, Spotlight, etc), and that doesn't help.

With AI coding... SwiftUI lost its edge/advantage (easy to layout screens), as now you code less of that directly, and might as well just go fo the framework that allows the most flexibility and gives you the best results for your users.

Apple really needs to either double down on it, and make it such that it has everything that UIKit has (match both features and performance), or just turn it into another optional framework, just as Interface Builder (.xib files) back in the day of Objective-C.

Right now it heavily promotes it as a first class citizen, meanwhile the features are not even parity with UIKit. It is so misleading to newcomers to the platform.

Razengan 2 minutes ago | parent [-]

> With AI coding... SwiftUI lost its edge/advantage

On the contrary, I think AI has made it EASIER to approach SwiftUI now, because AI makes up for SwiftUI's biggest weaknesses: Apple's wonky documentation and the need to know when to fall back to AppKit/UIKit.

the-golden-one 12 minutes ago | parent | prev | next [-]

A similar story to WPF.

tonyedgecombe 8 minutes ago | parent | next [-]

[delayed]

Razengan 4 minutes ago | parent | prev [-]

WPF was stamped out by lack of dogfooding = inability to inspire confidence. Back when I wanted it to succeed, Microsoft was barely using it in any of their own apps.

Apple has used SwiftUI in their OS more than MS/Windows did, and there's quite a few apps on the App Store that -seem- to be made with SwiftUI.

Razengan 28 minutes ago | parent | prev | next [-]

I fell in love with SwiftUI the day it was announced, but as a solo dev I still haven't been able to make a full app with it yet, mostly because of the lack of documentation, and the gaps where you still need to drop down to AppKit/UIKit.

I went through Visual Basic, .NET, WPF, Cocoa, and other random frameworks all professing to be the promised panacea for UI, but I think SwiftUI+SwiftData is the best environment ever.. IF only it could reach its full potential, i.e. do everything that Apple's "legacy" APIs can do.

I even tried using SwiftUI for games: https://i.imgur.com/5aTWbft.mp4

The worst hinderance that cripples and sours the experience is Apple's insistence on a yearly update cycle and the way they advertise those updates: You have to wait for the next WWDC and suffer through videos of uncanny-valley presenters, hoping to catch a glimpse of something that fixes the shit that was bothering you since the last WWDC.

At least Swift has been getting more regular updates since it went open source.

There's no way I'd dare to take on a full Apple-platform app project alone on my own, but I've started dabbling in it again thanks to AI: Codex even converted an old app I made in Visual Basic 900 years ago and had it running in SwiftUI within minutes!

I've even tried to get AI to sift through the WWDC video transcripts so I won't have to waste my mortal lifespan on that.

steve1977 2 minutes ago | parent [-]

> There's no way I'd dare to take on a full Apple-platform app project alone on my own

And that's really sad, because earlier Mac OS X (and even OPENSTEP to a degree) was an Eldorado for boutique developers, not least due to frameworks like Cocoa and Objective-C (despite all the hate it seems to get).

If you knew C, it was not hard to grasp Objective-C (at least it was much easier than say C++ and MFC on the Windows side of things).

formvoltron 33 minutes ago | parent | prev | next [-]

Is the right way to develop mobile apps flutter? or Kotlin multiplatform plus native UIs?

danscan 27 minutes ago | parent | next [-]

There is no right way :)

SwiftUI is good, albeit not without issues, as long as you tolerate them. The same is true for any approach. My most recent app was built in SwiftUI because I have been using React Native in my professional work for so long I wanted a change of scenery.

Each approach has its issues, and it all boils down to a matter of preference and which tradeoffs are appropriate for the project.

krzyzanowskim 4 minutes ago | parent | prev | next [-]

Flutter is not the "right way", due to the nature of Flutter being a lousy reimplementation of a UI frameworks.

rubymamis 29 minutes ago | parent | prev | next [-]

I know people would dismiss this, but I'm going to try to make the case for Qt - I'm currently converting my note-taking app to mobile and it's going very well.

afidrya 23 minutes ago | parent | next [-]

It's licensing is expensive though unless the app is opensource.

preg_match 22 minutes ago | parent | prev [-]

Yes, Qt is mature and high-quality software. If you’re doing OSS, then Qt is truly a no brainer. The amount of C++ you have to write is truly minimal, and it’s not “raw” C++. There’s a lot of tooling and libraries. You can target web now too, and QML is legitimately good.

If KDE can develop a high performance stable desktop, you can design whatever.

SV_BubbleTime 22 minutes ago | parent | prev | next [-]

Flutter has been a great success for us.

livinglist 26 minutes ago | parent | prev [-]

Define right, it’s hard to replicate the native UI especially Liquid Glass on iOS because it’s rendering everything using its own rendering engine, making it hard to feel right on iOS. I have also seen a lot of companies move away from flutter to either native or React Native.

lowbloodsugar 17 minutes ago | parent [-]

Well we all love Liquid Glass. Most loved UX update in iPhone and macOS history. Massive dealbreaker for an app not to look like Liquid Glass. I definitely choose apps based on whether they look like proper Liquid Glass applications instead of the developer taking shortcuts and focusing on working features instead.

lelandfe 14 minutes ago | parent | next [-]

You jest but yes, even as I do not love this new update, an application bucking Apple platform standards personally sours me pretty hard on it.

afavour 7 minutes ago | parent | prev | next [-]

I despise Liquid Glass too but for most users there’s a broad feeling of “it fits” vs doesn’t. And apps with Liquid Glass fit today’s iOS.

livinglist 12 minutes ago | parent | prev [-]

Well I’m a heavy Flutter user myself, and the app I built Hacki often gets reviews saying it doesn’t feel native on iOS. I personally don’t have anything against it and I think Flutter has the BEST developer experience compared to other mobile app dev toolkit/SDKs.

sampton 15 minutes ago | parent | prev | next [-]

SwiftUI is gold compared to SwiftData.

migueldeicaza 22 minutes ago | parent | prev [-]

skills issue

mpweiher 8 minutes ago | parent | next [-]

https://en.wikipedia.org/wiki/Poe's_law

migueldeicaza 2 minutes ago | parent [-]

Let me rephrase, he is not the sharpest knife in the drawer.

In my professional medical opinion, he is at high risk of being replaced by a year old low-end Chinese open source LLM.

migueldeicaza 4 minutes ago | parent | prev [-]

I joked, but reading the post is even more clear - man this poor dude.

He is brute forcing his way through life and broadcasting it on YouTube.

Dunno man, Xogot is made up of almost half a million lines of code. Of those 727 files use SwiftUI, and 65 use UIKit, 119 use AppKit (I did not count the overlap, so they are not mutually exclusive).

Using GeometryReader makes it clear he is living in the past and the fact that he uses printChanges in this year without mentioning the dedicated SwiftUI instrument show a lack of curiosity on the space.