I submitted a couple apps last week that were revoked by Apple. I fixed them and tried to sumbit these apps again.
I have been getting this error for two days. I erased all my certificates and provisioning files on the provisioning portal and created all new ones . Also, I cleaned up everything in my keychain.
I am sure I am using the correct provisioning file in Xcode's build settings, and yet I still get this error. Why?
I solved this problem by the following steps:
Go to the file path where you save your provisioning file:
~/Library/MobileDevice/Provisioning Profiles
and remove all the provisioning files you have downloaded today.
Download the new provisioning file from the Apple member center that matches your project.
Press Command+B, rebuild the project, and see if this issue still exists.
Related
After upgrading to macOS Catalina with latest Xcode 11, I am not able to read files directly from user path when doing unit testing, example:
PROJECT_DIR + "/FolderX/myFile.json",
I keep getting error Thread 1: EXC_BAD_ACCESS (code=1, address=0x8)
This is also happened when I am trying to open a couchbase lite database with custom path.
Error:
error opening!: 14
Cannot open database, Error : Error Domain=SQLite Code=14 "unable to open database file" UserInfo={NSLocalizedDescription=unable to open database file}
I believe this is an issue due to the read write access between my simulator and the latest Catalina.
My current workaround is to add my files and database to target membership and read the files directly from [NSBundle bundleForClass:[self class]].bundlePath.
Is there any better fix to this? Like tweaking any setting to allow it to read files from custom path like in older versions?
You might try looking in SystemPreferences > Security&Privacy > Privacy tab. From there, scroll down to "Files and Folders" <-- There's where you can see programs and the folders they have been granted access to in Catalina.
Personally, I didn't have time to waste figuring out how the new file permissions are supposed to work, so I let Xcode have full disk permission. (Right above the "files and folders" is "Full Disk Access".
Of course, that solved all my issues... after I get a chance to play with the new file permissions, I may revoke that access and give it explicit folder access.
Well if anyone is still struggling with this, I've moved all my projects outside of ~/Documents/
it is strange that projects under ~/Documents/ doesnt get asked for read permission, other paths do!
I end up putting all my projects under ~/workspace/
** for those who doesnt know, ~/ means /Users/{your username}/
Check your File Access settings in the App Sandbox in your project's settings, under Signing and Capabilities. For example, I couldn't access files in /Users/Bert/Downloads, even after turning on Full Disk Access in Security and Privacy in System Preferences. I had to grant read access to the Downloads Folder in App Sandbox settings.
Xcode archives successfully using the latest - and correct - provisioning profile.
However, the Bots configured in Xcode Server still use an older profile.
This can be seen if one authenticates as xcodeserver user and navigates to ~/Library/MobileDevice/Provisioning Profiles.
Running security cms -D -i myuuid.mobileprovision confirms this.
Having tried reconfiguring a new Bot, restarting Xcode Server, deleting the old profile, and so on, nothing works.
How can we help Xcode 9 Server do what it promised, and use the latest provisioning profile from the Apple Provisioning Portal?
A dirty hack will work. This is assuming Xcode will correctly Archive using the correct profile. Unarchived the resulting .app file, then rename the embedded.mobileprovision file according to it's UUID, e.g.
myuuid.mobileprovision
Next, copy myuuid.mobileprovision to the ~/Library/MobileDevice/Provisioning Profiles folder.
Identify any older profiles linked to the same bundle identifier and delete. To play it safe, consider moving temporarily to ~/Desktop.
Finally, integrate the Bot, unarchive the resulting .app., and inspect to confirm creation expiry date, UUID, and UDID array are all as expected:
security cms -D -i embedded.mobileprovision
I have a Mac app that requires custom downloads for each user. I've done everything to sign the app for Gatekeeper, and it all verifies on the build. But when the app gets downloaded from the website with the custom file added, Gatekeeper no longer verifies.
Is there a way to do custom files without re-signing the app for each download? I just need to update a .plist file in the app bundle. The website is written in ASP.Net, so signing on the server probably won't work.
It sounds like you are attempting to sign your .app bundle, upload it to a web-server, and them modify a .plist value inside the .app wrapper before the .app bundle is downloaded and given to a customer.
Gatekeeper will not allow this. (At least, it will not allow it with "version 2" signatures, which are required for deployment on OS X 10.9.5 or later. It was permitted with the older signing system, so if you are content to deploy on OS X < 10.9.5, you could get away with it.)
See Apple Tech Note 2206 for reference (in particular the FAQ "I want to exclude files so I can fix my bundle after I build it"):
https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG302
Note: If you modify your .plist entry as you say you will end up with a broken signature, but all hope is not lost. If your users have the default security settings, they can still right-click on your .app bundle and say 'Open.' This will result in some scary security warnings from Apple, but if your users persist in clicking 'OK' then they will be able to run your app just fine.
I can build with Jenkins/xcodebuild when the project has the correct Provisioning Profile selected.
We want to be able to set the provisioning profile in xcodebuild.
Unfortunately, when the jenkins user runs
xcodebuild PROVISIONING_PROFILE="XXX"
...Lots of build output...
Check dependencies
Code Sign error: Provisioning profile 'XXX' can't be found
I can run the same line and have it work with a regular user account, accessing the file in ~/Library/MobileDevice/Provisioning Profiles/
The provisioning profiles are stored in /Users/Shared/Jenkins/LibraryMobileDevice/Provisioning Profiles
Anyone know where else the Jenkins user would be looking for these?
To answer this question: the provisioning profiles must be named after the UUID.
If you download and do not rename a .mobileprovision file, it will not be read by xcodebuild
A script for doing so is in another StackOverflow answer
My client wants to submit the project by himself so he asked me to get the xcode xcarchive of the project and send him to sign it and upload it.
He gave me his development certificate, I installed it and sign the target with its provision profile.
The build configuration that I'm using for signing is a copy of "Release".
Now when he tries to resign the archive and submit it, iTunes throw an error Invalid Binary and the culprit is the Signature
Its says :
Invalid Signature - Make sure you have signed your application with a
distribution certificate, not an ad hoc certificate or a development
certificate. Verify that the code signing settings in Xcode are
correct at the target level (which override any values at the project
level). Additionally, make sure the bundle you are uploading was built
using a Release target in Xcode, not a Simulator target. If you are
certain your code signing settings are correct, choose "Clean All" in
Xcode, delete the "build" directory in the Finder, and rebuild your
release target. Once you have corrected these issues, go to the app's
version details page (found in the Manage Your Applications module of
iTunes Connect) and click Ready to Submit Binary. Proceed through the
submission process until the app's status is Waiting for Upload. You
can then use Application Loader to upload the corrected binary.
Do I need the private key used by my client?
Can someone please point me to the right direction? Can I get any tutorial or video how to resign the archive and submit it to the store.
I think you should ask your client to generate a distribution certificate and then sign your project with it.