Live data from Hacker News

SwiftUI After 7 Years

ykvm.com

61–70 of 343 posts

Re: SwiftUI After 7 Years

#61

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

I wonder what experts think of this other option: going fully native for one platform then vibe-porting it to others.

It's never "just working", you'll still have to debug the vibe-ported apps. And you won't be good at it if your devs don't actually know the target platform.

All that to say, I don't think that vibe-porting will give you more than cross-platform. With cross-platform, at least your engineers understand the codebase.

Re: SwiftUI After 7 Years

#62
This seems to be a popular ‘controversial’ topic. I’ve been using SwiftUI for production applications and games since 2021. I drop down UIKit, Metal, or core animation when needed. But that’s no different than when I was making games in UIKit and would drop down to core animation or glyph renderers written in C etc.

Data Flow: The author claims there’s no way to know when things update. Not only does experience help here but there are profile tools that tell you when and where things are updated. This isn’t black magic. Keep Views small, be careful how you hand around data. @environment is super cool but can have a cascade effect. This was greatly improved iOS 17+ and I wouldn’t support anything older than iOS 17.

GeometryReader: Occasionally I’ll use this. It’s kind of a necessary evil when dealing with certain view complexity. It can also be a sign that you’re doing something wrong.

API Stability and performance: Apple users upgrade. There’s no reason that you should be supporting iOS 17 at this point — even iOS 18 is roughly 2%% of our user base across several apps. I’ve been using SwiftUI without major performance issues but I also don’t early optimize. I profile and fix as needed. One of the early studios I worked for wrote all our games in UIKit as prototypes, when performance tanked we’d switch to the appropriate tools (eg. OpenGL) where it was necessary — like in the core game.

I could go on but in the end just use the right tool for the job, if you’re not proficient in SwiftUI or it isn’t going to work for your cross platform project, you have a lot of other alternatives. For me though, it’s been amazing to work with. I stepped away from iOS programming for 3 - 4 years because I was burnt out using storyboards, dealing with massive view controllers, and all the boiler plate it’d take to get a view up and going in UIKit. SwiftUI roped me back in.

* Quick addition edit: Cross platform for iOS, iPad, macOS has never been good. I’ve found recent updates have made things better to the point of tolerable and it’s nothing like when we had to post-fix an ~ipad to our Nibs — There has never been a ‘glory days’ of cross platform Apple UI libraries.

Re: SwiftUI After 7 Years

#64
SwiftUI was doomed from the beginning. Not only Apple completely blew the implementation, it was actually DoA by a bunch of super bad decisions that ultimately make it incredibly hard to work with and manage, especially on bigger apps.

1. It uses the builder pattern for views (familiar to those who used Java) but for some reason they decided to make it so that the order of the modifiers in the builder matters. Each modifier doesn't actually modify the main view but it modifies what the modifier before it decided to return. This makes no sense as the modifiers should each be modifying the main view to make everything predictable and easy to debug. I'm convinced no one (not even senior devs with 5 years of SwiftUI experience) understands how the ordering of modifiers works. It's just swap them until it does what you want it to.

2. The view lifecycles and code execution path seem random and hidden behind layers of "magic," making it incredibly difficult for developers to trace and debug issues.

3. It is practically impossible to set breakpoints for rendering and view construction, it's impossible to really figure out when re-renders happen and what drives them. I'm convinced SwiftUI apps are incredibly slow not because the SwiftUI implementation itself is slow, it's because, even Apple's own apps probably do a bunch of unnecessary re-renders and one no one seems to have any idea. This is unfortunately another design issue that can't be solved by just making SwiftUI more efficient. It requires simplification and tooling to help developers not footgun themselves.

4. Lots of issues start appearing later on in the development cycle because, for simple apps, bad SwiftUI design decisions and footguns have unnoticeable effects, until the apps gets more complex and things start breaking. Fixing these issues sometimes requires rewriting whole features or spending hours debugging.

5. There seems to be almost no documentation on Liquid Glass. It's laughable that after more than 1 year, Apple has simply refused to document or provide good examples for Liquid Glass, except for maybe couple pages that resemble the brain dump of an engineer that has never passed a writing class in college?

6. Stuff seems to be rapidly changing and breaking from version to version. It took days to make my app look and work the same in iOS 27 as it did on iOS 26, even though iOS 27 is supposed to be a minor bug fix release. We don't even use anything non-standard and don't do any hacks. This defeats the whole purpose of a simple UI framework that can be easily adopted to different platforms (this never used to happen with UIKit).

7. View debugger still has no SwiftUI equivalent. It used to make things so much simpler in UIKit when you could just see the view bounds, pick views apart and understand what's actually happening. SwiftUI has no equivalent other than `.background(.red)`. Terrible.

I don't know how Apple can salvage this beyond just undoing some of these terrible design decisions and making it 1. super simple to work with, 2. stop relying on magic, making things more explicit, and 3. providing actual 1:1 UIKit feature parity.

Re: SwiftUI After 7 Years

#65

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

What I like about Kotlin Multiplatform (KMP) vs Flutter is that KMP is not a framework. For instance, I can write a KMP library and a "pure" Android or iOS app can pretend it is a "pure" Android/iOS library.

That is, pure native apps, can integrate KMP libraries. They cannot integrate Flutter libraries.

In other words, if I write a KMP library, I can ship it for multiple platforms and developers can use it in their Flutter project, or in their pure Android/Kotlin project, or in their pure iOS project.

Re: SwiftUI After 7 Years

#66
post #5

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

Yeah I don't really understand their insistence on these videos. I don't have the time to watch an incredibly hard to watch present babywalk me through the code, hoping I'd catch one modifier I missed that fixes the issue. Just write some docs for god's sake.

Re: SwiftUI After 7 Years

#67

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

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.

I have been involved in two non-trivial Qt mobile apps. Never again.

I don't know what your experience is, and I mean no offence or anything, but the only people I have seen who were happy with Qt for mobile development were people who had never tried to do it with a modern language, like Kotlin.

With Compose Multiplatform and Kotlin Multiplatform, you can write a cross-platform app in a modern language, and that is far better than C++.

Re: SwiftUI After 7 Years

#68

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

Do you have an example of where "the ideas don't combine well"? Or where an imperative approach is truly better?

In my experience the solution is often to use the appropriate architecture underneath your UI layer. Basically you build a data structure that represents your UI and always hand this entire structure to the declarative UI layer. Underneath the UI layer, you can still use imperative code to manipulate the data structures. The benefit of the reactive/declarative approach is that you don't have to think about how changes in the data need to be reflected in the UI. That's the framework's job.

Note: With "data structure" I don't mean "build a shadow DOM". I mean something specialized to your use case.

Re: SwiftUI After 7 Years

#69
post #64

SwiftUI was doomed from the beginning. Not only Apple completely blew the implementation, it was actually DoA by a bunch of super bad decisions that ultimately make it incredibly hard to work with and manage, especially on bigger apps. 1. It uses the builder pattern for views (familiar to those who used Java) but for some reason they decided to make it so that the order of the modifiers in the builder matters. Each m…

1. It's not really the builder pattern, which, in Java, is what you describe as wanting: mutating a single instance. SwiftUI uses result builders to compute a single generic View from the "DSL", but you could do the same thing without the custom syntax, it would just be more verbose.

2. Documentation issue. The lifecycle is standardized, but Apple is terrible as documenting it all in one place. I found this year's "Dive into lazy stacks and scrolling with SwiftUI" WWDC video actually had a pretty good explanation, at least for the lifecycle within lazy containers.

3 and 7. Yes, Apple's tools suck pretty bad. Preview canvas is also still terrible, despite multiple attempts to improve.

4. Not something I've experienced, not sure what you mean.

5. Yeah, Apple's docs suck.

6. Not sure what you mean here either, our stuff looks pretty much the same.

Re: SwiftUI After 7 Years

#70
post #45

Earlier quoted context omitted.

WPF was abandoned at birth, it went years without any attention and then was superseded. Apple has at least been consistent on UI frameworks.

Sort of superseded. In practice WPF is still very often the best option in the complete mess that is window GUIs

Yeah, I like WPF and I still use it for my own apps. In fact, my own software is the only thing keeping me on Windows now. I really should take a look at Avalonia and port my stuff over to Linux.
Post reply on HN