{"id":51840,"date":"2026-05-08T16:01:32","date_gmt":"2026-05-08T20:01:32","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=51840"},"modified":"2026-05-08T16:01:32","modified_gmt":"2026-05-08T20:01:32","slug":"building-shopie-for-mac-with-swiftui","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2026\/05\/08\/building-shopie-for-mac-with-swiftui\/","title":{"rendered":"Building Shopie for Mac With SwiftUI"},"content":{"rendered":"

Paulo Andrade<\/a> (Mastodon<\/a>):<\/p>\n

\n

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.<\/p>\n

[…]<\/p>\n

In a proper Mac-assed app, opening a context menu should enable a focus ring around the item the menu applies to, even when that item isn’t selected. […] Reminders, Notes, and Stocks are all SwiftUI apps on macOS, yet each behaves differently. Reminders only gets this right because it’s using List<\/code>, which inherits the behavior from NSTableView<\/code>.<\/p>\n

[…]<\/p>\n

SwiftUI has already gone through three drag-and-drop eras. […] But the problem with all three<\/em> is that you have no visibility into the drag session unless you are the drop target.<\/p>\n

[…]<\/p>\n

Once again, the issue isn’t that keyboard support is impossible in SwiftUI. It’s that the framework gives you just enough to cover the simple cases, then gets in your way the moment you try to match what Mac apps have done for decades.<\/p>\n<\/blockquote>\n\n

David Deller<\/a>:<\/p>\n

\n

Spent most of the day fighting with SwiftUI and getting nowhere. Hate it when this happens. The solution, as always, was to redo some parts in AppKit. I wish I had done this whole app in AppKit from the start.<\/p>\n

SwiftUI never gave me this much trouble on iOS, but it's so much worse on Mac. And context-switching between the two is a drag.<\/p>\n<\/blockquote>\n\n

Patrick McConnell<\/a>:<\/p>\n

\n

SwiftUI is littered with things that do 85% of what you need and then get ignored for years. It’s the iPadOS of frameworks.<\/p>\n

Yes, we can use Cocoa frameworks (and I do) but why can’t SwiftUI approach the level of the Cocoa frameworks?<\/p>\n

I think in many cases Cocoa is more effective simply because Apple hasn’t spent the effort to bring SwiftUI to the same level.<\/p>\n<\/blockquote>\n\n

Helge Heß<\/a>:<\/p>\n

\n

I think it’s because SwiftUI is not intended<\/em> to be a Cocoa level framework. Similar in how Objective-C is not supposed to replace C. That would be Smalltalk, which shows how impractical (however nice) that would be.<\/p>\n

My personal suggestion is to consider SwiftUI a form builder on steroids. It’s extraordinarily effective for things builtin.<\/p>\n<\/blockquote>\n\n

Helge Heß<\/a>:<\/p>\n

\n

I can’t tell what their long-term plan is, but IMO it’s extremely unlikely to be a fully SwiftUI based system. Except for tiny platforms like watchOS (the original target AFAIK). I suspect that SwiftUI for UIKit+ was never intended to be a competitor to Cocoa, but to ReactNative and the likes.<\/p>\n<\/blockquote>\n\n

Colin Cornaby<\/a>:<\/p>\n

\n

I had the unpleasant experience of trying to do something complicated with a scroll view in SwiftUI. You can’t get or manipulate the scroll offset directly? What?<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n