Post not yet marked as solved
Xcode 14 introduced some ridiculous Info.plist management bugs which are not yet fixed in Xcode 15:
The bugs are manifested in the General and Info tabs of target management:
-The Build value in the General tab is not in sync with the CFBundleVersion value in the Info tab (that is, changing the value in the General tab won't affect the Info tab and vice versa).
-The App Category value in the General tab isn't in sync with the LSApplicationCategoryType value in the Info tab.
-Additional document type properties in the Info tab cannot be added: clicking "Click here to add..." doesn't do anything.
-Document types in Info tab cannot be deleted: once you added a document type instance (even as a test) there's no way to remove it.
Something is going wrong with Mac App Store.
Suddenly, I can't submit an app due to an "Invalid Provisioning Profile Signature" error:
Invalid Provisioning Profile Signature. The provisioning profile included in the bundle com.***.*** [com.***.***.pkg/Payload/***.app] cannot be used to submit apps to the Mac App Store until it has a valid signature from Apple. For more information, visit the macOS Developer Portal. (ID: 63ae9290-28e2-4a65-8614-***)
I've never seen this error before.
This is a macOS app so no provisioning profile is even required.
Nothing changed in the signing settings I've been using to submit this app many times before.
Also, I have another, semi-pro, version of this app on the App Store. It's just another target in the same Xcode project which uses exactly the same signing settings as the first target. No issues submitting this version.
I assume it's a bug in the Mac App Store engine - I did submit it to Apple.
Still I wonder if anyone has experienced this error and has any suggestions.
macOS 13.2
Xcode 14.2
Thanks,
Leo
Post not yet marked as solved
I wonder if anyone has figured out a way to retrieve ALL available
Finder tags on Monterey and later?
On pre-Monterey systems, it was possible by reading this file:
~/Library/SyncedPreferences/com.apple.finder.plist
However, this file doesn't exist anymore.
Other methods (such as reading Finder prefs or fileLabels of
NSWorkspace) only return the 8 standard labels - but not any custom tags
created by the user.
Googling the subject didn't produce any results.
Thanks for any info,
Leo
Post not yet marked as solved
Xcode 14 keeps being unusable on Ventura: any IBOutlet properties created on Ventura won't be recognized in Interface Builder.
It also applies to the latest beta, Xcode 14.1 RC2.
No issues on Monterey.
It's unusual that such a major bug could make it into the final release (of whether Xcode or macOS or both). It's not some kind of a minor obscure issue that's easy to miss. It's a part of core functionality. The bug makes development in Xcode on Ventura pretty much impossible (at least in Objective-C, don't know if it affects Swift).
Post not yet marked as solved
It appears that Xcode 14 is simply unusable at this point as new IBOutlet properties are not recognized.
(Outlets created in pre-14 Xcode versions appear with a warning sign in Xcode 14 with a tooltip claiming that outlet doesn't exist).
To reproduce, create a new outlet in the header file of the app delegate class (or any other class instantiated in Interface Builder):
@property (nonatomic, retain) IBOutlet NSButton *testButton;
then select this class in Interface Builder and open the Connections Inspector.
The testButton outlet will NOT appear in the list of outlets.
This naturally makes Xcode 14 totally useless at this point.
Bug is submitted to Apple.
I wonder if there are users who do not experience this behavior?
Thanks,
Leo
Post not yet marked as solved
I wonder if others have the same issue on Monterey:
Read-write disk images are not opening automatically when double-clicking the .dmg file (that is, the disk image is mounted by its window doesn't open).
Sending this command in Terminal does NOT help:
defaults write com.apple.frameworks.diskimages auto-open-rw-root -bool true
ALL read-write dmgs are affected.
There weren't issues on earlier systems.
(I did submit a bug to Apple and they asked me for my sample dmgs).
Post not yet marked as solved
Is it just my luck - or is Xcode 11 unusable?I just upgraded from Mojave to Catalina and installed Xcode 11 from App Store (all latest versions naturally).Xcode 11 is simply unusable.In brief:On attempt to use Interface Builder, Xcode 11 gradually becomes unresponsive and then everything deteriorates completely. Xcode 10 and everything else works normally.In detail:When opening a project and starting working with code everything seems to be normal. But once I open a .xib file things go downhill.In Interface Builder, when I click elements they're not selected right away but after a brief delay. And then it takes several seconds until the info in the inspector updates.Then scrollers stop working. The entire app becomes unresponsive - like I click tab and it takes awhile until it activates. Then several clicks I performed earlier with no effect, suddenly start executing one after another.Same thing in the code editor: everything I type happens after a brief delay. Code completion doesn't work at all.I did the following troubleshooting:-Deleted and re-installed Xcode 11-Restarted Mac-Created a new clean user and ran Xcode there-Restarted in safe modeNothing helps - exactly the same things happens every time in all projects.Once again, Xcode 10 works normally.Xcode 11 cannot be used.Specs:iMac 2017 27" 40 GB RAMmacOS 10.5.4Xcode 11.4.1 [noSwift, ObjC only, only Mac apps]Thanks for any feedback,Leo
Post not yet marked as solved
Hi Eskimo,Thank you for your reply on https://forums.developer.apple.com/thread/115670As you suggested, I start a new thread here.I finally got to the bottom of the issue (after wasting few more hours)...Here's the situation in brief:-I successfully sign my app for notarization.-I successfully notarize it with altool and successfully staple. Therefore, I now have an officially notarized app.-However, the notarization process creates an invisible ._Info.plist file in the app's Contents folder.Which results in the following outcome when checking the signature with codesign:codesign -vvv --deep --strict appPath--prepared:aFrameworkPath/Versions/Current/.--validated:aFrameworkPath/Versions/Current/.appPath: a sealed resource is missing or invalidfile added: appPath/Contents/._Info.plistLike I mentioned, this notarized app then goes into my custom installer on dmg, which dmg I also notarize.However, the above issue with ._Info.plist file causes error 65 on attempt to staple the dmg (after successfully running altool):Stapling failedProcessing: dmgPathCloudKit query for dmgName.dmg (2/8162101e375e6e3fd1b06cc397f56181b19db60c) failed due to "record not found".Could not find base64 encoded ticket in response for 2/8162101e375e6e3fd1b06cc397f56181b19db60cThe staple and validate action failed! Error 65.SOLUTION:Delete the ._Info.plist file from the app's Contents folder after notarization. It eliminates the error 65 - and dmg with installer can be successfully notarized.CONCLUSION:There's apparently a severe bug in altool (or stapler?) that injects malicious invisible files into the package of notarized apps - which invalidate their signature.I notarize my apps successfully for months - yet this experienced bug only yesterday for the first time. Also, it so far only happens with one of my apps.I also submitted this bug to Apple via Feedback Assistant.Thanks,Leo
Post not yet marked as solved
Hi all,I wanted to start building a notarization automation script.However, when I try to use the 'xcrun altool' in Terminal, I get the following error:xcrun: error: unable to find utility "altool", not a developer tool or in PATHI'm on macOS 10.14.5, Xcode 10.2.1.I then especially downloaded and installed Xcode Command Line Tools - still get same error.Other tools like stapler do work.I checked this dir and altool is not there: /Library/Developer/CommandLineTools/usr/binAny idea what's going on?Thanks!
Post not yet marked as solved
I wonder if anyone's familiar with this error which only happens when I upload my apps to Apple for notarization:"AppName.zip/AppName.app/Contents/Resources/EWSMacCompress.tar.gz/EWSMacCompress.tar/EWSMac.framework/Versions/A/EWSMac83886082""The signature algorithm used is too weak."Additional info:-I've been signing my apps for years with no issues. The error only happens when sending the apps for notarization.-I submitted a bug back in November 2018, provided Apple with all the info they asked for - but it was never addressed further.-I recently contacted Apple again and they pointed me to some resource page that was last updated back in 2016, which doesn't provide any solution either.-A search on this error didn't produce anything useful.-The tar.gz file in question is an eSellerate licensing framework. As many people may know, it's been a popular licensing platform for Mac software for over a decade. While I switched to a different licensing platform some time ago, I still have thousands of customers with eSellerate licenses (as I'm sure is the situation with many other Mac developers).As far as I understand, this whole situation has to do something with signing files inside tar.gz archives - on which I couldn't find any info either.Any help will be appreciated!Thanks,Leo
Leo Braun.