9 ms·

Apple is pretty clear in it's intention of making SwiftUI the blessed UI toolkit, however, they haven't deprecated AppKit or UIKit in any way and keep updating

Apple is pretty clear in it's intention of making SwiftUI the blessed UI toolkit, however, they haven't deprecated AppKit or UIKit in any way and keep updating it, as they demonstrate at every WWDC with "what's new in AppKit" (e. g. for 2024: https://youtube.com/watch?v=McKYDogUICg https://youtube.com/watch?v=McKYDogUICg). They also provide means to mix-and-match AppKit and SwiftUI in both ways. In no way are they trying to "have you believe it's all SwiftUI now". It is simply the next generation of UI frameworks.

lallysingh 2y ago
That's how they treated Carbon, until they didn't.
ChrisMarshallNY 2y ago
I feel that SwiftUI still has a ways to go. I like the ideas and philosophy, but the execution is still a work in progress. First, they really need to beef up the docs. Next, they need to stop punishing people for "leaving the lane." Not everyone wants their app to look and behave like a bundled Apple app. I dislike Autolayout, and UIKit definitely has a lot of "old school" flavor, but with IB and UIKit, I can make an app that can do just about anything that I want.
- PittleyDunkin 2y ago
  I love autolayout. I've never felt it's been so easy to learn how to lay stuff out. InterfaceBuilder felt so confusing and arbitrary and like having to learn an entirely new language just to get basic behavior working correctly. Plus, it didn't compile to code but to a "nib" file you had to work with in abstruse and unintuitive ways. At least I can debug code; how the hell can i debug a nib? Most of the exposed functionality was difficult to google and assumed you knew what all the obscure icons (like springs and arrows and lines) meant. Very confusing and frustrating. Meanwhile autolayout was very intuitive. Define your variables, define your constraints, and it just magically works.
  - ChrisMarshallNY 2y ago
    I generally use storyboards, but I do need to occasionally do programmatic stuff. That's a pain, but I can make it work.
    - saagarjha 2y ago
      Are you still using them? It seems like Apple is basically killing them…?
      - ChrisMarshallNY 2y ago
        Yeah. The Interface Builder/Storyboard Editor is a slow-ass bug farm, but it works. They are still maintaining and improving it. Apple may be pushing SwiftUI, but they aren’t stupid enough to kill off UIKit/AppKit. I’ll lay odds that most AAA programs are still ObjC.
  - Klonoar 2y ago
    I sound like a maniac whenever I express my desire for Autolayout over HTML/CSS. I will in no way deny the sheer power the latter/reach/etc has and I can see why people like it. Autolayout, while tricky to get at first, pretty much "just works" when I write it nowadays... and the older I get, the more annoying I find the cascade in CSS.
- joshstrange 2y ago
  > First, they really need to beef up the docs. This is a common refrain I hear w.r.t. Apple and while I write very little native mobile code I have to agree. It’s so sparse and rarely has more that I should be able to find out by hovering over a function/variable in my IDE. Would it kill them to add a paragraph explain why or how you use the thing? To add code samples? Must be too much for one of the most valuable companies in the world… What kills me is that this is actively hurting their own platforms. I can understand some of Apple’s moves but this one is so incredibly short-sighted.
  - myko 2y ago
    > What kills me is that this is actively hurting their own platforms I don't think they care. Any useful application will be re-created by Apple and bundled with their OS eventually anyway. Outside devs aren't really necessary for anything but games.
  - ChrisMarshallNY 2y ago
    Those of us "of a certain age," know that Apple used to have the best documentation in the industry. Many of the folks that wrote the docs, had more credentials than the ones writing the code.
    - wpm 2y ago
      I love when I find some fantastic doc in the Apple Doc “Archive” with some huge banner at the top reminding me that there is newer documentation available that has, at best, 10% of the content.
- jen20 2y ago
  > Not everyone wants their app to look and behave like a bundled Apple app. As (now just) a user of macOS, that’s EXACTLY what I want - consistency, not the output of some branding or UX person trying to mark their territory.
  - ChrisMarshallNY 2y ago
    As with everything, "it depends." It's entirely possible to have unique branding, yet maintain consistency with standard Apple UX. Just takes flexibility and compromise. Many designers aren't so good at that. On a related note, did you ever try out Kai's Power Tools[0]? Now that was a nonstandard UX. Some folks really loved it, but it was an acquired taste. [0] https://mprove.de/script/99/kai/2Software.html https://mprove.de/script/99/kai/2Software.html
    - jen20 2y ago
      Actually yes! And Kai's Power Goo as well - both of those I hated. I really want apps to fit into the platform, and not try to be special snowflakes, regardless of what the platform is. Admittedly defining what a "Windows app" looks like has got harder over the years, and there were some dark years on the Mac where people tried to rationalize when to use brushed metal and so forth... The broader point is, I'm very glad Apple are making it harder for people to go off piste with regards to look and feel. Some people might be capable of doing a good job, but like with advertising, the well has been poisoned, and I assume that everyone doing it at all has poor intentions. Games get a pass (though I don't personally play any on desktop computers).
  - wpm 2y ago
    Yeah just like the Home app…or the calculator that can’t be resized…or System Settings (oooh which way is the text going to run in this text box? Nobody knows!)… or Game Center, or Apple Music, or any of the other half assed first party apps on the platform that all use different layouts and UI components and behaviors. The consistency you seek is gone, and has been for ages, if it ever even existed.
    - 2y ago
- turnsout 2y ago
  I’m achieving very custom looks in SwiftUI. What exactly do you find punishing?
  - ChrisMarshallNY 2y ago
    Here's an example from a couple of weeks ago: I wrote a small SwiftUI app, to display simple bar charts of data from our social app. Number of active users, vs. ones that haven't signed in, user acceptance/rejection rates, etc. The SwiftUI Charts library is pretty good for this. I consume a CSV file into a dataframe, and add some extra computed properties, etc. I wanted to add the ability to pinch to zoom, so users don't need to look at the entire dataset, and try to find individual days, etc. I banged my head for a couple of days, getting it working the way I needed (TL;DR, I did. Just took a while). I can add a magnification gesture adornment, but the docs for it suck, the docs for the charts suck, the docs for the viewbuilder suck, the docs for the view suck, and even the docs for the dataframe suck. I basically had to find out what I needed, by trial and error, and examining the exposed protocols. Some of the stuff is crazy easy, like translating the pinch to a usable number, but then, I wanted to add a bit of custom handling, for the edges, and allowing the user to pan the chart, while also being able to individually inspect bars (I ended up giving up on that, and have an ugly scrubber scrollbar under the chart). It also doesn't work on the Mac, which sucks, because I do a lot of admin stuff on the Mac. It's a long story, and I'm sure that you would find fault with my work (one of the things geeks love to do, is point out errors made by other geeks), but it shipped, it works, and we've been using it for days. And, in the end, even though it exhibits nonstandard behavior, it looks exactly like a Settings App panel. That's fine. It's a backend dashboard, but I'd be upset if it was something we needed to expose to end-users of the app.

lallysingh 2y ago

That's how they treated Carbon, until they didn't.

ChrisMarshallNY 2y ago

I feel that SwiftUI still has a ways to go. I like the ideas and philosophy, but the execution is still a work in progress. First, they really need to beef up the docs. Next, they need to stop punishing people for "leaving the lane." Not everyone wants their app to look and behave like a bundled Apple app. I dislike Autolayout, and UIKit definitely has a lot of "old school" flavor, but with IB and UIKit, I can make an app that can do just about anything that I want.

PittleyDunkin 2y ago
I love autolayout. I've never felt it's been so easy to learn how to lay stuff out. InterfaceBuilder felt so confusing and arbitrary and like having to learn an entirely new language just to get basic behavior working correctly. Plus, it didn't compile to code but to a "nib" file you had to work with in abstruse and unintuitive ways. At least I can debug code; how the hell can i debug a nib? Most of the exposed functionality was difficult to google and assumed you knew what all the obscure icons (like springs and arrows and lines) meant. Very confusing and frustrating. Meanwhile autolayout was very intuitive. Define your variables, define your constraints, and it just magically works.
- ChrisMarshallNY 2y ago
  I generally use storyboards, but I do need to occasionally do programmatic stuff. That's a pain, but I can make it work.
  - saagarjha 2y ago
    Are you still using them? It seems like Apple is basically killing them…?
    - ChrisMarshallNY 2y ago
      Yeah. The Interface Builder/Storyboard Editor is a slow-ass bug farm, but it works. They are still maintaining and improving it. Apple may be pushing SwiftUI, but they aren’t stupid enough to kill off UIKit/AppKit. I’ll lay odds that most AAA programs are still ObjC.
- Klonoar 2y ago
  I sound like a maniac whenever I express my desire for Autolayout over HTML/CSS. I will in no way deny the sheer power the latter/reach/etc has and I can see why people like it. Autolayout, while tricky to get at first, pretty much "just works" when I write it nowadays... and the older I get, the more annoying I find the cascade in CSS.
joshstrange 2y ago
> First, they really need to beef up the docs. This is a common refrain I hear w.r.t. Apple and while I write very little native mobile code I have to agree. It’s so sparse and rarely has more that I should be able to find out by hovering over a function/variable in my IDE. Would it kill them to add a paragraph explain why or how you use the thing? To add code samples? Must be too much for one of the most valuable companies in the world… What kills me is that this is actively hurting their own platforms. I can understand some of Apple’s moves but this one is so incredibly short-sighted.
- myko 2y ago
  > What kills me is that this is actively hurting their own platforms I don't think they care. Any useful application will be re-created by Apple and bundled with their OS eventually anyway. Outside devs aren't really necessary for anything but games.
- ChrisMarshallNY 2y ago
  Those of us "of a certain age," know that Apple used to have the best documentation in the industry. Many of the folks that wrote the docs, had more credentials than the ones writing the code.
  - wpm 2y ago
    I love when I find some fantastic doc in the Apple Doc “Archive” with some huge banner at the top reminding me that there is newer documentation available that has, at best, 10% of the content.
jen20 2y ago
> Not everyone wants their app to look and behave like a bundled Apple app. As (now just) a user of macOS, that’s EXACTLY what I want - consistency, not the output of some branding or UX person trying to mark their territory.
- ChrisMarshallNY 2y ago
  As with everything, "it depends." It's entirely possible to have unique branding, yet maintain consistency with standard Apple UX. Just takes flexibility and compromise. Many designers aren't so good at that. On a related note, did you ever try out Kai's Power Tools[0]? Now that was a nonstandard UX. Some folks really loved it, but it was an acquired taste. [0] https://mprove.de/script/99/kai/2Software.html https://mprove.de/script/99/kai/2Software.html
  - jen20 2y ago
    Actually yes! And Kai's Power Goo as well - both of those I hated. I really want apps to fit into the platform, and not try to be special snowflakes, regardless of what the platform is. Admittedly defining what a "Windows app" looks like has got harder over the years, and there were some dark years on the Mac where people tried to rationalize when to use brushed metal and so forth... The broader point is, I'm very glad Apple are making it harder for people to go off piste with regards to look and feel. Some people might be capable of doing a good job, but like with advertising, the well has been poisoned, and I assume that everyone doing it at all has poor intentions. Games get a pass (though I don't personally play any on desktop computers).
- wpm 2y ago
  Yeah just like the Home app…or the calculator that can’t be resized…or System Settings (oooh which way is the text going to run in this text box? Nobody knows!)… or Game Center, or Apple Music, or any of the other half assed first party apps on the platform that all use different layouts and UI components and behaviors. The consistency you seek is gone, and has been for ages, if it ever even existed.
  - 2y ago
turnsout 2y ago
I’m achieving very custom looks in SwiftUI. What exactly do you find punishing?
- ChrisMarshallNY 2y ago
  Here's an example from a couple of weeks ago: I wrote a small SwiftUI app, to display simple bar charts of data from our social app. Number of active users, vs. ones that haven't signed in, user acceptance/rejection rates, etc. The SwiftUI Charts library is pretty good for this. I consume a CSV file into a dataframe, and add some extra computed properties, etc. I wanted to add the ability to pinch to zoom, so users don't need to look at the entire dataset, and try to find individual days, etc. I banged my head for a couple of days, getting it working the way I needed (TL;DR, I did. Just took a while). I can add a magnification gesture adornment, but the docs for it suck, the docs for the charts suck, the docs for the viewbuilder suck, the docs for the view suck, and even the docs for the dataframe suck. I basically had to find out what I needed, by trial and error, and examining the exposed protocols. Some of the stuff is crazy easy, like translating the pinch to a usable number, but then, I wanted to add a bit of custom handling, for the edges, and allowing the user to pan the chart, while also being able to individually inspect bars (I ended up giving up on that, and have an ugly scrubber scrollbar under the chart). It also doesn't work on the Mac, which sucks, because I do a lot of admin stuff on the Mac. It's a long story, and I'm sure that you would find fault with my work (one of the things geeks love to do, is point out errors made by other geeks), but it shipped, it works, and we've been using it for days. And, in the end, even though it exhibits nonstandard behavior, it looks exactly like a Settings App panel. That's fine. It's a backend dashboard, but I'd be upset if it was something we needed to expose to end-users of the app.