Hello, problem is solved. Need no further help. Best regards gefa

Hello DTS Engineer, I experienced Code Signing Issue a second time. It looks like everything was correct: -> In the Signing & Capabilities section, "Automatically manage signing was enabled -> team was set correctly -> Signing Certificate, was "Development" was chosen • I cancelled these settings and reset them again • I cleaned the build folder • I build again The error vanished. As wanted, additional background information • Xcode 15.4 • macOS Sonoma 14.4.1 • type of app macOS Thanks for your help Best regards, Gerhard

Hello, Command CodeSign failed with a nonzero exit code All the above mentioned points (1-4) were set correctly. Nonetheless, the problem didn't vanish. Next I removed all breakpoints (about 100). Next: Clean Build Folder… Next: Build The problem was gone. Best regards, Gerhard

Hello Quinn, Your question: "What are the array elements? My app comprises about 500 methods, many of them contain pairs of deprecated…" -> Elements are NSStrings, NSArrays, NSMutableArrays, NSNumbers, NSSets, NSMutableSets I don't understand what you mean by "I think you should take this opportunity to factor out the common code so that you only have one copy of your archiving code." What do you mean by "common code"? Do you mean "deprecated code"? "… only have one copy of your archiving code"? As already said in my previous reply: Your proposal works. I need to do a big job to change them all bit by bit. What is irritating is this Console feedback: *** -[NSKeyedUnarchiver validateAllowedClass:forKey:] allowed unarchiving safe plist type ''NSString' (0x1f30548c8) [/System/Library/Frameworks/Foundation.framework]' for key 'NS.objects', even though it was not explicitly included in the client allowed classes set: '{( "'NSMutableArray' (0x1f304d690) [/System/Library/Frameworks/CoreFoundation.framework]" )}'. This will be disallowed in the future. BOOL _NSPersistentUIDeleteItemAtFileURL(NSURL *const __strong) Failed to stat item: file:///Users/gefa/Library/Containers/ch.psys.Observing-Las/Data/Library/Saved%20Application%20State/ch.psys.Observing-Las.savedState/restorecount.plist Does this any harm to my code? Can I ignore it? Best regards, Gerhard

Hello Quinn, I tried to implement your proposal. Need I to implement secure coding support as in the example? According to the example implementing 'secure coding support' requires about a dozen lines of code. What I have done: Deprecated code tmp = [NSKeyedArchiver archivedDataWithRootObject:savedSettingsArray]; settingsArray = [NSKeyedUnarchiver unarchiveObjectWithData:tmp]; (tmp is NSData, savedSettingsArray + settingsArray are NSMutableArray) I tried this: tmp = [NSKeyedArchiver archivedDataWithRootObject:savedSettingsArray requiringSecureCoding:true error: nil]; settingsArray = [NSKeyedUnarchiver unarchivedObjectOfClass: [NSMutableArray class] fromData:tmp error:nil]; Result: it works. Question: My app comprises about 500 methods, many of them contain pairs of deprecated NSKeyedArchiver+NSKeyedUnarchiver. I can't change these all at once. The chance of coding errors is great. So, I try to make changes bit by bit. How long does the deprecated code works? Although the corrected lines of code work the Console shows the feedback: *** -[NSKeyedUnarchiver validateAllowedClass:forKey:] allowed unarchiving safe plist type ''NSString' (0x1f30548c8) [/System/Library/Frameworks/Foundation.framework]' for key 'NS.objects', even though it was not explicitly included in the client allowed classes set: '{( "'NSMutableArray' (0x1f304d690) [/System/Library/Frameworks/CoreFoundation.framework]" )}'. This will be disallowed in the future. BOOL _NSPersistentUIDeleteItemAtFileURL(NSURL *const __strong) Failed to stat item: file:///Users/gefa/Library/Containers/ch.psys.Observing-Las/Data/Library/Saved%20Application%20State/ch.psys.Observing-Las.savedState/restorecount.plist I am unsure about this feedback. Need I implement 'secure coding support' in future or is this done automatically? Best regards, Gerhard

Hello Quinn, I tried to implement your proposal. Need I to implement secure coding support as in the example? According to the example implementing 'secure coding support' requires about a dozen lines of code. What I have done: Deprecated code tmp = [NSKeyedArchiver archivedDataWithRootObject:savedSettingsArray]; settingsArray = [NSKeyedUnarchiver unarchiveObjectWithData:tmp]; (tmp is NSData, savedSettingsArray + settingsArray are NSMutableArray) I tried this: tmp = [NSKeyedArchiver archivedDataWithRootObject:savedSettingsArray requiringSecureCoding:true error: nil]; settingsArray = [NSKeyedUnarchiver unarchivedObjectOfClass: [NSMutableArray class] fromData:tmp error:nil]; Result: it works. Question: My app comprises about 500 methods, many of them contain pairs of deprecated NSKeyedArchiver+NSKeyedUnarchiver. I can't change these all at once. The chance of coding errors is great. So, I try to make changes bit by bit. How long does the deprecated code works? Although the corrected lines of code work the Console shows the feedback: *** -[NSKeyedUnarchiver validateAllowedClass:forKey:] allowed unarchiving safe plist type ''NSString' (0x1f30548c8) [/System/Library/Frameworks/Foundation.framework]' for key 'NS.objects', even though it was not explicitly included in the client allowed classes set: '{( "'NSMutableArray' (0x1f304d690) [/System/Library/Frameworks/CoreFoundation.framework]" )}'. This will be disallowed in the future. BOOL _NSPersistentUIDeleteItemAtFileURL(NSURL *const __strong) Failed to stat item: file:///Users/gefa/Library/Containers/ch.psys.Observing-Las/Data/Library/Saved%20Application%20State/ch.psys.Observing-Las.savedState/restorecount.plist I am unsure about this feedback. Need I implement 'secure coding support' in future or is this done automatically? Best regards, Gerhard

Thank you very much.Problem solved

Thanks for your advice I will try it next time when confronted with a new problem. In the meantime my submitted problem is solved . Best regards, gefa.

After I got no ack from DTS I went back: the counter wasn't decremented. So something went wrong although I submitted my request correctly - at least it seems to me to be so. Best regards gefa

Hello Claude31, thanks for your answer. The buttons at bottom right of Xcode window should be like this (blue) Both are blue. Sorry about my wrong citation you monitored: print ("newRecordName is: (self.newRecordName)") That's a write error. In my app the syntax is correct: print ("newRecordName is: (self.newRecordName)") Some more info may help: The logs of print(…) should appear in a separate window of Xcode. This worked well about 2 or 3 weeks ago. I haven't changed anything. Perhaps an update - but I am not sure. Anyway. Here are some version infos: Versions: macOS 11.6 / iOS 15.2 / Xcode version 13.2.1 / iPhone Xr / iMac Circumstance: the iPhone is attached to the iMac for feedback of an app that runs on the iPhone. The Xcode window looks like this: Best regards Gerhard