The WWDC 2019 had a major impact on the UI toolkit landscape: while the venerable AppKit APIs remained available, Apple removed the old Carbon APIs and introduced 2 brand new frameworks: Mac Catalyst and SwiftUI.

Apple sporadically mentioned some apps built with these new UI toolkits. In this article, I try to bring a better overview of Apple’s use of AppKit, Mac Catalyst and SwiftUI in the different versions of macOS, from macOS Mojave to macOS Ventura.

AppKit, Mac Catalyst and SwiftUI

Since macOS Catalina, developers can create native UI for their Mac apps using 3 different UI technologies: AppKit, Mac Catalyst and SwiftUI. If you are not familiar with these technologies, here is a brief summary.

AppKit

AppKit is the old Cocoa toolkit, available to Mac developers since Mac OS X 10.0. It is powerful and mature but not the future of Mac development as clearly explained during the WWDC 2022 State of the Union.

Why did I use AppKit to develop Dependencies, an app to analyze dSYM files and create an interactive graph? Dependencies relies on compiler technologies with a lot of C++ code. Using Objective-C and AppKit was the simplest solution.

Mac Catalyst

Native iOS apps are using UIKit, a framework derived from AppKit. Mac Catalyst is the technology to port iOS app using UIKit on the Mac.

Clatters, my iOS app to monitor keywords on Twitter, Reddit and HackerNews, could be a great candidate for Mac Catalyst.

SwiftUI

At the WWDC 2019, Apple not only presented Mac Catalyst but they also announced SwiftUI, a brand new UI framework to create declarative UI. SwiftUI is still young but quickly evolving and the future of iOS and Mac development. SwiftUI is the technology that we use to create our brand new apps at Eimy.

Methodology and tools

The methodology and tools for this article are similar to the ones I created for iOS. If you are interested by an in-depth analysis of iOS, you should check out Apple’s use of Swift and SwiftUI in iOS 15.

For this article, I created a script that:

  • detects a Mac Catalyst app by checking if the binary links to UIKit /System/iOSSupport/System/Library/Frameworks/UIKit.framework/Versions/A/UIKit
  • detects if an app is using SwiftUI by checking if the binary links to /System/Library/Frameworks/SwiftUI.framework/Versions/A/SwiftUI
  • detects if an app is using AppKit by checking if the binary links to /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
  • detects if an app is an AppKit app or a SwiftUI app by checking the symbols NSApplicationMain and s7SwiftUI3AppPAAE4mainyyFZ
  • I excluded all the binaries located inside /System/iOSSupport, as these binaries only support Mac Catalyst and iOS apps

You can download the script detectUIFramework.sh here.

Before jumping into the details, please note:

  • This article only focuses on binaries using native UI frameworks and directly built into macOS.

  • On macOS Big Sur and later, I also counted the frameworks located inside the dyld shared cache.

  • Finally you should take this analysis with a grain of salt. While I believe the overall picture to be accurate, my approach has some limitations due to the simple fact that I don’t have access to the macOS source code and relied on imprecise compilation artifacts.

AppKit vs Mac Catalyst vs SwiftUI

A good overview of the distribution of AppKit, Mac Catalyst and SwiftUI is visible by grouping the apps in 3 categories:

  • Mac Catalyst apps (they might also use SwiftUI and AppKit)
  • Apps using SwiftUI (they don’t use Mac Catalyst but might use AppKit)
  • Apps only using AppKit

As you can see in the graph:

  • AppKit apps account for a huge percentage of apps
  • After a slow start, the number of apps using SwiftUI is quickly growing
  • The number of Mac Catalyst apps reached a ceiling

Detailed analysis

macOS Mojave: Marzipan experiment

With macOS Mojave, Apple ported 4 apps from iOS to macOS using Marzipan, the internal name of the Mac Catalyst technology:

  • Home
  • News
  • Stocks
  • Voice Memos

Marzipan was restricted to Apple’s own use and not open to third party developers. Only 4 low-risks apps were developed with this brand new technology.

macOS Catalina: Mac Catalyst and SwiftUI introduced

With macOS Catalina, Apple opened Mac Catalyst to third party developers while dogfooding with 3 new apps:

  • FindMy
  • PhotoPicker from the Photos app
  • Podcasts

SwiftUI was also introduced but a single app used this technology in macOS Catalina: the Contacts app, a low-risk experiment.

macOS Big Sur: Not an experiment anymore

With macOS Big Sur, several important apps adopted Mac Catalyst:

  • Maps
  • Messages
  • Screen Time
  • Weather Widget

A couple of other apps started to use SwiftUI including:

  • Control Center
  • Dock.prefpane
  • Keychain Access
  • Game Center
  • NotificationCenter
  • PhotosUIApps (private framework)

It is also worth noting that macOS Big Sur introduced redesigned widgets for Notification Center. These widgets are built with WidgetKit, a SwiftUI only framework:

  • Calendar
  • Clock
  • Notes
  • Photos
  • Reminder

macOS Monterey: Brand new SwiftUI apps

In macOS Monterey, only a handful of new apps were built using Mac Catalyst:

  • Books
  • Center Stage (CinematicFramingOnboardingUI)
  • Xcode Previews

What is more interesting is the list of new apps using SwiftUI. Worth noting are:

  • Diagnostics Reporter
  • Feedback Assistant
  • HelpViewer
  • Monterey Screensaver
  • Shortcuts
  • Translation

2 new prefpanes also joined the Dock.prefpane:

  • Displays.prefPane
  • Notifications.prefPane

And a couple of private frameworks started to use SwiftUI:

  • ChartSerializationUI
  • CoreChartSwift
  • Feedback
  • FocusSettingsUI
  • MusicKitInternal
  • NotesUI
  • PreviewsInjection
  • ScreenTimeUICore
  • SleepHealthUI
  • TipsUI
  • VideosUI

macOS Ventura: SwiftUI is the future

With macOS Ventura, it seems that Apple ported the remaining iOS apps to the Mac. Only 3 new apps were added:

  • Clock
  • Continuity Camera’s onboarding (ContinuityCaptureOnboardingUI)
  • Weather

On the other hand, a couple of apps were rewritten in SwiftUI:

  • Font Book
  • System Settings
  • Tips

It is also worth noting that these private frameworks are now using SwiftUI:

  • CloudSharingUI
  • PasswordManagerUI
  • PaymentUI (Apple Pay)
  • SharedWithYou
  • ShazamKitUI

Finer grained analysis

In the following graph, I split the apps in 6 categories:

  • Catalyst apps using SwiftUI
  • Catalyst apps with no SwiftUI
  • SwiftUI apps using AppKit
  • SwiftUI apps without relying on AppKit
  • AppKit apps using SwiftUI
  • AppKit apps with no SwiftUI

Raw Data

For a deeper analysis, you can download the raw data below.

Version Raw Data
macOS Mojave 10.14.6 10.14.6.txt
macOS Catalina 10.15.7 10.15.7.txt
macOS Big Sur 11.4 11.4.txt
macOS Monterey 12.4 12.4.txt
macOS Ventura 13.0b3 13.0b3.txt

Conclusion

Even though we don’t have access to the macOS source code, we can measure the usage of Mac Catalyst and SwiftUI in the built-in apps.

As we saw, the introduction of Mac Catalyst has been carefully planned over multiple years. Apple initially used this new technology for low-risk apps before adopting it for more critical apps like Maps and Messages. 4 years after its introduction, the number of apps using Mac Catalyst seems to stagnate. Most likely Apple already ported all the existing apps to the Mac and is now using SwiftUI for its brand new apps.

Apple took a similar approach for SwiftUI. The first years have been an experiment on a small number of low-risk apps. The use of SwiftUI started to quickly grow with macOS Monterey. In macOS Ventura 12% of the apps are now using SwiftUI.

As previously mentioned, this approach has some limits and while I believe the overall picture to be accurate, I can’t guarantee that the results are perfectly exact. If you think that I missed something, please reach out to me on Twitter.

Update 19.08.2022:

Steve Troughton-Smith pointed out that /System/iOSSupport is a significant chunk of macOS and as such the binaries in this folder (and the related frameworks in the dyld shared cache) shouldn’t be ignored. In the original analysis, I excluded all the binaries located inside /System/iOSSupport, as they only support Mac Catalyst and iOS apps.

Below is the updated graph if you include /System/iOSSupport and group the apps in 3 categories:

  • Mac Catalyst apps (they might also use SwiftUI and AppKit)
  • Apps using SwiftUI (they don’t use Mac Catalyst but might use AppKit)
  • Apps only using AppKit

And here is the corresponding graph if you split the apps in 6 categories:

  • Catalyst apps using SwiftUI
  • Catalyst apps with no SwiftUI
  • SwiftUI apps using AppKit
  • SwiftUI apps without relying on AppKit
  • AppKit apps using SwiftUI
  • AppKit apps with no SwiftUI