Phillip Caudell @phill@mastodon.notsobig.co

The only brushed metal I’m interested in

@jasonhowlin indeed an opaque type should preserve type information, but it appears Xcode Previews for whatever reason discards it. 🤷‍♂️

@mattiem It looks like it might be a quirk of Xcode Previews, actually https://mastodon.notsobig.co/@phill/111051676536041177

@helge @groue You're right that this is a Swift Package. Specifically, running from an Xcode Preview. Linking and running from simulator yields the 3 identical results. How curious!

@helge @groue view extensions for modifiers are super common yes, but I have not seen their type erasure talked about before https://mastodon.notsobig.co/@phill/111051329580089118

Edit: Macro is a neat idea, though.

@mattiem yes quite surprising! Presumably AnyView is introduced by the runtime?

I thought it made sense, but now I’m not sure it does. 😅

@cvieiragoebel@berlin.social thank you Christopher!

I'm a little embarrassed to admit, but I had been blissfully unaware that View extensions are type erasing.

That means if you have an extension for using your ViewModifier in a more ergonomic way, it'll be erased to AnyView unless you explicitly mark it as @inlinable.

https://gist.github.com/phillipcaudell/df04ebf01e9579a308e3534ac829a540

Edit: Perhaps this is just a quirk of Xcode Previews: https://mastodon.notsobig.co/@phill/111051676536041177

@shauny that's definitely an option! It's just iPad is frustratingly close to finished; these last little things are letting it down.

@simonnickel Yeh it's 100% caused by switching on the size class. The irony is I'm only doing so because of a separate issue with NavigationSplitView (https://mastodon.notsobig.co/@phill/110939609793823190).

Your problem looks similar though. I've had some mild success now by tying the lifetime of the State directly to the NavigationStack. Both get destroyed together (keeping the Stack happy). The State can then be restored through some other mechanism (like a Binding) https://gist.github.com/phillipcaudell/6201a448310bcc7830eea8be3b7bd24e

If you're wondering why Big Mail is taking so long

NavigationStack loses its navigation bar on iPad when returning from the background, making it impossible to go back or do anything. iOS 16 and 17.

FB13120953

https://gist.github.com/phillipcaudell/f6258c1fbac69a9fb2cd030fadd087de

@matt1corey the scenePhase reports .background, but yes! A little confusing at first, but I suppose it makes some sense.

Something that tripped me up recently was not understanding how .onAppear { } behaves on iPad.

It gets called multiple times, even though the view is not visible.

Why? Logging reveals the size class is also changing, so presumably iOS is taking snapshots for the app switcher.

If like me you rely onAppear to denote a user has seen something (say, Mark as Read), you'll need to check the scenePhase first.

Here's a gist: https://gist.github.com/phillipcaudell/290eab2c42c4cc27cfdc0c595b40654d

@bdewey @mattiem NavigationSplitView has a number of issues related to the column’s view identity changing. Group has no affect on layout whereas ZStack does, so I imagine that makes a difference when SwiftUI computes the body 🤷‍♂️ https://mastodon.notsobig.co/@phill/110911505249133591

@konstantin write once, break it everywhere

i am inevitable.

@mattiem right, because if the State is inside the Button it’ll be destroyed when the menu/swipe disappears, taking the dialogue with it.

Here’s one weird #SwiftUI trick Apple DON'T want you to know:

If you present a confirmation dialogue from a swipeAction or contextMenu nothing will happen as the view is removed before the dialogue is presented. Annoying, but it makes sense.

Instead, delegate the confirmation to the environment. Now the Button isn't responsible for the presentation and you're left with a nice clean call site.

Here's my implementation with an example: https://gist.github.com/phillipcaudell/ecb32dc5a3915931d225a6cb8a67ac34