271–280 of 343 posts
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…
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
SwiftUI is not Swift. It is implemented using complex Swift features, but it is a huge step backwards in dev-ex from autolayout and UIKit.
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
Ah yes, the glory days when you had to sift through 200+ lines of NSLayoutConstraint just to fix a simple layout bug.
If you don't think that way, or you're debugging somebody else's layout, then yeah, it's a nightmare. But it's shockingly easy to just redo the whole layout in that case.
I would only take this article seriously if you have to support old iOS versions. NavigationStack has been around since iOS 16, @Observable since iOS 17. and I'm not sure if the author is aware that GeometryReader hasn't been necessary since iOS 18 added onGeometryChange modifiers. Nearly 100% of users are on iOS 16+. I'm doing some fairly complex work with SwiftUI and I find most components work identically between…
> I'm not sure if the author is aware that GeometryReader hasn't been necessary since iOS 18 added onGeometryChange modifiers. I think the author does not understand how and why to use GeometryReader at all. He literally said "you find yourself wrapping everything in a GeometryReader" which is a different thing from simply measuring. For measuring you could always put GeometryReader into `.background()` and use that…
Regarding GeometryReader: Just read your comment out loud.
Any modern-day Windows developers want to chime in around WinRT and other stuff Microsoft has been up to? I’m still on Win32 and WinForms.
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 everythi…
IMO it goes further than that: It makes easy things easier and hard things impossible.
Earlier quoted context omitted.
Maybe responsive layouts are part of the problem? 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 pro…
Well, you can still have breakpoints, and switch between different structures for e.g. mobile vs desktop, or landscape vs portrait. 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 di…
Also, you want to localize apps, and different languages have /very/ different amounts of text for the same UI.
Earlier quoted context omitted.
This type of story about management getting rid of the old guard is so common and typical, it remains one of the most frustrating aspects of this industry. In the “enterprise scene”, this sort of purge strategy is likely linked to a big percentage of money wasted and sometimes total failure. Why do managers keep making this mistake? “Legacy” is only a bad word in IT. :-(
Because their KPIs are all about making a impact.
(Also, eg Ali Ozer is still there.)
Earlier quoted context omitted.
7 Years of release on Swift UI, 12 years for Swift. This isn't 7 years of development, but 7 - 12 years after release . And to most these past 7 - 12 years are an ongoing beta development. It is unfinished, unpolished with no end in sight. And I have been extremely critical since the beginning. But the problem runs much much deeper. It isn't the technology that is the problem, not the devs who are making it. It is th…
> Instead a lot of Apple's software development can be summarised as resume or KPI bonus driven development. It is not as bad as Google and Microsoft, but it is clear Apple have this problem a well. When did the term “KPI” come into use at Apple? I’m aware it was used in management circles decades ago but I don’t remember it being so common say in 2005. The underlying concept is sound, but the problem with abstractin…