Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I've noticed that developers who started with UIKit really have a hard time working with SwiftUI. I think this is because it's not just new syntax, it's an entirely different way to think: state is the source of truth, views are ephemeral, and you describe UI instead of managing it.by emehex
- Despite all the trends, I still really like HTML for structure, CSS for styling, and JavaScript for logic.
The boundaries aren’t perfectly clean, and that’s fine. But the separation gives you a useful way to think: structure this first, style it later, add behaviour where needed.
My experience with Compose—though I suspect SwiftUI people will recognise the feeling—is that I have to think about everything, everywhere, all the time.
Then we add some MVVM/UDF flavour. The "ViewModel" knows nothing about the view, despite usually serving exactly one screen. Add some "MutableStateFlow"s, combine them into "ScreenUiState", expose it as a "StateFlow", collect it with lifecycle awareness.
Beautifully decoupled. Extremely testable.
Then the organisation writes no unit tests and relies entirely on two-hour nightly screen tests.
A welcome-page refactor breaks the profile page.
“Didn’t you check the nightly build?”
No. It runs at night.
“Well, that’s your responsibility.”
But you broke it.
“Yes, but it’s your code.”
Then why did we ship it?
Fine. Schedule the postmortem with my mother.
And I’m not blaming mobile developers here. I’m frontend, backend, full-stack, I think AI engineer now. I have personally helped make simple things complicated across the entire stack.
What I like about the web is that one simple screen can be vanilla JavaScript. Another can use Vue. Another can use some specialised spreadsheet component.
People react to that with horror: what if components are duplicated, behave or look slightly different?
Fair concern. But that is real coupling with visible consequences and trade-offs. Somehow we have started treating coupling as something abstract that only exists inside code, rather than something that should produce an actual benefit when removed.
HTML. CSS. JavaScript. Or something close to it.
Maybe I’m getting old.
by peheje - Apple had a real winner with ObjC and AppKit. Swift is horrendously complicated for the benefits it offers over ObjC, and SwiftUI is a massive step backwards from AppKit.
Just MHO, and it’s not going to stop the juggernaut, but there’s just no appeal in moving there for me :( If (when ?) Apple drop ObjC, that’s the day I move to Linux
by spacedcowboy - 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.
Ps. The other upsetting thing about SwiftUI, is that it has hurt the Swift language as well, as the team has had to introduce all kinds of hacks, or obscure features to the language in order to make it work, which made even the Swift language experience worse and more complicated than it should have been.
by ardit33 - 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.
- As a solo app developper for two years mainly for apple platform(previously do networking infra software using C/Go)
After two many trial and fail, now it's quite clear to me that for simple UI I will use swiftUI(such as help sheet or simple toggles), for complex and performance first, I will just use UIKit instead, it save a log of time and actually the imperative UIKit is also quite easy to read and review
the feasibility of review is important because code is not mainly written by agent, though as my understanding of UIKit grows I can smell the bad part and let it rewrite
by mintflow - 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.
by sandoze - 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.
by rayiner