Hi @DTS Engineer (Kevin). Thanks for your detailed reply. I will add a bit more context to explain how our app uses locking and why. I realized from your answer that it may be different that the common use case. The app locks the file with an exclusive lock when the user opens the file to begin editing it. The file will stay locked as long as it is open. The main goal is to signal other instances of our app on other machines that the file is already open if another user tries to open and edit the same file. We do not want users to start working on a file that someone else may have started working on already and that may have unsaved changes. We are not really interested in preventing other apps from modifying the file because that will rarely happen in our usage scenarios. We do need to support Windows clients connected to networks shares since our app is cross-platform. Our team has in fact proved in the past that open(url.path, O_RDWR | O_NONBLOCK | O_EXLOCK) does work over SMB shares and we're reluctant to switch to a totally different locking system. We also have to keep supporting older app versions that use open. Given this additional information, do you think there's anything we can do to address the issue? Also, why does having a plain-text preview vs an image one affect the Quicklook locking behavior (and it's impact on us)? Alberto

How did you fix the codesign exception?