This would be easier to help you with if you added a minimum reproducible bit of code.

Shouldn't this DispatchQueue.main.asyncAfter(deadline: .now() + 0.3) {self.dealsTable.scrollToRow(at: >>>>savedRowMainFave<<<<, at: .bottom, animated: false) scroll to savedRowMainFave.row?

Then you've designed it incorrectly. Use adjustable font sizes and resizable images.

Hey, no drama. At least you have a valid use case. Most people just grumble that something isn't exactly how they want it.

You didn't mention "more complex circumstances", so I offered an opinion on the example you gave. I created a project with your code, made my adjustments, and didn't see the error. Why would closing a popover automatically set the sheet's State var to false? It's a separate control, and that's what was causing your error. Closing a popover will set the popover State var to false, but not a separate control which just happens to be open and true at the time the popover was opened.

It won't happen because it would have to be hardware-based. You can't just put something on a screen and expect it to know how much that thing weighs without there being some hardware that can detect the weight of the item. Apple won't add that hardware for such use cases. It would be too expensive, and not many people would use it (well, drug dealers might).

Any chance information like this could be added to the Developer Documentation?

"private should not be used in file level" Yes, it should. It's private in that scope in that file. You need to try fileprivate and private in two different source files.

Ah, yeah. In my code I just added a simple Text("CarView") etc. I guess this proves it's important to show all your code ;)

Do you understand how pointless your suggestion is? You haven't offered the name of a session to watch. I already have widgets working; my issue was specifically mentioned in my question. Regardless, I have recently fixed this with help from an ex Apple employee on Mastodon, and no WWDC session would've helped.

If you wouldn't mind, mark my answer as the accepted answer and it'll let others know that your question has a solution :)

No, it's putting the fix in the middle of foo, i.e. foStinrg(describing: o.value). Looks like an Xcode bug to me.

Please take note of what I said about using constants and the Notification.Name extension. You should create a name for each notification and use the syntax I provided. This will reduce typos.

17.5 isn't out yet, so I'd say this is the right place as it's the beta they're talking about.