Phillip Caudell @phill@mastodon.notsobig.co

@BenRiceM so slick! Congrats on shipping 🔥

@dominic very much focussed on shipping current feature set first, then we’ll go from there!

@dominic as soon as it’s viable on-device it’ll be interesting.

@xmollv also paginating the List 🙃

I guess it will be this way until they rebuild their flagship apps with it. No way they would let Mail.app stutter at a few hundred rows.

@brandonhorst that is definitely a big part of it, yes. Get something working on one platform, see it behave weird/broken on another.

@xmollv when the iPad build running on Mac has better List performance than the build made for Mac

@brandonhorst maybe, though hindsight is always 20/20. I really like SwiftUI, which is why it's so frustrating to see it let down by such an inconsistent implementation. We're year 4 now and the lack of maturity in some areas is really bothersome.

@abdulhadikh Sorry for the hold up in updates; there will be a new update next week.

Some interesting differences about List on Mac:

1️⃣ Swipe Actions are eagerly loaded. On iOS these are lazily loaded.

2️⃣ List immediately buffers ~300 cell bodies. On iOS it's about 10.

3️⃣ Cells don't respond to isFocussed, whereas on iOS they do.

4️⃣ “Select All” will immediately buffer all cells and lock up your app.

List on Mac

@Mecid they couldn’t have wrote a more obnoxious and crass message if they tried.

I hope you get it resolved quickly!

the REAL cost of the gay agenda

i’m pleased to report you can make the iPhone simulator gay now

@bardi à la Notes.app? It’s not something I’ve looked at, but I bet you could do it with NSTextAttachment or WKWebView.

Man, NavigationSplitView is *still* broken in iOS 17 beta 7.

I reported back in May (FB12178616) that when in compact mode transitions become sporadic and stop working. This code is verbatim from Apple’s docs and it doesn't work.

This broke back in iOS 16.2. It seems nuts to me something so significant can stay broken for this long (and on a relatively new API?!)

https://gist.github.com/phillipcaudell/4cc223bec9a18970aed489d06580a56d

@alpennec in this instance I would say it's actually better to not denote it with the destructive role. At least then it'll defer the delete animation until confirmation.

Edit: video loop makes it look jumpy, but it’s completely glitch free 😛

@alpennec AFAIK there is no equivalent of UIContextualAction's handler in SwiftUI. Messages is likely using that to defer the editing commit until the user has confirmed. Since there is no callback on swipeAction I'm not sure how it would be possible.

This doesn't seem that intuitive at first, but if you think about it, how would SwiftUI anticipate what action will be performed on your model?

In iOS 17 the animation has been improved considerably if you don't explicitly set the role, but for best results you still need to set it.

I recently got downvoted into oblivion for explaining why someone's List animation was glitching, perhaps because the solution is so simple it seems stupid.

On the left is swipeAction with a Button. On the right is the exact same Button, but now the animation is smooth.

The difference? I set the Button's role to destructive. SwiftUI uses the role to infer what animation to use. https://gist.github.com/phillipcaudell/e4ee5057dc33f92ed80b817762726275