★ SwiftUI Only Makes It Easy to Develop Bad Apps

Paulo Andrade, last month, “ Using SwiftUI to Build a Mac-Assed App in 2026 ”: I recently launched the macOS version of Shopie , an app I first released on the iOS App Store late last year. Shopie helps you keep track of products you’re interested in by letting you create wishlists and notifying you whenever a product’s price, availability, and other details change. Unlike my other apps, where I typically blend AppKit (or UIKit) with SwiftUI, Shopie is built entirely in SwiftUI. I wanted to keep it that way to maximize code reuse across iOS, iPadOS, and now macOS. This post explores how far SwiftUI can take you on the Mac in 2026, especially if your goal is to build an app that feels truly native to the platform. It’s not meant to be an exhaustive review of SwiftUI on macOS. It’s simply a collection of recipes and issues I ran into while porting Shopie , a fairly small app, and keeping it 100% SwiftUI. Andrade’s examples are copious. His conclusion is damning: Apple dropped the ball here. AppKit was ahead of its time and UIKit was a more polished version of AppKit. A serious cross-platform framework that unified the two should have happened long before SwiftUI. Instead, Apple left AppKit to fossilize and then tried to leapfrog the problem. You can see the result everywhere. SwiftUI is productive, modern, and often delightful, right up until you try to make a really good Mac app. Then suddenly you’re fighting the framework for things the Mac solved 20 years ago. There’s something really wrong with SwiftUI. Amongst the apps I use, the best example is Apple Journal.