The executable was signed with invalid entitlements - oh! my, again - ios

I bounced again in this error when trying to install an app neither on my iPhone and iPad. I applied all the suggested measures to no avail. In particular I removed all the profiles for the app from my iPhone, cleaned the derived folder, restarted the iPhone and Xcode, checked the identity between the profile in the project and in the target (I set automatic in the former), tried removing the Entitlement reference and keeping it and even created a new certificate and provisioning profile; all of this for nothing.
Other targets for this project install fine, it works fine on the simulator and submitting it to the app store for TestFlight testing does not create any problem either; so the problem seems just connected to physical debug devices. What else could it be?
Sometimes an "unknown error" pops up instead of the invalid signing one after a very long time since ending compilation.

Found. The issue was due to the Release choice creeped in the scheme build configuration.

Related

iOS app upload to iTunes Connect results in Invalid Signature issue

I'm working on a hybrid mobile app project (Ionic framework) and releasing to Android, iOS and web. This issue concerns only releasing the application on iOS.
I ran into an issue whereby I suddenly started getting the following email from iTunes Connect after building, archiving and uploading my iOS app to App Store from Xcode.
App Store Connect: Your app "YourAppName" (Apple ID: XXXXXXXXXX) has
one or more issues
Dear Developer,
We identified one or more issues with a recent delivery for your app,
"YourAppName". Please correct the following issues, then upload again.
Invalid Signature - A sealed resource is missing or invalid. The file
at path [YourAppName.app/YourAppName] 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
Best regards,
The App Store Team
I tried everything I could find on the internet regarding this issue:
Checking over my certificates, provisioning profiles, recreating them, updating Xcode, building the project again, made sure I'm using a distribution certificate not an ad-hoc certificate, verified the code signing settings in Xcode were correct, verified the bundle was built using the Release target, tried the "Clean All" option, deleted the "build" directory in the finder and rebuilt the release. In short - I tried everything I could find by Apple regarding this issue, also looked up the same issue in StackOverflow and tried a huge variety of the recommended solutions. I tried all of those options multiple times over to make sure I didn't miss anything.
Nothing worked...
Also a note that I was able to upload to App Store without any problems before. There hasn't been any changes to the project which could result in this Invalid Signature issue arising - no certificates have expired, no new ones have been created, no new provisioning profiles have been created. The same profiles and certificates were used which worked just fine some time ago. iTunes Connect just suddenly started responding with this issue.
What else can I try?
I was sceptical at first when I tried this solution but this actually solved my issue.
Find a spare USB stick or an external hard drive.
If your Mac's filesystem is APFS format the external volume using a HPFS Mac OS Extended (Journaled) file system. Move your project over to the freshly formatted HPFS external volume and rebuild it over there. This is important as if you build it on your Mac's APFS volume and then move it over to your HPFS external volume to archive and upload in Xcode this will not work!
The project needs to be built, signed, archived and uploaded ON the HPFS volume.
The uploading to App Store should now work again. It worked for me, hope it works for you as well.
See more information on the solution here

Beta from Crashlytics fail to install build on testers' devices

I'm sending my app to testers with Beta from Crashlytics which is an amazing tool to do app testing.
I had every new tester's device UDID registered in my developer account and then distribute a new build.
My testers got email invitation and accessed app's installation which could not be completed on their device.
They kept seeing an alert showing up with message:
Unable to download app - MyApp could not be installed at this time -
Done / Retry
Testers' testing status are "installed" in my Crashlytics dashboard but they're actually not able to finish installation.
Please help me find any possible factor causing this problem.
Perhaps the provisioning profile embedded in the build has been invalidated. Use Xcode to create a new archive, then use Fabric to upload a new build with that archive.
Discussion:
In my case, I had deleted the provisioning profile in the Apple Developer Member Center that had been embedded in each of my Fabric Beta builds. This caused the app testers had previously installed to immediately crash when they tried to launch it (embarrassing). It also caused the "Unable to download app - MyApp could not be installed at this time - Done / Retry" issue when testers tried to (re)install the app via Fabric Beta. Uploading a new build with my new provisioning profile embedded fixed the issue (each tester had to install the new build).
I've run into this problem back on iOS8 and just recently saw it again for iOS9, the only thing that solved the install issue was for my users to delete any previous version that they had downloaded, restart their phone, and try again.
You can also verify with them if Crashlytics properly installed on their iDevice, I've seen more than once where the configuration profile caused the issue, it's worth removing that (Settings -> General -> Configuration Profile (towards the bottom)) and retrying the install.
This is usually caused by one of two problems:
Incorrect provisioning profile/code signing settings. Double- and triple-check that the following settings are the same for the project and the provisioning profile: bundle identifier, development vs. distribution, adhoc.
Caching - sometimes, even when you've done everything correctly, things still just go awry. In such cases, you can try: deleting the previous version of the app from your phone, cleaning your project, deleting and re-downloading provisioning profiles, and building the app again.
RubyMotion Solution
For me, it was because I was using a development distribution profile, but with the wrong entitlements. Well, entitlement, singular.
I still had the 'beta-report-active' entitlement enabled, which was not included with the development distribution profile I am using. It is instead included with the production distribution profile (which is needed to distribute to TestFlight). However, I just wanted to deploy to my local phone, and not air my dirty app laundry to my entire internal test group, so this is where I found myself.
In any case, removing the 'beta-report-active' entitlement fixed my issue.
I tried the normal route of checking for proper certs and also deleting the app and provisioning profile along with rebooting device. In my case it was installing on device A and not device B. Device A was older iPhone 5c running iOS 9 and device B was newer iPhone 8 running iOS 11.x. When I archived the app for distribution I was selecting device A during the archive. Once I selected "Generic Device" it worked. But I'm sure I've built in the past selecting a specific device instead of generic and it worked. I was using Xcode 8.2, but I don't believe the Xcode version matters.

Failed to get the task for process [duplicate]

I have the following error when I try to run a new project on my ipod:
Error launching remote program: failed to get the task for process 312.
The program being debugged is not being run.
I've read about Entitlements.plist, and I've tried to add the get-task-allow, but then it doesn't let me compile because of a code signing error. I only have a development provisioning profile, so it's not the same as the people who were trying to debug the distribution build (I'm also in the debug build, so that isn't a problem).
Old projects build and run fine on the ipod, just new projects.
I've tried restarting both xcode and my ipod, but it doesn't help.
I have no more ideas on how to build/run new projects on xcode, so any help is much appreciated!
Oh, and I'm using an iPod 3G with iOS 4.0.1. Xcode is 3.2.3 (64-bit).
It turns out that using a different provisioning profile (one with a wildcard rather than one without) solved this issue.
The key point is to use a Developer profile rather than a Distribution profile.
Check that you're doing signing using a development provisioning profile, not a distribution one.
This error happens when you have set Distribution Provisioning profile in code signing. Change it to Developer Provisioning Profile, then it will work. Worked for me for Xcode SDK 4.5.
There is also a case that your error would happen.
If an app with same Bundle Identifier is launched at background ( probably an App Store version ), Xcode debugger will not know which App it should attach to. To solve it, remove/uninstall the App Store version, and click Run in Xcode again.
The same story can apply if you once build the app with a bundle id then you changed the project bundle id and still kept both app versions. make sure you remove the old one.
If your certificates are not quite right or have become not quite right, this problem can start to happen and you can go round and round playing with provision and entitlement files to no effect. (In nearly all cases, you don't need an entitlement file.)
I'm talking here about debugging on a tethered device in "debug" mode, not any sort of "release" mode.
Here's how I finally determined this was the problem and fixed it:
1) Try to create the simplest Xcode project possible and in Target...General set it up for your "Team". (If you find this impossible to do, that already is a sign of this sort of problem.)
2) Tether your device and try to run on it. Normally, this would go smoothly, but if the opening screen appears on your device for a second or two and then the app crashes and Xcode says it can not attach to some positive task id, then you may have the sort of problem I had.
3) So I then went to another Mac with Xcode and did the same thing, letting Xcode 5 automatically get the needed credentials. (I'm using a "wild card" * app id for all of this.) In my case, much to my surprise the simple app I created on the new Mac ran on the tethered device just fine keeping up its opening screen indefinitely. What a relief. So I then went to keychain access on the new machine, exported all of the relevant keys into one file and then exported the relevant certificated to a .p12 file. I also made a copy of the new working project to take back to the first Mac.
4) Back at the first Mac using the app for the second Mac, it had trouble with the Team ID when I looked at the Target...General screen. Your symptoms might be different, but the point is I couldn't rebuild the app from the second Mac on the first Mac.
5) So I then opened up Keychain Access (possibly not necessary) and double-clicked on the files I brought over, first the one with the keys and then the one with the certificate, providing the p12 password when requested. (Some of this may not actually be necessary, but I'm not sure which and I am describing what worked for me.)
6) I did step 4 again and this time it worked fine! I then found that the other programs that were giving me the "failed to get task" problem now worked fine, too. I just wish I could get back all the time I lost before I tried the process described here.
Conclusion, something was wrong or had become wrong with the certificates or the keys on the first Mac. It was subtle enough that I could still do builds, make ad hoc releases, etc. but I could not run on a tethered device. Though I don't think it is a factor, I was using a corporate developer account and this Mac was set up to do development for several other developer accounts (and these did not display the problem).
After Xcode 5.0 tried and failed (it hung) to update certificates, ... which it suggested me to do. All I did then:
Restart Xcode 5.0
Open Window > Organizer
Select Devices at the top
Select my device (which had a green bullet)
Click the (+) Add to Member Center at the bottom and follow the few simple steps
Go to the Apple Developer Center and make sure that your developer certificate has not expired. Mine had expired so I renewed it and then went back into Xcode (5.1.1) and under accounts preferences I viewed the details of my apple account and hit the little refresh button at the bottom. My iOS development signing identity showed up and I was back in business.
Removing distribution profiles from device in Organizer solved this issue for me
1.Run the Application using development certificates in both debug and release area in code signing identity.
or
2.Use the development certificate in debug area and distribution certificate in release area.

Problems with code signing for ad-hoc distrubution for iPad App

I've been trying for a weekend now to install my application via ad-hoc means for beta testing and demo purposes. I can install from Xcode just fine, but when I try and take the app file and place it into iTunes, then try and synch, I keep getting the error "The application was not installed on the iPad because it is not signed".
I have gone through all the steps. We went to the provisioning portal and added all the devices. We then downloaded a distribution provisioning profile and installed that onto the development computer. We created an Entitlements.plist file, though there was no get-task-allow attribute, so I had to add in my own. I cleaned the targets, restarted Xcode, built the application under the ad-hoc profile with the Entitlements.plist set for the Code Signing Entitlements.
I take the app file that's generated and drag it into the Applications area of iTunes, hit synch, and I get the error.
I know I am doing something wrong, missing a step, but it must be a convoluted, obscure step that Apple doesn't have in their documentation. So can anyone see the problem in what I'm doing? If you could, let me know. Thanks.
Ok. Yay. Figured this out after some more hair-pulling.
Apparently, the build you follow is important. I kept testing and building to the Simulator folder, and this is wrong.
To deploy to a device, you should clean all targets and then build specifically to the device. You don't have to run it or have something plugged in, but you must build to device. The APP that is produced is different for simulator as it is for device.
Did you set the "Code Signing Entitlements" build setting in your target to "Entitlements.plist"?

Porting iPhone app to iPad fails to sign?

I am able to create a new application profile targeted for my iPad, however, when I convert from iPhone to "Universal" device, I am getting an error in signing.
[BEROR]Code Sign error: a valid provisioning profile matching the application's Identifier 'rfc1034identifier' could not be found
Also note: I am able to run it in the simulator (which does not require signing).
It is a very old application ~OS version 2.x or 3.1 that had SDK problems which required more manual process to get the signing code into the build settings, so I would not be surprised if there is some residual foo in the build settings.
I ended up starting over and created all the device certificates and provisioning profiles. At least the new XCode knows how to put the values in plist and install the provisioning profile on the device correctly. After I got a good project configured/setup, I did find the problem in the bundle-name setting that was somehow hooked to an expired provisioning profile.
Also, I may have missed the new shorter expiry time. Either way, I am going to mark this one as user error ... but still claim that the build error messages could do a better job of jumping to the location of the error.

Resources