I was trying to help you out. I see you don't want that.

Reminder to put all your code inside the code block.

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 :)

Then you may need to generate some sort of unique userId. When the app is launched for the first time and the user doesn't login, generate the id and send that with your request to the server, and reject requests after a number have been made. If the user instead logs in, retrieve the id from your own server and store it in the app. Again, it won't stop deletion and re-installation of the app as a new id will be generated each time.

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