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.
Related
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.
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'm at the point where I'm ready to build, but when I try to archive the project I get the following error in xcode:
app_sign cannot resign
/Users/me/Library/Developer/Xcode/DerivedData/My-App-bzgdaitstcabzpaiygqfnluetfhk/Build/Intermediates/ArchiveIntermediates/App/InstallationBuildProductsLocation/Applications/My-App.app/My
App. Please remove and then build
Does anyone know why this is happening?
In build settings I've tried leaving the code signing identity blank, and tried it with the correct distribution profile.
I've tried with and without the provisioning profile specified.
I've tried deleting the whole file in my DerivedData folder.
It would seem that this is the line in question that causes the problem:
"$TOOL_PATH" app_sign sign "$SHARED_RESOURCE_DIR/developerkey.cert"
"$CORONA_RESOURCE_CAR_PATH/resource.car" "$CORONA_EXECUTABLE_PATH"
little
But I don't know enough about what it's doing here to think of the solution. If I build the sample app that comes with Corona Enterprise still builds fine, but my own app still fails.
It turned out that the problem was to do with the xcode.proj file itself. Not sure what the cause was, it seemed to be keeping a reference to a file which no longer existed, rather than the new build.
I made a new project, copied all of my own source files across but left the new proj files in, and then it built successfully.
I did a major restructuring of my app, and decided the easiest way to do this, was to create a new project with a new name. After everything was working, I went in and renamed the project but now I get "A valid provisioning profile for this executable was not found."
I went into my app-info.plist and ensured that my CFBundleIdentifier is the same. I confirmed that the Project Name is the same, and that the built app is the same. I confirmed in my Build Settings that it shows my Distribution Profile.
This is the first time I've completely rewritten the app this way, is there something I've missed?
Have you tried cleaning both projects? (cmd+shift+k)
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.