We're 5 years in now and even the most talented and experienced SwiftUI devs aren't building apps that are better than what you could build before, nor does it seem like there are kinds of apps that weren't possible before.
And still, a large chunk of dev energy is spent just trying to make it ‘as good as' before, too. Churn for the sake of churn. Some big apps have fancy new UIs with terrible layout performance, completely squandering the long-held lead Apple's chip teams bought the platform
@stroughtonsmith no worries – this 'large chunk of dev energy' would be wasted anyway. Be it SwiftUI, React Native, Flutter or whatever. That's just people/companies who cannot tell what a decent app is in the first place.
@stroughtonsmith I've personally found SwiftUI apps to feel like imposters. Compared to UIKit, they just feel like they're faking it. So many awkward renders, animations, etc.
@stroughtonsmith .. then there’s the question of whether it fits the UI problem at all.
It fits the static layout quite well, but for a dynamic interface it’s often easier to think in terms of “what should be happening, and in what sequence” rather than “this is what it is”.
Being able to drop down from declarative to imperative programming easily would be great.
Perhaps a more appropriate way to use this would be to generate imperative code from the declaration.
@stroughtonsmith Fundamentally declarative programming is best kept in academia.
It’s cool, but the problem is that the abstraction breaks down as soon as non-functional aspects become important, eg performance.. or you have a bug.
Now suddenly you need to understand how it works.. or rather how its engine works.. which happens to be a black box.. so you need to probe it, to theorize about what might be going on.. and the whole thing descents from high level abstraction into tinkering.
@stroughtonsmith The goals of SwiftUI are ease of learning, ease of use, less code, cross-platform.
Your measuring stick here is what could be built before or things that weren't possible before. That is, uniqueness or newness. Or else performance of apps that did exist.
Hopefully you see that you are measuring non-goals and failing to measure things (new devs, new apps, dev productivity, app availability on more platforms) that would tell you whether SwiftUI is meeting its goals or not.
@gregtitus what SwiftUI's goals are and what people claim SwiftUI's goals are are two different conversations. SwiftUI is a great tool for many things (though I would very much argue cross-platform isn't one of them, and is where its limitations become most stark)
@stroughtonsmith But there sure are a lot of crap Catalyst apps (mainly from Apple) that do less than their old Mac versions, are less stable, and feel about as alien as Electron apps. 🎉
@stroughtonsmith What it certainly did NOT do is make coding more accessible to people with some light scripting/automation chops. The dream of “anyone can code” is, if anything, less true now than five years ago.
@stroughtonsmith for the performance issue I blame ObservableObject and everyone abusing it. I cannot convince devs more experienced than me that any change to a ‘@published’ var makes any view that observes that to redraw itself and its subviews.
@stroughtonsmith I learned to code and make apps thanks to SwiftUI being more accessible. I don’t think @FitWoody_Camp has anything to envy to any app made with UI KIT. For me much quicker (idea to launch in 3 months) and maintainable.
To me, it seems clearer than ever that there's not a progression path with AppKit/UIKit in the past and SwiftUI in the future, as some ideal end point. It's a very popular, easy to use, sideshow, like what Microsoft did with .net perhaps, but it may never make sense to use it for everything, especially if you continue to write in (and keep up with) modern lower-level UI frameworks. That Apple's ‘next' platform (visionOS), didn't go all-in on SwiftUI kinda defines the next 20 years
@stroughtonsmith I wrote couple of apps in last 10 years for customers that use CALayer to animate features on the screen at fast pace. Currently there's no way these could be replaced with SwiftUI - and there does not seem to be a future feature on the roadmap that would do that.
This reminds me of a customer I had in the past, that used scsi protocol over USB to talk to his device - which couldn't be used anymore due to way apple treated some device drivers of the past. :/
SwiftUI is very important to Apple, politically, but you gotta wonder if that's shielding it from some very harsh existential questions internally. Is it being protected because it is itself a worthy successor framework to AppKit & UIKit, or is it actively preventing a worthy successor framework from being built?
@stroughtonsmith I wonder how much the yearly refresh cycle hurts these kinds of efforts. If the team behind SwiftUI were free to release it as a library instead of baked into the OS, would we see it evolve faster. (Same goes for like every Apple API out there.)
@stroughtonsmith have you tried Jetpack Compose? Imo everything SwiftUI should be: open source, frequent updates, not tied to OS versions, can drop to lower levels when needed.
IIRC in the SwiftUI WWDC slack labs, if someone asked for something to be exposed public (eg pixel scroll offset) they’d say “why? Put a use case in a Feedback, we’ll prioritise it based on number of dup.”. So I don’t think they’re going for a comprehensive UI kit, more like a kit for common functionally of apps
@stroughtonsmith ..in my own private Mac frameworks, I use builders to create NSView hierarchies, perform auto-layout, configure views and controls, set callbacks, etc.
That let’s me run as native AppKit, while being able to drop into the debugger to follow the flow of control, mix non-builder code, etc.
It’s not as elegant as full-declarative coding, but it’s fast, easy, flexible and transparent..
@stroughtonsmith I’m starting a new project and with all the rough edges in SwiftUI and the way it forces you into particular architecture patterns I just can’t being myself to use it for the majority of the UI. UIKit is faster, more stable, and more flexible. It requires a bit more code but most of that code increase can be hidden away in helper layout extensions to make constraint based layout easier and shorter.
Add comment