Phillip Caudell @phill@mastodon.notsobig.co

@Mecid such a great pattern. Works great for sheets and windows too: https://mastodon.notsobig.co/@phill/111102106124235691

@alpennec The implementation is a bit more involved, but yes you can expand it to sheets and other things.

Basic gist: have a global router that populates the environment with a navigate action. Define an enum of your views along with some sort of view factory protocol (Routable). Then have a modifier somewhere responsible for presenting.

Bonus benefit is the view state is now 100% serialisable and restorable.

@alpennec Yeah unfortunately NavigationSplitView is pretty unusable when it’s compact: https://mastodon.notsobig.co/@phill/110939609793823190

Your best bet is to create a wrapper around it and switch to a NavigationStack when needed.

Ooo DocC now includes extensions in Xcode 15!

👏 👏 👏

Why is deinit not called here?

If a StateObject's lifetime is that of the containing view, popping from the stack should deallocate it. But it doesn't.

Weirdly removing the List's selection binding results in a dealloc as expected.

Is this a memory leak with List or am I missing something? (iOS 17/latest Xcode)

https://gist.github.com/phillipcaudell/8509aba4f3fc064b3d7bfbb1fefbe9a9

@xmollv ahh yes toolbar items are particularly sensitive in NavigationSplitView. It seems to bubble up preference keys much later than NavigationStack does, so presumably it gets out of sync somehow ¯\_(ツ)_/¯

back in my day you could swizzle the whole runtime using a fork whilst hot swapping a UIViewController from space and no one ever got hurt

“Your engineers were so preoccupied with type-safety that they didn't stop to think if they should”

– Ian Malcolm, 1993

@mattiem thanks for sharing! I did stumble across this, but wondered if Swift 5.7 could make all the casting/switching redundant.

I need an ”AnyCodable" type for serialising some generic stuff.

Is something like this the best approach now that we have existentials on protocols?

AnyThoughts appreciated!

https://gist.github.com/phillipcaudell/99d1fe52873d0c5115bc281272003784

@xmollv one man's SwiftUI is another man's UIViewRepresentableOhMyGodWhyIsThisHappening

@xmollv 100% this! See: https://mastodon.notsobig.co/@phill/111059874348717556

NavigationController was relatively straightforward. I got stuck with UISplitViewController + List refusing to render the Sidebar style without a UITableView. If you can crack that…

@xmollv don't even get me started.

@dominic the second it’s ready it’ll be on TestFlight 🙂 https://discuss.bigmail.app/t/development-update/164/2

@sandropennisi AFAIK DocumentGroup is a wrapper around UIDocument + view management, so I’d say it’s still worth exploring your own. 99.99% of my SwiftUI issues are at the UIKit/AppKit border. Apple’s implementations for whatever reason are just extremely problematic.

@kyleve QA? Don’t know her! https://youtu.be/cQEmpk-aS-Q?si=dkksWyJu-g2JZMII

@sandropennisi @bdewey do yourself a favour: stop using these APIs. Seriously.

Write a light wrapper around UINavigationController. It won’t take you long, and I guarantee you’ll have far fewer issues. And if you do, you can actually fix them.

Happy to exchange notes if you’re interested :-)

@stroughtonsmith

@sandropennisi I also saw @bdewey having issues with DocumentGroup + NavigationStack. https://iosdev.space/@bdewey/111041862162653396

For what it’s worth, the navigation APIs have been absolutely shocking. Not sure what’s going on over there.

This is definitely the best looking rectangle they’ve made yet