I have a CI build machine running Xcode server and using a bot to generate a build, however the .ipa built via the bot is not being entitled to register for the APNS token.
Specifically, didFailToRegisterForRemoteNotificationsWithError gets called and there is a runtime warning of ""No valid 'aps-environment' entitlement string found for application".
However if I build the app on a separte development PC, or I build it actually on the CI machine independently of the bot then everything is fine.
I've used push notifications extensively in several apps so know that the message "No valid 'aps-environment' entitlement string found for application" always appears if the app has not been signed with the correct profiles. However I have absolutely 100% confirmed that the app is being built with the same profiles when running as part of the bot build to when I build it manually.
I also know that Xcode downloads provisioning profiles to different locations when running under the bot to when running for a user, and I also know that the bot runs as system and not the logged in user when I build manually. I have taken all these differences into consideration but am still unable to get the bot build to work.
What's more I have used this exact same CI machine to previously build this app using Jenkins (which also ran as system) enabled for push and it worked!
These is what I have done/checked:
1)
Download the project manually to the desktop, open in Xcode and examine the signing identity and provisioning profiles being sued in the build settings. Build and run it manually using Xcode -> it works
Download the project indirectly via the bot as part of its integration run. Open the project downloaded by the Bot in Xcode (the Xcode server downloads it to: /Library/Server/Xcode/Data/BotRuns//Cache/NNNN). Do the same thing, check the signing identity and provisioning profiles. THEY ARE IDENTICAL to those used when I build on the desktop
OK so the problem is not due to a difference in the actual signing identity and provisioning profiles being used.
2) When you run Xcode manually it downloads the provisioning profiles to location X, but the Bot downloads the provisioning profiles to location Y. So I have examined the contents of X and Y to make sure there is nothing missing from Y (if there was the build would actually fail however, which it doesn't).
To make absolutely sure they are identical I have copied the entire contents of X into Y and run the bot again (they don't get overriden by the bot) - So now the bot and the desktop builds are using the exact same copies of the profiles yet still there is a difference when the .ipa executes.
Incidentally the location of X is ~/Library/MobileDevice/Provisioning Profiles and that of Y is / Library/Server/Xcode/Data/ProvisioningProfiles.
3) When I build manually it is as the logged in user, but when the bot build it is as the system. So within the keychain I have tried copying all the certificates and keys from the user's keychain into the system keychain. Yes still it makes no difference, the .ipa created by the build bot fails to run properly while the build created manually via Xcode does run.
This is driving me mad and has wasted days already, what else could I have missed or could try to resolve this?
Any suggestions or ideas?
I have found the exact cause, as to the reason behind the cause I don't know, thus I'm marking mine as the accepted answer as it is at least a workaround to anybody who encounters the same problem. I'm tempted to think the reason is due to a bug in the bot system which is mistakenly expecting there to be an entitlements file.
I've discovered that the reason the bot build fails is because the bot is not placing the aps-environment entitlement into the .app file even though that entitlement is within the embedded.mobileprovision. But XCode does insert it into the .app file if built manually or an archive is built.
Also I've found that I can force the bot to put the necessary entitlement and associated information into the .app file if I use an Entitlements.plist.
But this is using Xcode 5 - entitlement.plist files are a thing of the past, so it should not be necessary to use one just to force the bot to place the entitlement into the .app, hence why I suspect it might be a bot bug.
Are you tried to unzip your .ipa and check embedded.mobileprovision they should be the same. Also just for sure check that you not use developer profile to release build in bot/xcode.
Shooting in the dark:
Although you said that the provisioning profile works great when you are running the build manually, have you tried creating a new provision profile from scratch and use that on the CI build machine using the bot?
Related
We're using Jenkins and Fastlane to automatically build and publish an app to App Center.
The publishing step is successful and it can be downloaded through App Center, but the app won't launch (it opens and immediately closes).
The builds we have submitted manually have a Provisioning Profile listed in the Release:
But the Fastlane builds have no value specified here, even though the logs say "All required keys, certificates and provisioning profiles are installed".
UPDATE: I've done some more digging and checked out the difference between a correct .xcarchive and an .xcarchive that leads to issues. The problematic one has no signing identity in its Info.plist ApplicationProperties SigningIdentity.
It seems that this lack of a SigningIdentity in the Info.plist file of the .xcarchive was the root of the problem.
I solved it by going to Keychain Access and setting When using this cerficate: to Use System Defaults on my distribution certificate.
With this in place, the SigningIdentity is set properly when creating an archive, and the generated .ipa successfully launches on my device.
So it turns out this had nothing to do with Fastlane, just the settings on my Build Server.
I didn't figure this out on my own, this post saved me: iOS 12 enterprise apps crash upon launch
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
I am trying to submit an update to the iOS app store. I am going from a Buzztouch app to a Sprite Kit app. I am able to archive the Xcode project and submit it. The app gets to the status of Upload Received but than about a minute later, it changes to Invalid Binary and I get an email saying:
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 these issues have been corrected, go to the Version Details page and click "Ready to Upload Binary." Continue through the submission process until the app status is "Waiting for Upload." You can then deliver the corrected binary.
I have cleaned out the build directory, rebuilt my release target, and made new provisioning profiles multiple times. All of the Code Signing Identities are set to iOS Developer. Code signing and the provisioning profiles have always been a little bit confusing to me, I could have made some obvious mistakes.
I have tried submitting over 50 times! I find this very frustrating because I have emailed Apple and they got back to me but it was just a link to the dev center with code signing information. I have also spent lots of time searching the Internet to find a solution to this and there hasn’t been a good solution that actually works for this problem.
The only thing I can think of is either because I am changing from a Buzztouch app or it is Sprite Kit.
Here is a screenshot of my code signing:
In Apple developer support there are two additional common causes of the Invalid Signature binary rejection reason,
executable files containing special characters (i.e. non-numeric, and non-alpha). To resolve this issue, change the Xcode target’s Product Name build setting from “${TARGET_NAME} to a string containing only alpha/numeric characters. Let me know if this was the cause of the issue (and the problematic characters) because I file bug reports to fix each instance I find here.
Apple Double Files ("double files") that result from copying the Xcode project uncompressed to/from a non HFS+ formatted hard drive. To check if this caused your rejection:
A. Run the app diagnostic here: How do I check if my application's signature has been corrupted?
B. Then check the command line output with: List of Signature Verification Failure Root Causes. Double files are diagnosed with a message like:
resource missing: my.app/._.*
C. From the docs:
The file prefixed with "._" is considered an AppleDouble file and it
can result from copying the uncompressed Xcode project folder onto a
non-HFS+ formatted disk. The AppleDouble files must be removed using
the 'dot_clean' command. The Xcode project folder is the argument to
dot_clean as illustrated below. Note: You can drag your Xcode project
folder from Finder into the Terminal window to automatically fill its
path into the command.
dot_clean /path/to/My_Xcode_Project
(If Terminal can't find the dot_clean utility, download the optional Command Line Tools through Xcode > Preferences > Downloads)
D. After running dot_clean on your Xcode project, create a new app archive (via Xcode > Product > Archive), reattempt submission.
To prevent double files be sure to compress the Xcode project folder to .zip using Finder before transferring it to/from a non HFS+ formatted hard drive.
This is what I did when I encountered a similar problem with the Mac App Store:
Re-generate the app's Distribution and Development certificates (from the Apple Developer's Certificates site).
Download both certificates and drag them to Xcode's icon (not sure whether it had any impact, but after so many submission failures, I was pretty superstitious).
Re-fresh the certificates and identities from Xcode.
Open Xcode's Preferences.
Go to Accounts tab.
Clicked my account
Clicked the refresh button.
Generate the archive.
Submit the app and clicked on "refresh signing identities" somewhere mid-way in wizard prompts.
As a reference, here is my built settings related to signing. That one worked the last time I submitted the app (which has been in the "waiting for review" state for the past two days now, so I guess it passed all of their automated tests).
Your issue relate with signing failed because of your app didn't sign with recent distribution certificate. Check the following steps:
1) Check your bundle identifier to list out provisioning profile as like below picture. Because It also lead to this problem.
2)You may not using the correct certificates when building your app. Just Delete your certificates in Provisioning Portal and create new ones and update them in Xcode.
3) From your picture, you didn't selected correct provisioning profile. Goto Organizer / Provisioning Profiles / Refresh and allow Xcode to fetch the latest ones. see screen shot to how to do that.
Select correct Provisioning profile.
Select correct code sign.
4) Cleaned up your project.
5) Just clean all your targets . You can even go to /Users/%USERNAME%/Library/Developer/Xcode/DerivedData and delete all of the directories in there.
see this ref
Under "Code Signing Identity" Make sure you have selected your Distribution Cert for the "Release" scheme
Under "Provisioning Profile" make sure you select a Distribution provisioning profile (not an Ad Hoc one)
Archive and distribute, make sure the same cert is selected when submitting (after entering your iTunesConnect info)
After doing all of the above
Menu Bar
try Product->Archive
Then from the organise try resigning and submitting.
Window->Organiser
Select archive and then press distribute (but i'm pretty sure you'll know how that works)
Obviously if you can't do this then chances are you have indeed got something wrong with your signing certificates, more specifically your bundle identifier is likely to be the culprit.
One other option is your app uses services that you haven't set up on developer.apple.com/ios for the app id such as game centre, push notification etc. Good luck
check your launch images . Are they conflicting like 2 images have got same name. Because i have got the similar issue which i solved like this within 10 minutes.
To figure out this problem I just created a new Xcode project and copied and pasted everything into the new project.
In my case the problem was to not ASCII chars in filename (someone did sent us to embed), solution was to do a global search in project:
ls -1 -R -i | grep -a "[^A-Za-z0-9_.':# /-]"
And delete those chars from filenames.
I'm setting up a CI machine and the problem I'm facing is that the build fails with a profile/signing error when built using the bot.
However if I manually clone the project onto the CI machine and build it manually from within XCode on the build machine then it is successful - this shows that the CI machine's keychain is correctly set up and the profiles/signing setting of the project are all ok.
That fact that I can manually build it on my dev machine and on the CI machine but not using the bot suggests to me that the bot is running as a different user?
So my question is how do I set up the X Code server account / bot to be the correct user? The Apple Xcode CI document isn't very clear on this area, I've followed the instructions for configuring the server, configuring the bot, adding group members to the XCode server etc. but something must have been incorrectly configured. Trouble is I've followed the documentation step by step but don't know where I could have gone wrong.
Anybody know of a good alternative bot tutorial as an alternative to Apple's documentation or have an idea what the problem might be?
Copy the relevant provisioning profiles from
~/Library/MobileDevice/Provisioning Profiles
to
/Library/Server/Xcode/Data/ProvisioningProfiles
and it'll build fine.
You might need admin permission to access that folder, though.
And if that doesn't work, copy the relevant certificates/private keys from the login keychain to the System keychain.
The reason behind this is because..Xcode only downloads provisioning profiles that are managed by Xcode, which are the Team Provisioning profiles.
So you would only need to copy the ones that are not managed, like Adhoc Distribution profiles, and other custom provisioning profiles that are not created by default after creating a new Application ID.
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"?