6 ms·

> On macOS ... going forward, it’s likely that new capabilities and evolutions of the design language will be provided for the latter [SwiftUI] but not the form

> On macOS ... going forward, it’s likely that new capabilities and evolutions of the design language will be provided for the latter [SwiftUI] but not the former [AppKit]. I think this is vastly over-stating the technical churn of UI development on macOS. While we're definitely seeing new UI toolkits introduced that are Swift-only (like the new Charts.framework[0]), nearly every Mac app Apple ships is written using AppKit. For example, I just verified (`otool -l PATH_TO_APP_BINARY`) that Mail, App Store, Notes, Music, Xcode[1], and Photos all link against AppKit, and none link against SwiftUI (on macOS 12.4 21F79, which I'm running). There is, in my opinion, approximately zero chance that Apple either: (A) rewrites all of the UI in all of their apps, replacing AppKit with SwiftUI, in even the medium-term, or (B) starts treating AppKit apps as second-class citizens by introducing a new design language only available from SwiftUI. Yes, we're going to keep seeing cool new widgets and features which are only available from Swift. No, the platform's design language is not going change in a way that makes AppKit apps obsolete. [0]https://developer.apple.com/documentation/Charts https://developer.apple.com/documentation/Charts [1]I bet Xcode links SwiftUI somewhere for IDE integration, but I'm specifically referring to the UI implementation, parts of which have been in development since, like, NeXTSTEP and are certainly built using Objective-C & AppKit.

jolux 4y ago
Aren't App Store and Photos Mac Catalyst apps?
- favorited 4y ago
  Nope! Both are fully native macOS apps, at least on the version of Monterey that I'm running. You can examine which frameworks a binary links by running `otool -l /System/Applications/Photos.app/Contents/MacOS/Photos`. Traditional macOS Cocoa apps will link AppKit, while Catalyst apps will link UIKit. For example, if you run that command with a Catalyst app (e.g., Messages or Maps), you'll see that those apps link against `/System/iOSSupport/System/Library/Frameworks/UIKit.framework/Versions/A/UIKit`, and AppKit is nowhere to be found.
  - astrange 4y ago
    Photos on the Mac actually uses their own private reimplementation of UIKit called UXKit from before Catalyst. (So does Twitter on the Mac, which was written by a developer on the original iPhone.)
    - jolux 4y ago
      The new Twitter app does use Catalyst though.
  - jolux 4y ago
    Interesting, I thought I had heard that App Store was Catalyst now for some reason.
    - favorited 4y ago
      It does kinda look like a Catalyst app, with its navigation stack, whitespace, etc.
tacotacotaco 4y ago
I would remind you that Microsoft disowned MFC and aggressively pushed all developers off of win32api once .net was released. Then they went about rewriting visual studio in .net and possibly the office suite as well. I hope Apple doesn’t attempt this because, in my opinion, I don’t think Microsoft’s products benefited from that churn.
- xyzzy_plugh 4y ago
  This is an extreme exaggeration. The shit you can do with MFC is still frightening, even today.
  - nu11ptr 4y ago
    > The shit you can do with MFC is still frightening, even today. Only vaguely familiar with MFC. Elaborate?
    - nyanpasu64 4y ago
      Foxit Reader was (is?) developed using MFC.
      - pcwalton 4y ago
        To be fair, the first version of Foxit Reader is from no later than 2005. Its contemporaries were, like, Kazaa and Winamp.
- pjmlp 4y ago
  And yet a couple of devs sabotaged C++/CX efforts to the point that C++/WinRT with WinUI 3.0 isn't a match to MFC in tooling.
jreese 4y ago
On the flip-side, it's worth keeping in mind where the puck is heading. Every "new" macOS app from Apple (eg, Shortcuts, System Settings, and even recent refreshes of old apps) has been written in either SwiftUI or Catalyst. A bunch of these still link to AppKit here and there, but it seems pretty clear that no new developement is breaking ground with AppKit. Similar to the Carbon/Cocoa split, I'm sure we'll see AppKit supported well into the future, especially since we just passed the latest major architecture transition. But that doesn't mean AppKit isn't a dead end.
- favorited 4y ago
  That's totally fair, but I think the point that "every 'new' macOS app from Apple ... has been written in either SwiftUI or Catalyst" isn't really surprising. New features are probably going to rely more on newer technologies – especially in places like Shortcuts & System Settings, where the legacy approaches had non-trivial security implications. And, at least so far, we've only seen Catalyst apps from Apple when either: (A) an app was being ported from iOS because it didn't already have a native Mac counterpart (e.g., TV, News, Podcasts), or (B) the Mac version was significantly behind its iOS counterpart from a feature perspective (e.g., Messages). I had written a diatribe earlier about how I don't see this as equivalent to the Cocoa/Carbon situation, but deleted it because I'm being long-winded enough already. It boiled down to the fact that Carbon existed specifically to help port apps from a legacy OS to what Apple was loudly declaring to be the future: OS X. Carbon was a way for apps to get off the sinking ship that was the "classic" MacOS. I mean, they had a funeral for it! https://i.imgur.com/KjFh63u.jpg https://i.imgur.com/KjFh63u.jpg 20 years from now, will Apple's macOS apps contain more Swift+SwiftUI than Objective-C+AppKit, probably! But I'm not worried about AppKit being a "dead end" until they rewrite Mail, Keynote, and Xcode – because they have significantly more invested in those apps than I have in my AppKit apps. (For the record, I love SwiftUI, and use it whenever I can! I just have no expectations that AppKit is going away any time soon.)
- Klonoar 4y ago
  The Music.app rewrite is AppKit-based, so it's not unheard of for Apple to still reach for AppKit internally.
ketralnis 4y ago
Apple themselves aren't particularly quick at adopting the guidance that they give to developers. iTunes was carbon well after Apple was telling developers to stop using it
pjmlp 4y ago
Apple clearly stated at WWDC 2022, that the best days of Objective-C and AppKit/UIKit are behind them, they even had a slide for it in case there were any doubts.
- sandyarmstrong 4y ago
  Yup. Even the "What's new in AppKit?" talk pushed using SwiftUI for things like Settings due to controls only available in SwiftUI.

jolux 4y ago

Aren't App Store and Photos Mac Catalyst apps?

favorited 4y ago
Nope! Both are fully native macOS apps, at least on the version of Monterey that I'm running. You can examine which frameworks a binary links by running `otool -l /System/Applications/Photos.app/Contents/MacOS/Photos`. Traditional macOS Cocoa apps will link AppKit, while Catalyst apps will link UIKit. For example, if you run that command with a Catalyst app (e.g., Messages or Maps), you'll see that those apps link against `/System/iOSSupport/System/Library/Frameworks/UIKit.framework/Versions/A/UIKit`, and AppKit is nowhere to be found.
- astrange 4y ago
  Photos on the Mac actually uses their own private reimplementation of UIKit called UXKit from before Catalyst. (So does Twitter on the Mac, which was written by a developer on the original iPhone.)
  - jolux 4y ago
    The new Twitter app does use Catalyst though.
- jolux 4y ago
  Interesting, I thought I had heard that App Store was Catalyst now for some reason.
  - favorited 4y ago
    It does kinda look like a Catalyst app, with its navigation stack, whitespace, etc.

tacotacotaco 4y ago

I would remind you that Microsoft disowned MFC and aggressively pushed all developers off of win32api once .net was released. Then they went about rewriting visual studio in .net and possibly the office suite as well. I hope Apple doesn’t attempt this because, in my opinion, I don’t think Microsoft’s products benefited from that churn.

xyzzy_plugh 4y ago
This is an extreme exaggeration. The shit you can do with MFC is still frightening, even today.
- nu11ptr 4y ago
  > The shit you can do with MFC is still frightening, even today. Only vaguely familiar with MFC. Elaborate?
  - nyanpasu64 4y ago
    Foxit Reader was (is?) developed using MFC.
    - pcwalton 4y ago
      To be fair, the first version of Foxit Reader is from no later than 2005. Its contemporaries were, like, Kazaa and Winamp.
pjmlp 4y ago
And yet a couple of devs sabotaged C++/CX efforts to the point that C++/WinRT with WinUI 3.0 isn't a match to MFC in tooling.

jreese 4y ago

On the flip-side, it's worth keeping in mind where the puck is heading. Every "new" macOS app from Apple (eg, Shortcuts, System Settings, and even recent refreshes of old apps) has been written in either SwiftUI or Catalyst. A bunch of these still link to AppKit here and there, but it seems pretty clear that no new developement is breaking ground with AppKit. Similar to the Carbon/Cocoa split, I'm sure we'll see AppKit supported well into the future, especially since we just passed the latest major architecture transition. But that doesn't mean AppKit isn't a dead end.

favorited 4y ago
That's totally fair, but I think the point that "every 'new' macOS app from Apple ... has been written in either SwiftUI or Catalyst" isn't really surprising. New features are probably going to rely more on newer technologies – especially in places like Shortcuts & System Settings, where the legacy approaches had non-trivial security implications. And, at least so far, we've only seen Catalyst apps from Apple when either: (A) an app was being ported from iOS because it didn't already have a native Mac counterpart (e.g., TV, News, Podcasts), or (B) the Mac version was significantly behind its iOS counterpart from a feature perspective (e.g., Messages). I had written a diatribe earlier about how I don't see this as equivalent to the Cocoa/Carbon situation, but deleted it because I'm being long-winded enough already. It boiled down to the fact that Carbon existed specifically to help port apps from a legacy OS to what Apple was loudly declaring to be the future: OS X. Carbon was a way for apps to get off the sinking ship that was the "classic" MacOS. I mean, they had a funeral for it! https://i.imgur.com/KjFh63u.jpg https://i.imgur.com/KjFh63u.jpg 20 years from now, will Apple's macOS apps contain more Swift+SwiftUI than Objective-C+AppKit, probably! But I'm not worried about AppKit being a "dead end" until they rewrite Mail, Keynote, and Xcode – because they have significantly more invested in those apps than I have in my AppKit apps. (For the record, I love SwiftUI, and use it whenever I can! I just have no expectations that AppKit is going away any time soon.)
Klonoar 4y ago
The Music.app rewrite is AppKit-based, so it's not unheard of for Apple to still reach for AppKit internally.

ketralnis 4y ago

Apple themselves aren't particularly quick at adopting the guidance that they give to developers. iTunes was carbon well after Apple was telling developers to stop using it

pjmlp 4y ago

Apple clearly stated at WWDC 2022, that the best days of Objective-C and AppKit/UIKit are behind them, they even had a slide for it in case there were any doubts.

sandyarmstrong 4y ago
Yup. Even the "What's new in AppKit?" talk pushed using SwiftUI for things like Settings due to controls only available in SwiftUI.