User Profile

I have a big project file, objc/xib based. The file's owner class header is not being parsed correctly, the context menu for the "File's owner" shows warning signs for all existing outlets and actions. What's confusing is this only happens when running Xcode 12 on Big Sur. On Catalina everything works fine. Makes it very tiring to test things cross OS (reboot to tweak the xib, reboot to test). I'd gladly submit a FB about this, but first thing they'll ask is how to reproduce it. Smaller XIBs don't exhibit this. Is there any log or sanitization tool I could try to narrow it down?

We've had this head scratcher for a long time now. The app is sparkleapp.com, a website builder, it has a bulit-in FTP client that stores the password in the keychain. We use SSKeychain to store and retrieve the password.A random selection of users will lose their password after the app update. In this case the non-appstore version of our app Sparkle (not sandboxed) updates is via the Sparkle updater framework (humor me).Previous topics suggests the DR determine whether the Keychain will allow the updated app to access the keychain information. I ran a the update here and the result of the two versions appears to be an identical DR:Duncans-MacBook-Pro:tmp duncan$ codesign -d -r - /Users/duncan/auto/builds/Sparkle\ 2.8.7.app/ Executable=/Users/duncan/auto/builds/Sparkle 2.8.7.app/Contents/MacOS/SparkleNonMAS designated => anchor apple generic and identifier "eu.riverdesign.sparkle" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "8W892L9Q36") Duncans-MacBook-Pro:tmp duncan$ codesign -d -r - /Users/duncan/auto/builds/Sparkle\ 2.8.7\ updated\ to\ 2.8.8.app/ Executable=/Users/duncan/auto/builds/Sparkle 2.8.7 updated to 2.8.8.app/Contents/MacOS/SparkleNonMAS designated => anchor apple generic and identifier "eu.riverdesign.sparkle" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "8W892L9Q36")Does the lack of access on some of our user Macs mean their update failed to produce identical DR?Unfortunately this seems to happen to unsophisticated users, it's really hard to ask them to try things for me. Questions I have asked suggest they don't get a keychain unlock prompt.Sorry I'm really stuck and have no idea how to troubleshoot this.