Apple Documentation and SwiftUI for Mac
I wrote a post yesterday about triple-column navigation in SwiftUI. It felt a bit awkward posting it because this really shouldn’t be some obscure knowledge. This is hardly a challenging problem. But to me and to many other people, this was challenging.
Why was it challenging? The
NavigationViewdocumentation page doesn’t mention a triple-column layout or macOS at all. But the lack of content is not the only problem with Apple Documentation.The intention of the article isn’t to complain, but rather to review the documentation system and point out some of its issues.
This is a native macOS app written entirely in SwiftUI, from
@mainto bottom. Not a prototype, not a toy. A full-featured app. The intention is to deliver the best macOS experience possible.[…]
The relationship between SwiftUI and AppKit are not documented and not guaranteed to be supported. This workaround is useful for now, but might stop working in the future.
[…]
I had to compromise in a few places. But I don’t have a lot of bugs to report. Maybe I’m just getting better at avoiding things that don’t quite work as expected. There are some limitations, but the AppKit integration is always there for me.
SwiftUI is an amazing way to prototype interfaces quickly but when you hit a wall you hit it hard and there’s almost nothing you can do.
It’s also telling to me that, for instance, nobody seems to have figured out how to make two Buttons in SwiftUI be the same width.
(Yes, I’ve seen various posts about it, but so far haven’t found a solution that works in all cases.)
Previously:
- SwiftUI Layout Explained
- What Is Not So Great About SwiftUI
- The State of SwiftUI
- Emulating Equal-Size Constraints in SwiftUI
Update (2021-03-14): Alexander Grebenyuk:
I solved all these performance issues with one simple trick – rewriting the list using
NSTableView.[…]
Unlike iOS, macOS needs to know the size of every cell. It allows precise control using a scroll indicator. It appears that
Listattempts to implement self-sizing on top ofNSTableView, but it’s destined to fail on macOS.[…]
There is always a risk with SwiftUI. It is an exceptional tool, but you never know when you are going to hit a wall. My pure SwiftUI app uses
NSTextView,NSSearchField, and nowNSTableViewandNSMenu.
Update (2021-03-19): Steve Streza:
SwiftUI is two things. It is 1) a declarative, reactive UI paradigm similar to React or Jetpack Compose, and 2) a new set of controls and views that mimic AppKit/UIKit.
1 is brilliant. 2 is absurdly frustrating at every turn, and feels like hacking non-native UI.
Update (2021-04-07): Alexander Grebenyuk:
Some basic things that are unproblematically done with Auto Layout are hard in SwiftUI, for example, matching views size or aligning views. SwiftUI layout system is simply less expressive. The good things about it (stacks, grids, spacers) are easy to add to Auto Layout. And I still can’t build a complete mental model around the SwiftUI layout system. Auto Layout, on the other hand, makes total sense – it’s just math.
#SwiftUI is a disaster. I know of a team about to ship a production app built 100% with SwiftUI and it’s a UI shit show. Basic things that have worked fine since iPhone 2.0 just don’t work correctly with SwiftUI.
Update (2021-04-14): Ken Case:
Some things we wanted to do were easier than ever. Some things were much harder than one would hope. (E.g., SwiftUI will happily reclaim views which are scrolled offscreen, which can play havoc when one of those views is the first responder.) Creative experimentation required.
Update (2021-04-15): Marcin Krzyzanowski:
For the past 2 days, I’ve been dealing with a SwiftUI issue where
NSViewRepresentabledoes something different than SwiftUI views and the hierarchy does not update properly. The same hierarchy and if I just replace component withSwiftUI.Button- everything starts working.Now I need to reimplement native
NSSegmentedControlpurely in SwiftUI views to make it work, and still, it won’t look as good as the native component (SegmentedPickerStyleis not enough for my needs)SwiftUI is faster until it’s not.
Update (2021-06-07): Peter Steinberger:
Sometimes SwiftUI is just so random. Compare the two images. The context menu does work in one and doesn’t work on the other. Can you tell which one is the right one?
5 Comments RSS · Twitter
Triple-column navigation in SwiftUI is easy to implement. However, if you want to change the look-and-feel at launch—e.g., to show the sidebar by default on iPad—you have to dip into UIKit in .onAppear{}, find the UISplitViewController, and configure it.
So yeah, you hit a wall!
Can you even organize contacts on iOS? As far as I know, you can only create contact groups on a Mac, or the very least icloud.com. The groups on my contacts app are the same ones from the last time I set up a new mac back in 2009.
Thanks for this column. I've spent a lot of time with SwiftUI, wondering whether I was just a crappy coder because I'd get to a certain point and then then next step was just seemingly unknowable. I was consoling myself that maybe it was just the poor documentation; maybe it's a bit more than that.
Still, the future looks bright, even if the present is full of Roadrunner-Coyote walls.
Navigating the nuances of SwiftUI reminds me of my early days in programming, when documentation was a treasure hunt and every solution felt like striking gold. Alexander Grebenyuk's experiences resonate deeply with me, and it's a testament to the challenges and rewards of adapting to evolving tools. As Wil Shipley points out, while SwiftUI is groundbreaking, it's evident that we're still in the growing pains phase.
Reading Alexander Grebenyuk's insights on SwiftUI for Mac felt like a flashback to my early days wrestling with UIKit. The exhilaration of breakthroughs mixed with the sting of undocumented features. Kudos to all the developers who share their experiences; it helps bridge the gaps left by official documentation.
