Thanks for the information. Embedding a fixed decryption key is what I do. My app supports user send data to another phone using airdrop, and I encrypts the file when transferring it. However I don't encrypt data files on phones yet. BTW, in my app the data are owned by user, so it's fine if they take a screenshot or do whatever. My purpose is to prevent other people to look at the data.

Ping @Claude31. Thanks for any suggestion.

I just read macOS 13.2 release notes. It said that it used macOS 13.1 SDK. That probably explained why there isn't a newer Xcode release for macOS 13.2. So I still need to figure out why my app crashed in simulator in macOS 13.2.1. I wonder if anyone else observed the same issue?

On a second thought, I don't really know if it's a convention that there is a Xcode release for each OS release. So I think my question is, will there be a Xcode release for macOS 13.2? I really think the current Xcode version doesn't work.

Hi, may I ask if this is an issue with Xcode or macOS? My code worked well on macOS 13.0 + Xcode 14.0, but crashed on macOS 13.2.1 + Xcode 14.x (I tried all Xcode 14.x releases). So I suspect this might be an issue caused by macOS change? See more details at https://developer.apple.com/forums/thread/725062#725062021. Thanks.

Forgot to mention, my laptop has Intel CPU.

Thanks for the information and pointers. I didn't know them.

@stm-Dude, I assumed the wrappedValue of the binding is of optional type. That's not the case in your code. You just need to change the "Value?" in the function's param type and return type to "Value".

I'm using a much simpler workaround now. See the comments under my original post. I'll post the code below.

Typo in the above comment. The async() call should be made in the custom binding's setter.

I realized a much better approach to work around the issue (or feature). The new approach is to use DispatchQueue.main.async() to decouple the simultaneous change. The elegant part is that we can write a generic function to take the original binding and return a new custom binding, and encapsulate the async() call in the new binding's getter. Unfortunately I can't post the code in comment, but it's very simple to implement it.

UPDATE on Xcode 14 RC: the issue is still observed and the above solution works fine also. So it's very likely not a bug but a feature. It's odd that the SwiftUI team keep silent on this.

One more thing. When I wrote the above I assumed the error occurred for all Views that wrote to its binding param. My further experiments show that's not true. For example, TextField doesn't have this issue. So it seems only some Views (e.g. Picker, Sheet) have this issue. We need an official answer from the SwiftUI team on what exactly the error message means. Before that I'll continue to use my solution above.

As the Xcode and iOS release notes mentioned very few SwiftUI related change, I didn't try them because I don't think it's worth the trouble. I ended up with a SwiftUI + UIKit hybrid approach (unfortunately the forum doesn't allow me to post the link). I can't believe, for a serious regression like this, the SwiftUI team in Apple just keep silent and pretend nothing happened. They could respond with a simple UIKit based workaround to save a LOT of people's time. What a shame!

Got it. Thanks.