It looks like this has been fixed 🥳 at least, I received a notification for the new post in this thread

Thank you for that link. That certainly seems like the same issue. That's a real shame, and it probably means there's nothing individual developers can do about this problem to workaround it. I hope that Apple deploys a fix soon, and back to Catalina, not just Big Sur.

I'm also seeing this problem. I recently revisited a thread that I was watching and I see new posts have been made, even though I never received an email notification. There must be something wrong here. If I look at my Apple dev forums profile under "Watching" it says: "You aren’t watching any threads right now". That's definitely not right. The thread itself still has the bell icon turned on, to indicate that I'm watching it.

I also encountered this issue with a helper app on macOS 11.5. My main app is sandboxed, codesigned, and notarized. I verified that's all in order using the codesign and spctl tools. I also used the xattr tool to verify that none of my apps or their files have the quarantine flag set. The helper app is inside the main app's bundle. When the main app tries to launch the helper app via NSWorkspace I see these errors in the console log: LAUNCH:Application launch of disabled, bundled executable is not permitted, so returning kLSNoLaunchPermissionError, <private>, status=-10826 LAUNCH: Launch failed in CSUI with error Error Domain=NSOSStatusErrorDomain Code=-10826 "kLSNoLaunchPermissionErr: User doesn't have permission to launch the app (managed networks)" UserInfo={_LSLine=3762, _LSFunction=_LSOpenStuffCallLocal} handle LS launch error: {\n    AppPath = "/Users/me/whatever/MainApp.app/Contents/MacOS/helper.app";\n    ErrorCode = "-10826";\n} It doesn't seem to matter whether my app is stored in the /Applications folder or elsewhere. Launching the helper app always fails. I can clear the problem by manually launching the helper app in the Finder. Once I've done that the main app can also launch the helper app programmatically. Unfortunately this isn't a very friendly solution for customers. If there's any way to workaround this issue, or anyone learns any more information about this situation, I would be very happy to know.

I'm reproducing the bug on an attached Dell 4K monitor. The seams show whether the display is set to the default resolution or scaled. But regardless I've had dozens of customers report this issue, and we can't very well tell them all to buy new Retina monitors! A DTS ticket may be a good idea, but my sense right now is that this isn't anything that can be worked around.

@Etresoft Thank you for the reply! SwiftUI is a non-starter. This is a mature Mac-only app built using AppKit. The view in question isn't a trivial widget, but rather a complicated and dynamic view hierarchy that isn't suitable to be implemented in SwiftUI– at least for now. We'll see what happens as SwiftUI develops. Thanks for suggesting the use of a magnification factor. I actually forgot about -[NSScrollView magnification] because this is older code that predates that property. Unfortunately the results are the same. Even in a simple test project that uses NSScrollView's magnification factor the errant seam lines occur. The bug manifests even for zoom factors that seem relatively benign, eg: 1.5x zoom. Oh well, I guess this is just an unavoidable drawing bug of macOS. I'll see about sending in a feedback report to Apple.