Hi all,
A few days ago I was unable to submit my app for notarisation, I would get this error message:
No suitable application records were found. Verify your bundle identifier ‘com.<snip>’ is correct.
This made no sense since I've never had to create an identifier to notorize apps that I distribute myself. Then, the next day the notorization succeeded with no warnings (and no intervention of any kind on my behalf).
However, for the last two days I've been trying to notorize the same app again (with a small bug fix) and once again keep getting the error above. Now I'm beginning to wonder if it's a problem with my set up or a problem with Apple's servers.
As a test I created the bundle ID on the developer site, but that didn't help.
Can anyone shed some light on what light be happening?
Tim Armes
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
I have a Mac OS application that's linked against a few dynamic libraries. Previously I hadn't needed to configure anything in particular in XCode. When exporting the application the libraries were automatically copied into the archive in a folder called libs.
When running otool on the version of the app created by XCode 11, I see this:
@executable_path/../libs/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0)
@executable_path/../libs/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
I'm now trying to export my app on Big Sur using Xcode 12. With no configuration changes on my behalf, the libraries were no longer exported at all, so the app wouldn't work on any other machine. To try to fix the issue I'm telling Xcode to embed them from the general settings.
Xcode then adds them to the copy phase, and they are now exported (albeit in the Frameworks folder):
The run path search option it set to:
@loaderpath/../Frameworks
@executablepath/../Frameworks
@executable_path/Frameworks
But despite all this, the main binary still isn't linked against these embedded versions:
/opt/local/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0)
/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
If I run otool -D against one of the embedded libraries, I get this:
otool -D libcrypto.1.0.0.dylib
libcrypto.1.0.0.dylib:
/opt/local/lib/libcrypto.1.0.0.dylib
Does anyone know haw to solve this, or have any suggestions to try?