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.
I sure hope they can figure out a way through. Whatever it is, SwiftUI isn't it.
I think this opinion is heavily shared by Swift developers now, but the messaging every WWDC is always "Swift and SwiftUI is the best way to build apps for Apple Platforms", etc.. If you have to keep telling everyone what they don't believe is true, it's a sign there's a problem.
It feels like someone with a lot of organizational power is disconnected from the pulse of the community. SwiftUI is undeniably clean in a lot of ways, it presents beautifully and fits on slides well, but that matters less and less, and this all wasn't really working out even before LLMs disrupted things.
But they do quietly drop or fix them, covertly acknowledging they were mistakes. Often with this messaging: "we have this new shiny thing that is even better than the old shiny thing (that was really a turd)".
Remember "garbage collection"? Or "modern syntax"? Or CocoaJava?
And with hardware they had their "come to Jesus" moment a while ago. And then hit it out of the ballpark with Apple Silicon.
The one for software is still upcoming.
Garbage collection is still there, regardless of the marketing message without fundamentals from CS theory of automatic memory management algorithms, because they need to blame something else other than themselves, Apple does no wrong.
They actually went all in on CocoaJava. I was there for the WWDC.
> Garbage collection is still there
"Garbage collection is deprecated in OS X 10.8. Use ARC instead—see Transitioning to ARC Release Notes."
https://developer.apple.com/documentation/foundation/nsgarba...
Of course they did, until they saw the Objective-C adoption numbers were high enough.
> "Garbage collection is deprecated in OS X 10.8. Use ARC instead—see Transitioning to ARC Release Notes."
ARC is garbage collection, of course mighty Apple won't acknowledge that, because it doesn't suit their marketing, and they are to sell ARC after the Objective-C 2.0 conservative GC failure, given the underlying C semantics.
So they need to sell ARC as the great saviour, so much better than "GC".
https://gchandbook.org/contents.html
https://web.eecs.umich.edu/~weimerw/2008-415/reading/bacon-g...
Nope. Until they saw that (a) CocoaJava was a complete dud, not just technically, but also in terms of developers buy in and (b) Cocoa/ObjC was accepted well by a large part of the dev community.
> > "Garbage collection is deprecated in OS X 10.8. Use ARC
> ARC is garbage collection,
In terms of the Apple ecosystem, "Garbage Collection" refers to the failed attempt to introduce a tracing garbage collector. Apple/OSX always had reference counting (introduced by NeXT pre-acquisition with Foundation in EOF and later in OPENSTEP 4.0), which technically is also a form of garbage collection, but again in this case the terms are distinct.
> So they need to sell ARC as the great saviour, so much better than "GC".
Again, in the Apple ecosystem, "Garbage Collection" always referred to the tracing collector, even before they had to abandon it due to it not working.
And ARC is markedly better than their GC, but only arguable and at best marginally better than the reference counting they had pre-GC, and in some significant sense worse. Which is why I generally don't use ARC. For my style of programming the benefits are minuscule and the drawbacks real.
Apple GC is a form of GC. There is no redefinition going on. It is correct.
However, it is ridiculous to say "we will replace garbage collection with garbage collection" and it is too cumbersome to say "we will replace reference counting garbage collection with tracing garbage collection".
Both "garbage collection" for the tracing garbage collection mechanism and "reference counting" for the reference-counting garbage collection mechanism are correct uses of terminology.
Using these shorthands instead of either the cumbersome complete terms or the confusing other shorthand is perfectly fine.
Although admittedly some Apple zealots started insisting that the Apple shorthands were the correct terminology. Or that programs that were broken by the broken GC had always been broken. Or that what Apple calls "MVC" is actually the correct definition of MVC when it is not.
https://blog.metaobject.com/2015/04/model-widget-controller-...
https://blog.metaobject.com/2017/03/concept-shadowing-and-ca...
It would be great if it was half as bad as SwiftUI.
It’s easy to say they were just trying to be trendy and thus the real flaw was the trend is bad and the fault of worse devs than us (the young web devs mentioned)
The thing that obviates that is the trendy stuff works, yet, SwiftUI doesn’t.
(source: I wrote ObjC/Cocoa as early as 2006, and switched to Flutter as my primary dev kit some years ago: it simply doesn’t have the performance issues mentioned.)
Generally, it is not young web devs fault that SwiftUI exists, and certainly not their fault it still has serious issues 7 years in. The things named in the article as not-working in SwiftUI do work in fine in the others.
But I also really liked Objective-C.
Classic iPhone apps have fixed layouts, and classic Mac apps have a big dynamic document in the centre with mostly fixed toolbars around the sides, and dialogs with fixed layouts. Making a really dynamic layout with OS widgets is a huge pain, so most apps sidestepped it.
As Apple gradually added more and more slightly different sizes of iPhone and iPad, making good UI layouts got harder. Even handling screen rotations is a huge hassle! If iOS had proper support for resizing from the start, screen rotation would be trivial, just another window resize.
Xcode had Interface Builder and autolayout, but I found those to be disastrously fiddly and unusable. Maybe some people like them?
HTML has many problems of its own, but it does have good support for responsive layouts. CSS isn't perfect, but it's vastly better than anything you can find in macOS, iOS, Android or Windows.
It seems to me that SwiftUI was trying to tackle two problems at once: React-style declarative UI, and responsive layout. Those are both good ideas, but trying to tackle both in a single uber-framework and deprecating the lower layers was too ambitious. As somebody said elsewhere in this thread, SwiftUI could have been decent as just an optional helper on top of the existing UIKit / AppKit.
I get their appeal (in the sense of only having to develop one layout), but IMHO, in many cases more strict layouts would be the better choice.
You mention classic apps having a fixed layout, I think that's a good thing.
Not every user interfaces makes sense in portrait AND landscape mode for example.
And the slightly different sizes of iPhones are not really that problematic with something like autolayout.
But I don't think you can cover all requirements with a set of fixed layouts, they do need to be somewhat flexible. Even if all screens were the same size, you'd want to be able to boost the font size for accessibility, and that essentially means scaling the whole UI.
And the slightly different sizes of iPhones are not really that problematic with something like autolayout.
I think something like flexbox is a better fit. There are tradeoffs in each approach, but I usually find a local, modular, bottom-up approach easier to work with than global constraint solving, even though it seems in principle like it should be nice to be able to say "keep this button here in relation to this other button". As you add more constraints like that your layout slowly turns to mush and doesn't actually resize nicely. (Edit to add: I'm probably conflating a few different generations of iOS toolkits here, I realise autolayout is somewhat separate from constraint-based layouts.)
I don't think it's a coincidence that most other UI toolkits have added something like flexbox (including iOS) -- it's not perfect but it fits how people generally think about UIs. Was HTML/CSS the first major UI framework to use flexboxes? That's how I remember it, but maybe it was copied from somewhere else.
Also, you want to localize apps, and different languages have /very/ different amounts of text for the same UI.
It can be problematic regardless of the technical solution, though generally I have to agree with the loudest voices on this thread: SwiftUI is a load of rubbish, UIKit and autolayout (and Interface Builder) was better.
Regarding problems with all layouts: I've got a 2022 model iPhone SE, so smallest screen, and every so often run into an app which just doesn't handle the screensize right. I've seen this happen as a developer with both UIKit and SwiftUI, it's just the type of bug you end up seeing is different.
Multiple 'artboards' for screen sizes/ratios are the solution, which basically just means swapping out a .nib in Interface Builder. Better to just make it explicit.