As I was watching the Keynote I couldn’t help but get really excited about developing for the Mac. I’ve had plans off and on to get Stream running on the Mac – it actually does run on the Mac but it’s just a shell of app. The current Mac implementation is using AppKit. I really wanted to learn AppKit because it’s how all the lovely apps we use today are built. Think of [Safari](https://www.apple.com/safari/) (the UI at least), [Photoshop](https://photoshop.com) (the UI), and my favorites like [Twitterrific](https://twitterrific.com), [Day One](https://dayoneapp.com), [Tot](https://tot.rocks) (I’m writing this post with it), [NetNewsWire](https://ranchero.com/netnewswire/), and [BBEdit](https://www.barebones.com/products/bbedit/) all use AppKit and the list goes on and on and on. It’s the Mac equivalent of Win32 (A.K.A. Windows API.) It’s tried and true. And until now it was the obvious choice for building an app for the Mac.
## The Grizzled Veteran
What I heard: _“If you have an AppKit app keep on plugging away but consider mixing in SwiftUI.”_
AppKit is going to live on. Makes complete sense to me. You can’t just drop a framework serving, I’d imagine, thousands of apps in the wild. Some of the most popular applications on the Mac use this framework, like I mentioned in my opening paragraph. I failed to mention Microsoft’s Office apps. They’re really popular.
Something else to consider. Large portions of the operating system use AppKit. It seems a waste of time to go through the entire operating system and replace all that working code with SwiftUI, doesn’t it?
Remember that old saying “If it ain’t broke, don’t fix it.” A lot of folks will adopt that saying and Apple can’t just drop AppKit on the floor. At least for now.
AppKit will be around for the foreseeable future. When Apple shows that slide with a hint you should start moving your app to SwiftUI, then you know time is short. Until then keep on keeping on and make sure that new code is written in SwiftUI.
## The Utility Player
UIKit is the the most popular framework Apple has ever created. Today’s iOS App Store is full of apps built entirely on UIKit. You can’t make an app without using it – directly or indirectly.
When Apple announces they used [Catalyst](https://developer.apple.com/mac-catalyst/) to bring Messages – which has to be one of the most used UIKit applications on iOS – to the Mac you have to listen.
What I heard: _“If you have a great iPad App today and want to get it on the Mac, use Catalyst.”_
Indeed. Use Catalyst. Seems pretty obvious.
Again, this technology should be good until AppKit is no longer a thing on the Mac. That’ll take years and years, if it happens at all.
## The Rookie
[SwiftUI](https://developer.apple.com/xcode/swiftui/) has a lot of promise. It’s definitely Apple’s preferred way of creating applications moving forward. The abstract nature of it means you get most of the work you need for each platform by coding it once. We’re not talking Java’s promise of write once run anywhere. That obviously didn’t work. We’ve come a long way since then and Apple is definitely pushing the boundaries. Will you have #if’s in your Swift code? Absolutely. Is that a horrible thing? No, it is not. It’s a small price to pay to get your application on all of Apple’s platforms.
What I heard: _“If you’re building a new application, use SwiftUI. It’s the way forward.”_
This changes my calculation for bringing Stream to the Mac. Since it’s in its infancy on the Mac I’m switching to SwiftUI. Once it is completed on the Mac I’ll bring that code back to the iOS version and it’ll stay that way.
The project I’ve always wanted to build will be built from the ground up using SwiftUI for the user experience. That’s just how it has to be to keep it viable for years to come.
Until I’m retired – read as dead – I’m going to invest in SwiftUI.