Again, thanks for all of your time with this issue. I guess I didn't know that in 5 years time away a user requesting a file was a "restricted" entitlement (it wasn't before), or that my explicit App ID from 5 years before needed to be changed by Apple to include my current Team ID prefix. And I have no idea about extensions, keychain access, TestFlight, etc. for this simple app LOL. This Validation Hell is well-named, and I'm hoping no critical bugs are found in this update because this process is certainly not "Automatic".

After weeks foiling the forum and Developer Support and then back to DTS, several hours with Claude allowed me to update my app. Fingers-crossed for Review. Here is a summary of the issue provided by Claude.ai: Xcode Organizer's "Validate App" / "Distribute App" GUI flow was silently reusing a stale, cached export/signing configuration from the very first failed attempts — made months earlier, before the Team ID issue was ever corrected. Every subsequent click of "Validate App" regenerated the same old broken identifier, regardless of how clean the underlying archive, profile, or certificates actually were. This cached state was invisible and not cleared by normal troubleshooting steps (deleting DerivedData, signing out of the account, even creating brand-new archives). The fix was to bypass Organizer's GUI entirely and drive the export/validate/upload process from the command line instead, which uses only the settings explicitly provided each time — no hidden cache.

Well first, going to App Store Connect for a new profile erred out when I installed it in Xcode because it did not include MacOS platform. But the profile did show the App ID prefix as I posted before and you wanted me to check. So I created another profile for the Mac App Store, the new profile again looks good with the Team ID, bundle identifier, etc. installed it, and did the Manual signing and everything looked good UNTIL I tried to validate the archive and again go the same??? errors (below). I couldn't find 346JXXXXXX anywhere in Xcode but it keeps showing up. Even in the Archive Contents plist the Team ID is listed with the correct bundle identifier. So, what now? Invalid Provisioning Profile. The provisioning profile included in the bundle com.enatal.Contact-Sheet-Maker [Photo Contact Sheets] is invalid. Invalid 'com.apple.application-identifier' entitlement value. For more information, visit the macOS Developer Portal. The server’s response was: ‘{ code = 91130; description = "Invalid Provisioning Profile. The provisioning profile included in the bundle com.enatal.Contact-Sheet-Maker [Photo Contact Sheets] is invalid. Invalid 'com.apple.application-identifier' entitlement value. For more information, visit the macOS Developer Portal."; }’. Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “346J2Y98RX.com.enatal.Contact-Sheet-Maker” value for the com.apple.application-identifier key in “com.enatal.Contact-Sheet-Maker.pkg/Payload/Photo Contact Sheets.app/Contents/MacOS/Photo Contact Sheets” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID. The server’s response was: ‘{ code = 90286; description = "Invalid code signing entitlements. Your application bundle\U2019s signature contains code signing entitlements that aren\U2019t supported on macOS. Specifically, the \U201c346J2Y98RX.com.enatal.Contact-Sheet-Maker\U201d value for the com.apple.application-identifier key in \U201ccom.enatal.Contact-Sheet-Maker.pkg/Payload/Photo Contact Sheets.app/Contents/MacOS/Photo Contact Sheets\U201d isn\U2019t supported. This value should be a string that starts with your Team ID, followed by a dot (\U201c.\U201d), followed by the bundle ID."; }’.

The error contained this again: "Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “346JXXXX.com.company.appname". I tried via Automatic signing and manual with the same results. So, Xcode is not using the Team ID???? And here's what Developer Support answered back: "Thank you for your patience. I have an update from our engineering team. Please reach out to the internal team handling code-level issues. To get help with code-level issues from Developer Technical Support (DTS), you can submit a Technical Support Incident in the Code-level Support section in your account. Stephanie Developer Support" Don't really think this is a code-level issue???. So, back to the beginning with DTS (and I thought you were DTS)???

Apple Developer Program Support is the WORST. After three weeks, and two advisors providing robotic/AI communications, their answer was basically one line saying the problem should be resolved, and if not, start all over again. The "new" error messages are exactly the same as they were a month ago but with an App ID different from the one I clearly requested as described previously. I am still unable to validate my update.

I was obviously not in a hurry to update this app, but is it normal for DTS to take ~3 weeks, and counting, to change the App ID?

The first option works for me because I have never used TestFlight nor ever plan to with this amount of validating hell. First of all, I haven't heard that any of this was my fault or stupidity from the beginning, and I guess I am stupid because I do not know how to "Migrate from a unique App ID prefix to using your Team ID as the App ID prefix". I guess, I'll need step-by-step instructions because nothing I tried works. I tried changing the bundle identifier in Xcode to "QZ9XXXXXX.com.company.My-App" with no provisioning profile. And apparently, it thinks it's a new app, and not an update with a different SKU (the same as the Identifier but not the app's SKU). I'm sorry that this is taking so much of your time. You helped me so much for an app even older than this wth BLE and it's still working at a least a decade later (and selling). And then this: I also tried creating a new App ID with the Team ID, but that doesn't seem to go anywhere when there is no provisioning profile to use it with???

Oops, code block doesn't do what I thought (again). Here are the complete descriptions. Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “346XXXXXXX.com.company.My-App” value for the com.apple.application-identifier key in “com.company.My-App.pkg/Payload/My-App.app/Contents/MacOS/My App” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID. Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “346XXXXXXX.com.company.My-App” value for the com.apple.application-identifier key in “ccompany.My-App.pkg/Payload/My-App.app/Contents/MacOS/My App” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID.

Wow, thanks for your lengthy response BUT I'm still in Validation Hell. I'm right back with the same errors. I do not plan new MacOS apps at this point (which I hope can use Automatic Signing) so I chose the manual provisioning distribution profile route as you described. The provisioning profile was created with my App ID with my one of my two Distribution certificates (Distribution for Use In Xcode and Mac App Distribution - I used the former). The signing certificate I myncluded Team ID QZ9XXXXXXX. <key>AppIDName</key> <string>My App</string> <key>ApplicationIdentifierPrefix</key> <array> <string>346XXXXXXXX</string> </array> nd this was the provisioning profile Name: MyApp MacOS Dist Prov Profile Type: App Store App ID: 346XXXXXXX.com.mycompany.my-app I imported this profile into Xcode for Manual, cleaned the build, archived it, tried to validate the archive, and got these same errors. Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “346XXXXXXX.com.company.My-App” value for the com.apple.application-identifier key in “com.company.My-App.pkg/Payload/My-App.app/Contents/MacOS/My App” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID. And again, Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “346XXXXXXX.com.company.My-App” value for the com.apple.application-identifier key in “ccompany.My-App.pkg/Payload/My-App.app/Contents/MacOS/My App” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID. It seems the validation code still wants my Team ID (QZ9) as a prefix and not the App ID (346). Or did you mean that I should add my Team ID as part of my bundle identifier?

Here is the complete descriptions for the validation errors. Again, don't know why Automatic Signing Management for a MacOS app generates these. Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “346JXXXXXXX.com.enatal.Contact-Sheet-Maker” value for the com.apple.application-identifier key in “com.enatal.Contact-Sheet-Maker.pkg/Payload/Photo Contact Sheets.app/Contents/MacOS/Photo Contact Sheets” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID. Invalid Provisioning Profile. The provisioning profile included in the bundle com.enatal.Contact-Sheet-Maker [Photo Contact Sheets] is invalid. Invalid 'com.apple.application-identifier' entitlement value. For more information, visit the macOS Developer Portal.

To clarify, this is a 2021 MacOS app (not 2011), 346JXXXXXX is my Team Member ID, QZ99XXXXXX is my Team ID, my Bundle ID is in this format: com.company.app-name, this app's Apple ID is 1575XXXXXX. I'm the Admin for the Team (of one). I have no idea why the Team Member ID prefix is appearing in the error messages for a MacOS app and causing this issue. I didn't even know I had that Team Member ID. Hope this info can lead to some resolution. Thanks.

After force quitting Xcode, restarting my iMac, opening Xcode, it never opens, and watching it on Activity Monitor, it shows up, but then turns red as not responding x2. Sounds like my Xcode app is hosed or it is still trying to verify the simulator runtime??? I'm not sure how to completely delete and reinstall Xcode and get rid of whatever is causing it keep verifying the runtime.

Yes, thank you ZackJarret. I had that ".identifier" in one permutation but not with (__bridge CFStringRef) (because I got another warning saying it could not bridge or something earlier - again I'm clueless). And in the dictionary code, adding ".identifier" as a simple NSString was enough to make it all work. FWIW, I did try chatGPT with three goarounds and finally it came up comments below. I'm glad you're human. In recent macOS SDKs, UTTypeJPEG is deprecated, and you should use kUTTypeJPEG instead. If you're seeing a warning, it's generally safe to ignore it in this case because kUTTypeJPEG is the correct constant to use on macOS. #pragma clang diagnostic ignored "-Wdeprecated-declarations" CGImageDestinationRef destinationRef = CGImageDestinationCreateWithURL((__bridge CFURLRef)theURL, kUTTypeJPEG, 1, NULL); #pragma clang diagnostic pop

I have a MacOS app in the store that tries to address the issues related by starkadhr, and some potential customer (probably some Unix guy) asked whether the app could change the creation date/year of, again, scanned photos before 1/1/1970. No. With Eskimo's reservations about changing creation dates noted, I changed the creation date my old-fashioned way in ObjC (I don't do Swift - I'm passed my prime since I had one of the first 500 apps in the app store). NSDictionary *fileDict = [NSDictionary dictionaryWithObjectsAndKeys:createDate, NSFileCreationDate, modDate, NSFileModificationDate, nil]; [[NSFileManager defaultManager] setAttributes:fileDict ofItemAtPath:[self.urlForCurrentImage path] error:nil]; I'm wondering if this ObjC code below will work with earlier dates than 1970 or is this still using setFile/old Unix code somehow? - (BOOL)setUnixSafeFileCreationDate:(NSDate *)date fileURL:(NSURL *)url { NSError *error = nil; BOOL success = [url setResourceValue:date forKey: NSURLCreationDateKey error:&error]; if (!success) { NSLog(@"NSURLCreationDateKey error: %@", error); return false; } else { return true; } }

So, I had a similar circular warning for this same method where I wanted to identify a JPG or a PNG image and create an image with the appropriate extension. Although a good example of how to use it was not clear to me and here's what worked for me (Objective C). Import the newer identifiers: @import UniformTypeIdentifiers; Create a property to hold the identifiers: @property (strong) NSString *imageType; Assign one of the identifiers to the property: if ([theImageExtension isEqualToString:@"png"]) {         _imageType = (NSString *)UTTypePNG.identifier;     } else {         _imageType = (NSString *)UTTypeJPEG.identifier;     } Use it: CGImageDestinationRef destinationRef = CGImageDestinationCreateWithURL((__bridge CFURLRef)theURL, (CFStringRef)_imageType, 1, NULL); And that worked! (after many permutations)