{"id":39511,"date":"2023-05-26T14:41:04","date_gmt":"2023-05-26T18:41:04","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=39511"},"modified":"2025-12-16T15:49:06","modified_gmt":"2025-12-16T20:49:06","slug":"wallaroo-and-swiftui-on-macos","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2023\/05\/26\/wallaroo-and-swiftui-on-macos\/","title":{"rendered":"Wallaroo and SwiftUI on macOS"},"content":{"rendered":"

Craig Hockenberry<\/a>:<\/p>\n

We have a View<\/code> in the app that uses SceneKit to display a 3D scene with a confetti flourish after a customer starts a subscription. I was expecting stuff like that to take a lot of effort to get working on the Mac. Instead, it ran 100% out of the box with no modifications at all.<\/p>

And the stuff that I was expecting to be easy, like a settings view, buttons, and menu commands, turned out to be hard. To put that “hard” in context, it took me about a month to go from an app that we were proud of on iOS to one that we were equally proud of on macOS[…]<\/p>

[…]<\/p>

We also found that many of the issues encountered on macOS were things we had done wrong on iOS. Porting the app to the Mac made both<\/em> platforms better. We’re also rethinking our View architecture so things that are currently Mac-only can be used to improve the iPad experience.<\/p>

[…]<\/p>

You’re going to have platform-specific code. More than you realize: certainly more than I expected!<\/p>\n

[…]<\/p>\n

It took me three days to hook up a Save menu item and have it work reliably.<\/p><\/blockquote>\n\n

I don’t understand why they had to use a custom button style and a hard-coded radius to get buttons that looked good on both platforms. I thought the point of SwiftUI was that you’re supposed ot just specify that you want a button and it does the right thing on each platform.<\/p>\n\n

Craig Hockenberry<\/a>:<\/p>\n

\n

SwiftUI’s default mechanism for handling URLs on macOS isn’t great. If you’ve used .onOpenURL<\/code> on a View<\/code> to handle external events, you’ll be disappointed to learn that a URL scheme on macOS opens a new window (Scene<\/code>) before it hands the URL to the view modifier. And if you’re using a single Window<\/code> instead of a WindowGroup<\/code>, nothing happens at all.<\/p>\n

[…]<\/p>\n

One thing we wanted to do was use the Escape key to pop the NavigationStack<\/code>. On the Mac, it’s a key that has always represented “go back” and many apps (like Photos) take advantage of that. Unfortunately, to accomplish that in Wallaroo, we had to use an invisible<\/em> ToolbarItem<\/code> with a .keyboardShortcut(.escape, modifiers: [])<\/code>.<\/p>\n

[…]<\/p>\n

While you’re struggling with window and sidebar size constraints, you end up with UserDefaults<\/code> for frames that have “fun” keys like \"NSWindow Frame SwiftUI.(unknown context at $1acd3d768).SceneBridgeReader, SwiftUI.ModifiedContent>, SwiftUI._PreferenceWritingModifierSwiftUI.PreferredColorSchemeKey>, SwiftUI._EnvironmentKeyWritingModifier>>>>-1-AppWindow-1\"<\/code>.<\/p>\n<\/blockquote>\n\n

Craig Hockenberry<\/a> (Mastodon<\/a>):<\/p>\n

You won’t realize how much you depend on SwiftUI previews until you start working on macOS.<\/p>

Sometimes they kinda work, but more often than not you’ll get an endless spinner. When they do work, they’re not interactive (you have to use the selectable mode with the arrow icon).<\/p>

[…]<\/p>

The similarity of the key names makes this a hard lesson to learn. I looked at “aps-environment” and “com.apple.developer.aps-environment” for hours before I realized they were different. After you add the one for macOS<\/a> manually, everything is golden.<\/p>

[…]<\/p>

We weren’t able to get FileRepresentation<\/code> working in a Transferable<\/code>. Other applications can’t access a temporary file that’s created for the export. This feels like a sandbox problem that we couldn’t work around.<\/p><\/blockquote>\n\n

Previously:<\/p>\n