I had successfully uploaded an app for TestFlight but after archiving and uploading now it is giving me this error I can't explain. Just to make sure I unchecked all entitlements in the capabilities target tab but that doesn't seem to matter.
I looked over all the app id's, certificates and provisioning profiles but there's nothing that looks abnormal. I would look in the actual .plist file generated by Xcode but I don't see where it is or if it even exists. Where should I even check to verify what's going on? Xcode is a buggy mess so I don't even trust this isn't some random bug (I cleaned the target of course just to make sure).
Automatic signing is unable to resolve an issue with the "..."
target's entitlements. Switch to manual signing and resolve the issue
by downloading a matching provisioning profile from the developer
website. Alternatively, to continue using automatic signing, remove
these entitlements from your entitlements file and their associated
functionality from your code. Then rebuild your archive and try again.
Provisioning profile failed qualification Profile doesn't match the
entitlements file's value for the application-identifier entitlement.
I had a terrible time with some old projects where I had to use manual signing because I couldn't get automatic provisioning to work. Then I discovered the following solution, which has worked for me 100%:
Switch to automatic provisioning if you haven't already.
Edit the target build settings and search for Sign. You should see four Code Signing Identity entries and they should all say iOS Developer. (If one of them says iOS Distribution, that's the kiss of death.)
Still editing the target build settings, search for Provision. Scroll down to the bottom and see if there is an explicit extra provisioning profile setting giving a profile number. If so, delete it.
Edit the target capabilities. Turn Game Center and iCloud and In-App Purchase on. Now turn them off again. This will give you an empty entitlements file (you can confirm this in the project navigator).
You will now be able to build to a device, archive, and export to the App Store, using automatic signing throughout.
I have had a very similar issue with Xcode 9.4, the only difference being that the error referred to issues with both the application identifier and keychain access groups entitlements.
I switched from automatic Xcode signing to manual signing to try to fix the problem. After some mucking about that did not help (and that I don't think contributed to fixing the problem) I ended up re-enabling the Xcode automatic signing. This appears to have fixed the problem. I was able to clean, archive and upload without any issues.
Not a particularly satisfying answer, but it worked for me.
Related
I am trying to publish my app on the app store but I get this error. I have no idea where it is coming from. My certifications and signing are managed automaticaly by XCode. (Select is empty because I erased it on the screenshot)
Invalid Signature - A sealed resource is missing or invalid. The file
at path [AlphaBane.app/AlphaBane] is not properly signed. 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. For more information,
please consult
https://developer.apple.com/library/ios/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html
https://developer.apple.com/library/ios/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html
I started a brand new project with Cordova, and I am still facing this error. As Always, Apple error are self-explained (irony). What do I have to do to fix this error ?
Thanks
I'm seeing the same thing in a project (on Xcode 9.2) with multiple targets (different version of a single app framework) - all targets pass except one. One of my apps continued to get this error. Perfect situation to look into why this is happening. I first thought it was the signature profile (development vs distribution certificate). Check that first.
But in my case, I had a few files that were not being used by the code that I had excluded from the build. When I added these resources my build passed. Check to see that all needed resources are included in the File Inspector panel. This includes code and media resources.
I encountered the following issue after upgrading to XCode9 (Well I could not completely isolate the cause because I re-generated the certificate right after upgrading for enabling Push Service) :
dyld: Library not loaded: #rpath/apowo.framework/apowo
Referenced from: /var/containers/Bundle/Application/2CD5CA32-1DAF-423B-B921-024DCBEE2AF0/picatown.app/picatown
Reason: no suitable image found. Did find:
/private/var/containers/Bundle/Application/2CD5CA32-1DAF-423B-B921-024DCBEE2AF0/XXXX.app/Frameworks/apowo.framework/apowo: code signing blocked mmap() of '/private/var/containers/Bundle/Application/2CD5CA32-1DAF-423B-B921-024DCBEE2AF0/XXXX.app/Frameworks/apowo.framework/apowo'
There are several similar posts over SO but I believe it might be caused by something new. In fact the original issue was not on XXX.framework but libswiftcore, and after I have done all the suggestions on SO the error came from my own libraries. And here is what I have tried:
clean
delete the derived data
restart XCode, Mac, and my phone
delete all the certificates and recreate again
delete the framework references (and the binaries as well) from the project and re-add
None of them works.
Some additional data is I am using jenkins and fastlane to manage the build. The XCode project is re-created every time when the job runs. The same job runs well on another machine which is on XCode 8 and nothing breaks (runs after re-creation of the certs so it is with the new certs).
I thought it was about the libraries and I rebuilt them on XCode 9. The newly built libs were also in the XCode 8 built app and worked well but not on XCode 9.
Any help will be appreciated.
I have tried the following step and it's working:
In XCode -> Build Phase -> Linked frameworks and libraries: choose your particular framework status from required to optional.
And it should work ;)
I was having a very similar issue which ended up being a coding signing / Certificating issue. This article goes over two possible solutions in depth. For me, it came down to changing my Developer Certificate's trust levels.
Open Keychain Access: My Certificates > "Right Click" Certificate > get info > Trust > When using this certificates > Use System Defaults
"When using this certificates" should go from Use Custom Settings > Use System Defaults
https://blog.supereasyapps.com/how-to-fix-iphone-and-ipad-app-codesign-crashes-using-an-apple-developer-profile/
Had the same problem, and no matter how many times I recreated the certificate, cleaned the project or toggled the "use system defaults" vs "always trust" setting in the certificate — nothing helped.
What did help is noticing that while I had an Apple Worldwide Developer Relations CA in the keychain, my developer certificate was still "signed by an unknown authority" (only shows up when I double click it, there is no red cross near it in the list like for the expired ones).
It turns out apple has 5 different WWDG CAs — https://www.apple.com/certificateauthority/ You may want to check which was used to sign your profile (Issuer Name -> Organizational Unit: Gx) and download the appropriate one (or all of them). In my case, for example, I only had G1 installed, while a new certificate auto-created by XCode was signed by G3 that was missing in my system. Installing G3 (download and double-click or drop into the keychain window) solved the problem and I was able to run the application on my phone again.
I updated to Xcode 6's final release last week, and all as gone well. I've been able to build my code, generate adhoc distribution builds (for legacy Testflight), etc.
Today I added some healthkit code, and had to enable HealthKit in the AppId to do the full build. After I did this, Xcode is refusing to Distribute the build I've just archived to create the final .ipa file. I get the error below no matter what now.
What I've done to try to fix this, as various tests:
regenerated my apps Distribution provisioning profile for adhoc release.
deleted all previous Xcode provisioning profiles, reinstalled and reimported all the provisioning profiles. The updated profile is present for sure.
changed the Team in the General settings, and changed it back to the correct one; allowed Xcode to try to "Fix" the issue.
Updated "build settings" to have the correct Distribution provisioning profile for Release, which Archives use. Confirmed code signing is correct for the Team
Tried "Automatic" for provisioning profile and code signing, as an alternate.
close and restart Xcode
None of this has helped generate the .ipa again, which worked before adding Healthkit support and invaliding all this.
How am I supposed to fix this to properly generate my ipa builds again?
EDIT
I was able to get an IPA built by installing an XC generated provisioning profile that appears to match my Distribution Adhoc profile entirely, except that it includes ALL the user devices I have in the portal, including ones that have long since been phased out (ex-employees). The only difference is the desired profile excludes about half the devices. I'd prefer not to have to do this.
I'm facing more or less similar problems since i started using XCode6. Before XC6, i could use my ad-hoc distribution provisioning profile that was linked to a limited number of devices to create an ad-hoc distribution.
Since XC6, I get the same error message as above, while at the same time Xcode generates its own XC Ad-hoc provisioning profile. From that moment on, when you try again,this XC generated profile is always used and you don't get the error anymore. But of course, at that moment it is using a profile that links to all my registered devices, which i do not want.
No matter what i have tried, eg removing all profiles, it keeps on generating and using that XC generated profile that links to all registered devices.
It gets worse: as a workaround, i tried to modify the XC generated profile and simply remove the devices i don't want. After refreshing in XCode and creating an adhoc distribution, I get the same error again stating that no profiles can be found. Again Xcode generates its own XC-adhoc profile, which of course already existed, and again all devices are linked back to that XC-adhoc profile...
FYI: i don't use anything like Healthkit or so, just default features.
Strictly speaking, it is not blocking from creating an adhoc distribution, but also in my case I have registered devices which belong to different customers, which means i prefer to limit the number of devices for a particular adhoc distribution.
Did you enable HealthKit in the apple developer portal in the app id and update your provision profile?
You need to activate that, and update your provision profile.
Please don't dismiss this as a duplicate without reading fully - I've scoured the net and stackoverflow and found many questions like this, but none of the fixes work and I'm not sure why.
It doesn't help that the xcode configuration is still offline at the dev center, but I should still be able to do this manually.
I'm preparing an app for submission and the code signing of the Archive isn't working.
Provisioning profile 'Company Distribution' specifies the
Application Identifier 'Company.*' which doesn't match the current
setting '2Cxxxxx3D5.Company.App'
So the issue is that it thinks the provisioning profile doesn't have the prefix of my apple developer ID, and when you look at the code signing options under settings you'd be inclined to agree, it says "Company Distribution for Profile Bundles 'Company.*'"
However, in organiser the profile clearly says '2Cxxxxx3D5.Company.*'. The App ID is right in Organiser but for some reason is then wrong in the code signing dropbox.
So far I have
Deleted all the profiles from my machine
Deleted all the profiles from the ios center
Cleaned the build, emptied the build directories
Restarted my mac
Restarted my iPad
Used the javascript hack to insert the Device IDs into a new provisioning profile, with a new appID, re-downloaded it and re-imported it.
I have exactly the same error with exactly the same symptoms again, I just can't work out why the profile is clearly correct in Organiser but then doesn't seem to translate through to the profile screen.
Can anyone throw any insight my way please? :)
Ahh the joys of codesign -- it has tripped up many developers trying to get build configuration setup. This too is a mismatch between a few different settings in Xcode and potentially your App Store Distribution Profile. There are three places that you have to make sure are set identically to ensure this error clears, each of which is tied to the AppID. I answered a similar question relating to a Development Certificate and Provisioning Profile, however the same set of checks is required for your App Store distribution certificates and provisioning profile:
A valid provisioning profile matching the application's identifier could not be found
That question includes some additional information about where particular settings are located, and the process by which one would go through to go from code to device build. A nearly identical process could be used to setup for App Store Distribution -- replace references from "Development Provisioning Profile" to "App Store Distribution" profile as well as omit those test device configurations that aren't applicable to Distribution builds and you should be good to go.
Should you rather try and debug using what you currently have, then read on:
At the core of code sign is the need for your AppIDs to match up in each of the documents issued by the 'Certificates, Identifiers, and Profiles' tool as well as in the build configuration of your Xcode project. There are a few ways in which you can solve the issue, either changing your provisioning profile and signing settings to match the same AppId, or changing the AppID to match your provisioning profiles. It is important to understand the ramifications of this decisions -- Unless you specifically need shared keychain access and specifically do not need any entitled services (In-App Purchase, Push Notifications, iCloud, Game Center, Newsstand, Data Protection, etc.) the option with the least restrictive results is to change your provisioning profile to match your current AppId.
Quickest (but most restrictive) route to a successful codesign build
Your description of the error certainly confirms the root problem -- You have a Distribution Profile named "Company Distribution" set to an AppID from the Certificates, Identifiers, and Profiles tool that is "Company.", however your App Specifies an AppID of "2Cxxxxx3D5.Company.App" which does not match the AppID that code sign is using. Put a different way, your project is configured to set the Bundle ID to "2Cxxxxx3D5.Company.App" while you are attempting to codesign a bundle "Company.". The "2Cxxxxx2D5." part violates the provisioning profile you (or perhaps the Xcode Automatic Profile Selector) has picked for your archive codesign operation.
The "2Cxxxxx3D5." part of your AppID looks suspiciously like an App ID Prefix -- this should not be specified in the Xcode App ID field (or in the Info.plist where that field's value is derived. Xcode automatically handles the App ID Prefix for you based on the Provisioning Provisioning Profile used to do code sign. If your Xcode App ID contains this prefix value remove it so that your App ID becomes "Company.App". In doing so, your Application's App ID becomes a valid App ID given the "Company.*" Distribution Provisioning profile that the error indicates is being used during code sign.
More sustainable fix -- Fix the AppID and Reissue the Distribution Provisioning Profile
As Apple continues to release 'entitlement' based services, it may not be agreeable to issue this app under the wildcard Provisioning Profile. Instead, the best way to retain the widest flexibility is to issue an explicit AppID for your Company's app, reconfigure Xcode, and reissue the Distribution Profile for that new explicit AppID. The linked answer above serves as a step-by-step guide for how to do each of these tasks except the Distribution Provisioning Profile. At a high level, the tasks to complete are:
Update the App ID in the Xcode project to omit the TeamID / App ID Prefix.
Ensure that the edited App ID is registered with Apple's Certificates, Identifiers, and Profiles tool.
Issue a Distribution Provisioning profile for the new bare-bones App ID
Install to Xcode, restart Xcode, then ensure that the Codesign Settings are using the new Provisioning Profile and Signing Identity.
Run the Archive.
Once you get the App ID matched up to the one encoded in the Distribution Provisioning profile you should be in a much better state to run your Archive. If you run into additional questions or problem, tack a comment on to this answer and we can see what we can do.
The instructions given in the Distribution page on the iOS Provisioning portal clearly still describe the process of creating, and including the Entitlements.plist file in a build for an ad-hoc distribution. The iOS Development Guide's Distributing Applications page, on the other hand, makes no mention of the Entitlements.plist file.
When I tried to "Build and Archive" our latest app following the instructions from the iOS Development Guide, the resulting ad-hoc app.ipa wouldn't install on my development device, due to a problem with the entitlements. When I rebuilt with the Entitlements.plist file, the new app.ipa installed fine.
Unfortunately, including the Entitlements.plist in the app.ipa means that the resulting build can't simply be re-signed and submitted to the app store - Right? Instead, I have to rebuild without the Entitlements.plist and submit the result to the app store.
I guess that I really have a few related questions:
Would the app.ipa produced as directed in the iOS Development Guide (no Entitlements.plist, just sign with the ad-hoc distribution provisioning profile) install OK on a non-dev device that was properly identified in the test distribution provisioning profile?
Is there any way for me to test the exact results of a "Build and Archive" on my dev machine, so that I can just re-sign it and submit it to the App Store from Xcode?
Will an app.ipa that explicitly includes an Entitlements.plist file be rejected if I did submit it?
Thanks!
As of Xcode 4.2 you no longer have to create an Entitlements.plist file when creating applications that do not require any special permissions to run. The get-task-allow entitlement is automatically set to true or false, depending on what kind of provisioning profile you sign your application with (Developer, Ad Hoc, or App Store).
ref:http://help.testflightapp.com/customer/portal/articles/535398-invalid-profile-distribution-build-entitlements-must-have-get-task-allow-set-to-false-
i just tried , no need entitlements for simply ad-hoc , simply using ad-hoc profile to archive and share , then fine .
From the iOS Developer library:
If you're doing an Ad Hoc distribution, you must properly configure your project to include an Entitlements.plist file and uncheck the get-task-allow checkbox (which sets it to False).
http://developer.apple.com/library/ios/#technotes/tn2242/_index.html
There's no issue with leaving the Entitlements.plist file in the Distribution build, I've had several apps submitted with it.
Actually, Entitlements.plist is also for other iOS features that your app may use:
Entitlements. These files define
properties that provide your
application access to iOS features
(such as push notifications) and
secure data (such as the user’s
keychain).
http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/iphone_development/115-Configuring_Applications/configuring_applications.html
Also check this answer:
The executable was signed with invalid entitlements
Get-task-allow is now called "Can be debugged" in Xcode 4.1 if you've used the modernization tool
I don't have answers to all your questions, but I needed to add an Entitlements.plist when I recently used ad hoc distribution for some testing. I think the documentation still talks about the 'get-task-allow' setting in the .plist, but when I followed the instructions exactly I had problems signing the app. Instead, I created an Entitlements.plist using Xcode's template. It has two or three settings, none of which are get-task-allow. I left it exactly as it was when created, and the build succeeded.
My experience in the past has been that apps submitted to the app store with an Entitlements.plist included failed the verification step.