4 ms·

I think the problem with SwiftUI in a way was (or is) that Cocoa was so good. And, at least IMHO, it didn't need replacing, just improving. But I feel like App

by steve1977 2mo ago

I think the problem with SwiftUI in a way was (or is) that Cocoa was so good. And, at least IMHO, it didn't need replacing, just improving. 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.

monster_truck 2mo ago
Totally agreed. I kind of figured things were going to get shitty when the guy who made autolayout got hounded on so hard that he left. I sure hope they can figure out a way through. Whatever it is, SwiftUI isn't it.
- rudedogg 2mo ago
  > 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.
  - steve1977 2mo ago
    Well the problem now is Apple would need to admit they made a mistake. And Apple does not make mistakes.
    - mpweiher 2mo ago
      Yes, they don't ever openly admit mistakes. 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.
      - mort96 2mo ago
        SwiftUI is too big to silently drop. It is too difficult to silently fix.
        steve1977 2mo ago
        So the only way out is something new again.
        mpweiher 2mo ago
        Happy to rename my stuff "Objective-Swift" :-)
      - pjmlp 2mo ago
        CocoaJava was when they were not certain devs educated in C++ and Object Pascal would ever accept Objective-C. 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.
        mpweiher 2mo ago
        > CocoaJava was when they were not certain devs educated in C++ and Object Pascal would ever accept Objective-C. 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/nsgarbagecollector https://developer.apple.com/documentation/foundation/nsgarba...
        pjmlp 2mo ago
        > They actually went all in on CocoaJava. I was there for the WWDC. 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://gchandbook.org/contents.html https://web.eecs.umich.edu/~weimerw/2008-415/reading/bacon-garbage.pdf https://web.eecs.umich.edu/~weimerw/2008-415/reading/bacon-g...
    - NetMageSCW 2mo ago
      Apple Maps says otherwise.
  - pjmlp 2mo ago
    If you want to see this behaviour dialed to 11, check how Microsoft management talks about WinUI 3.0, and the harsh reality of its sore state of development experience. It would be great if it was half as bad as SwiftUI.
- joenada 2mo ago
  Obj-C and Autolayout were absolutely awful to work with. SwiftUI is at least the right idea for a UI framework, it's just been implemented horribly.
refulgentis 2mo ago
It’s a seductive idea, but it displaces who is responsible for the poor framework development onto users of the framework. 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.)
- pjmlp 2mo ago
  It sure does, hence why there was this whole drama with a new render engine for Flutter.
  - refulgentis 2mo ago
    Shaders compiled at startup vs. not, not “who knows why a repaint is happening”
    - pjmlp 2mo ago
      It was a bit more than that, including how out of place it looked in fruity platforms.
      - refulgentis 2mo ago
        No, they did not change the renderer because of Apple. That is a complaint about Flutter, the iOS-aping widget set can't stay up with current iOS, and I don't think they have a real solution yet. There's something about pulling out the Material UI library from Flutter itself that's supposed to help (I don't quite understand why, modulo "we can make a focused team work in a package instead of in the big ol' framework and that'll be easier") 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.
lilbigdoot 2mo ago
I never really tried out Cocoa. What did you like about it?
- steve1977 2mo ago
  At least for me, it just had/has the right mix of abstraction and simplicity. It just "ticked" in a way that for example MFC didn't. But I also really liked Objective-C.
  - iainmerrick 2mo ago
    Cocoa and Objective-C are both great, but I think there's one huge problem that they never managed to solve well: responsive layouts. 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.
    - jstsch 2mo ago
      Good points. It's just that responsive layouts have not been fixed anywhere. Also on the web, it is way too hard. How often don't you see a box floating over some background photo and then covering the focal point, e.g. the face? Sure, it can be done, but the permutations of testing are simply too large for mere mortals. 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.

monster_truck 2mo ago

Totally agreed. I kind of figured things were going to get shitty when the guy who made autolayout got hounded on so hard that he left. I sure hope they can figure out a way through. Whatever it is, SwiftUI isn't it.

rudedogg 2mo ago
> 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.
- steve1977 2mo ago
  Well the problem now is Apple would need to admit they made a mistake. And Apple does not make mistakes.
  - mpweiher 2mo ago
    Yes, they don't ever openly admit mistakes. 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.
    - mort96 2mo ago
      SwiftUI is too big to silently drop. It is too difficult to silently fix.
      - steve1977 2mo ago
        So the only way out is something new again.
        mpweiher 2mo ago
        Happy to rename my stuff "Objective-Swift" :-)
    - pjmlp 2mo ago
      CocoaJava was when they were not certain devs educated in C++ and Object Pascal would ever accept Objective-C. 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.
      - mpweiher 2mo ago
        > CocoaJava was when they were not certain devs educated in C++ and Object Pascal would ever accept Objective-C. 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/nsgarbagecollector https://developer.apple.com/documentation/foundation/nsgarba...
        pjmlp 2mo ago
        > They actually went all in on CocoaJava. I was there for the WWDC. 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://gchandbook.org/contents.html https://web.eecs.umich.edu/~weimerw/2008-415/reading/bacon-garbage.pdf https://web.eecs.umich.edu/~weimerw/2008-415/reading/bacon-g...
  - NetMageSCW 2mo ago
    Apple Maps says otherwise.
- pjmlp 2mo ago
  If you want to see this behaviour dialed to 11, check how Microsoft management talks about WinUI 3.0, and the harsh reality of its sore state of development experience. It would be great if it was half as bad as SwiftUI.
joenada 2mo ago
Obj-C and Autolayout were absolutely awful to work with. SwiftUI is at least the right idea for a UI framework, it's just been implemented horribly.

refulgentis 2mo ago

It’s a seductive idea, but it displaces who is responsible for the poor framework development onto users of the framework. 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.)

pjmlp 2mo ago
It sure does, hence why there was this whole drama with a new render engine for Flutter.
- refulgentis 2mo ago
  Shaders compiled at startup vs. not, not “who knows why a repaint is happening”
  - pjmlp 2mo ago
    It was a bit more than that, including how out of place it looked in fruity platforms.
    - refulgentis 2mo ago
      No, they did not change the renderer because of Apple. That is a complaint about Flutter, the iOS-aping widget set can't stay up with current iOS, and I don't think they have a real solution yet. There's something about pulling out the Material UI library from Flutter itself that's supposed to help (I don't quite understand why, modulo "we can make a focused team work in a package instead of in the big ol' framework and that'll be easier") 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.

lilbigdoot 2mo ago

I never really tried out Cocoa. What did you like about it?

steve1977 2mo ago
At least for me, it just had/has the right mix of abstraction and simplicity. It just "ticked" in a way that for example MFC didn't. But I also really liked Objective-C.
- iainmerrick 2mo ago
  Cocoa and Objective-C are both great, but I think there's one huge problem that they never managed to solve well: responsive layouts. 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.
  - jstsch 2mo ago
    Good points. It's just that responsive layouts have not been fixed anywhere. Also on the web, it is way too hard. How often don't you see a box floating over some background photo and then covering the focal point, e.g. the face? Sure, it can be done, but the permutations of testing are simply too large for mere mortals. 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.