Anyways I'm back to use NavigationLinks(value:) again, which this time seems to be behaving.
I think the reason it wasn't working last time is because I had installed a navigationDestination on my Sidebar (which is shared between compact and regular size class). It looks like it was confusing NavigationSplitView.
Now I have the navigationDestination installed just in the compact size class, and things seem okay…
Okay, another update on my Navigation Saga, because sharing is caring.
After integrating, I noticed selected rows wouldn't unselect when popping back.
Turns out using .tags() will only work if:
1) The root List is bound directly to an ObservedObject. A Binding to the same value in an ObservableObject won't work.
2) The List must only contain Text or Label views (so no pinned Grid at the top).
I'm also not sure why the Binding gets fired so many times VS the ObservedObject either? #SwiftUI
If there's any poor souls stumbling across this in the future, here's a gist to my solution: https://gist.github.com/phillipcaudell/085580a9412284f381a4730930c7d52f
Now to refactor this back into Big Mail 🥲 #SwiftUI
…so instead, I'm switching to a Stack when compact. Only issue is getting NavigationLink, SplitView and Stack to play together.
In the end I found it was easier to remove NavigationLinks all together, and instead use tags. Lists then use this as their selection value.
Then, using those selections, I'm computing a path to drive the Stack. Once I caught EditMode, it all worked.
No jittery toolbars. Smooth transitions. Consistent and predictable across iPhone/iPad/Mac.
Thank god.
Hallelujah! 🙌
Finally got a workaround for the NavigationSplitView regression in iOS 16.4.
Transitions stop working when the content column no longer contains a List (say you have a “Select Mailbox" view, a Grid, etc).
Here's a gist of the issue: https://gist.github.com/phillipcaudell/6d4d0efac6a22cd42bf75f3acd7a033b
It seems to suddenly start behaving like a NavigationStack, which is why adding a navigationDestination sorta works (except now you've got wonky nav animations, and it still sometimes fails)…
Well hot damn, someone on Twitter suggested setting the Set's underlying type to Optional, and voila, editing and navigation!
I'm still not entirely sure why this works though. Surely an empty Set would denote no selection? Making the type itself Optional isn't intuitive at all.
Even the init signature doesn't give any hints, only that the Binding itself can be Optional... 🤷♂️ #SwiftUI
Okay one for the #SwiftUI crowd: Do we have a definitive answer whether a List's selection binding should be Identifiable or not?
Apple seem to play fast and loose with this. Some of their example projects (Food Truck) don't conform to Identifiable, and the Swift header for List only has Hashable as the requirement. Meanwhile the docs say a List's selection should conform to Identifiable.
So what is the truth? What do you do in your apps?
I refuse to sleep until I have found a solution to this, which is unfortunate, as it means I may never sleep again 🥲
I've now officially arrived in crazy town, and started wrapping UINavigationController myself.
What's interesting is that the SwiftUI environment is still automatically adding nav items to the controller, so I've actually got the same broken animations as with NavigationStack. At least it’s…consistent.
Running out of ideas now 😅
Ok I have to be missing something here. If you add a selection binding to a List (let's say you want to edit it), then that seemingly renders all NavigationLinks in the List unusable. Surely not!?
Please someone, anyone, tell me I'm holding it wrong! #SwiftUI https://gist.github.com/phillipcaudell/3b890345efbc36c050d3ec630051c200
Bugs happen, I get it, I write buggy software too. But my god, I have never in my 14 years of writing apps for iOS have the ground move beneath me as much as it has with #SwiftUI. A couple of issues every now and then I can forgive, but it's not. It's every update, something has broken or changed.
It may be a beautifully expressive framework, but it doesn't matter if it doesn't work reliably, all the time, every time.
Something is deeply and systemically wrong with it.
Here's the exact same code running on iOS 16.2. It works just fine.
And I’m sorry if I sound like a twat, but the SwiftUI team HAVE to get a grip on this. I cannot tell you how many hours I waste wondering "Wait, is that something I broke?!”
I'm being gaslit by a UI framework!
Arghhh. Another #SwiftUI regression in 16.4: NavigationSplitView won’t animate the first push of the detail column if the content column goes from List, to no List. Again, this worked just fine in prior releases! https://gist.github.com/phillipcaudell/a125708c3075abcabe9940427c57d1a3 (FB12175649)
On iPad, hitting search will hide the suggestions.
On iPhone, hitting search does nothing, they just get stuck there. https://mastodon.notsobig.co/@phill/110163933612089969
And this is code pretty much lifted from Apple's own docs. Maddening. https://gist.github.com/phillipcaudell/d7282b58f90c8be7e83c27ce78b6d44a
On iPad, the suggestions briefly show, then vanish. Why? I have no idea! It never used to do that, now it does.
(It also doesn't show the icon, for...reasons?)
On iPhone, the suggestions will appear on presentation (great!), but if you tap a suggestion, then type just a little too fast, the caret position gets messed up.
Do this enough, it'll eventually crash, throwing an exception from some private _UIObscurableTextContentStorage class.
🏳️🌈 Founder / Maker
Building that new email app.
Swift and rollercoasters are my thing.
Recovering VC.