Bitrise "deploy to itunesconnect" step failing despite having profiles and certificates - ios

Context
I've been using Bitrise to deploy one single app on both Android and iOS.
It's always been working fine, knowing that the initial configuration had been done by a coworker who doesn't work with us anymore. I've mostly been maintaining the workflow and changing expired certificates/provisioning profiles so I don't know the initial configuration details.
Problem
Recently we decided to split our app in two different apps from different repositories, so I needed to create a new Bitrise app.
Here’s what I’ve done:
Created a new app on Bitrise based on our new repo
Added the exact same steps that were in the other app
Added all the same env variables
Connected to Apple via Apple ID, tested the connection via the button on Bitrise (which was successful)
Deleted all the old profiles on my Mac, archived the new app from XCode (v.13.4.1) and ran the Bitrise scripts that uploads the certificates and profiles (app-store and development) on the platform.
My certificates were successfully added to the project in the Code Signing tab.
However, when building, the step « deploy to itunesconnect » systematically fails with the following error:
"Invalid Provisioning Profile. The provisioning profile included in the bundle xxx is invalid. [Missing code-signing certificate]. A Distribution Provisioning profile should be used when submitting apps to the App Store. For more information, visit the iOS Developer Portal
I find it weird because the « Certificate and profile installer » step is successful. I’ve tried several things suggested on forums (including stack overflow), for example adding the certificate on Bitrise directly downloaded from Apple connect (no Bitrise script), or creating a new certificate directly on Xcode, but nothing worked. People who had this error seemed to have issues on how their certificates themselves, but I'm wondering if I didn't do something wrong even before.
At this point I am a bit stuck. Anyone have an idea on what I could be doing wrong?

Related

Appcenter iOS install error "this app cannot be installed because its integrity could not be verified"

I see that this question has been asked many times but I see no solution that works for me so I'm hoping that providing more info might shed some light.
We use appcenter.ms to test iOS apps. Until our iOS certificate expired this method worked fine. We generated a new enterprise certificate and ad hoc provisioning profile for new releases of the iOS app. Which led to the first curiosity.
I see how to upload a certificate on appcenter.ms but not a provisioning profile. I thought there was an option to do this in the past but perhaps I am mistaken. However, the app is signed with a provisioning profile before upload, so perhaps this is not needed now.
Once the app is uploaded, it can't be installed. It remains grey and when you tap it, you get the "this app cannot be installed because its integrity could not be verified" error. Again, that the .ipa is created with an ad hoc certificate and profile in Xamarin (VS for Mac).
Also, I can't install the provisioning profile on a device from appcenter.ms. You basically get stuck in a loop where you seem to successfully install the profile but have to keep doing it because it never actually installs.
I hope this is enough info for some insight and thanks in advance for any feedback.
We were able to solve this by redoing and downloading development certs and via
And also downloading and double clicking the apple development certificate here
After that our keychain showed both as trusted and we could build to the iPhone again.
The issue can be the your device is simply not registered on the developer portal and/or that ad-hoc provisioning profiles have not been regenerated.
You need to register your device, regenerate a provisioning profile with this device in it and rebuild your app using this profile.
This can also happen because of
Developer ID Notary Service - Outage
which can be checked on https://developer.apple.com/system-status/
Notarization is well explained here:
Notarization gives users more confidence that the Developer ID-signed
software you distribute has been checked by Apple for malicious
components. Notarization is not App Review. The Apple notary service
is an automated system that scans your software for malicious content,
checks for code-signing issues, and returns the results to you
quickly. If there are no issues, the notary service generates a ticket
for you to staple to your software.
Work around fix:
Select your app.
Navigate to TextFlight tab
Create External Testing group
Add one tester
Add build which you want to download using TestFlight
Open TestFlight and download an app.
In my case this was caused by trying to include an entitlement for aps-environment "development" when using an Ad-Hoc provisioning profile. The value for this environment in Entitlements.plist must match what is hard coded into the provisioning profile file - if you open an Ad-Hoc profile in a text editor you will see it expects the "production" environment.
The possible solutions depending on your requirements are to either use the Development profile/certificate, or change the aps-environment to "production" to continue using an Ad-Hoc provisioning profile.
It can also happen if you have other incorrect entitlements - worth checking what entitlements are enabled under the Identifier in Apple Developer portal and removing unnecessary ones.
I had this issue because when building the app on xCode for distribution (Product->Archive then Distribute App), I chose automatic signing. After manually signing the app and choosing my own generated certificate and profile, everything worked again fine.
I removed the Entitlements file from the Addition Resources in iOS Bundle Signing and it worked.
I think the MSAL configuration was set to debug in entitlements.plist
I have also face this issue before but for me the reason was little different
First the build was enterprise one and the build was made on the earlier Xcode version on which the iOS version you are using on the device was not supported by the Xcode.
All I did was to update my Xcode and make a new build and shared the build. After that we were able to install that build over device Hope it works for you as well
This is how I solved for myself.
In you iPhone Settings > General > VPN & Device Management you should see your company name (if an app from it is installed), and if you click on it, you will see a button like "Verify" above the list of apps installed provided by the company. Just click on "Verify".

Xcode validation failure

Validation of an archive for uploading to the store is failing in the Xcode Organizer with this message: "Failed to locate or generate matching signing assets: Xcode attempted to locate or generate matching signing assets and failed to do so because of the following issues. Permissions failure - Your account does not have permission to create profiles."
This problem has been reported by several other people on StackOverflow and Apple Development Forums, with no resolution. Here I'll explain some things I've tried with the hopes that maybe someone can suggest a solution. This is a really important problem because it's preventing release of an app.
Does anyone know how to fix this? Does anyone know what the "permission to create profiles" is referring to? From my understanding, the Organizer should just be signing the app with an existing Provisioning Profile, not creating any new ones.
Background information: I have admin privileges in a company team and am able to build the project fine. My development certificate works ok for installing to a phone. There are no expired certificates in my Keychain and the certificates in the key chain look ok. I have rebuilt the Distribution certificate and downloaded it to my Mac successfully.
The problem occurs whether I select manual or automatic provisioning in Project Settings (though this shouldn’t affect archive validation anyway). I have the original distribution Certificate on my machine from importing a .p12 file from the original developers. I’ve tried rebooting my Mac, restarting Xcode.
Issues I can think of looking at next: (1) I am using a wildcard in the app bundle name in the Distribution Provisioning Profile. Is there any problem with this? The wildcard seems to match the app bundle ID in the build. The app has previously been released without an explicit app bundle name in the provisioning profile. (2) The distribution provisioning profile has no services enabled. The app Project Settings include one service: Remote Services under Background Modes. Is there a problem because of this mismatch? (3) Should I try using Application Loader instead of the Xcode Organizer?
The problem, it turns out, was a bad Distribution Certificate. The team I was working for turned out to have two Apple Developer accounts with the same name, but one was an Enterprise account and the other was not. I had been given the Distribution Cert for the Enterprise account. Once I deleted all my relevant certificates from my keychain and XCode Preferences/Accounts and read in the .p12 file for the correct Distribution Cert, everything worked.

Missing code sign certificate when trying to deploy app to new TestFlight

We've been developing an app based on Appcelerator Titanium the last couple of months and to deploy the app to our testers, we've used TestFlight. Now, Apple have shut down the "old" TestFlight and integrated it into ItunesConnect.
Now we want to deploy an update to our testers. So we created a new app within Itunes Connect with the same app bundle as the app bundle the provisioning profile we're building the app with are using. We build an IPA file which we try to deploy using Apples tool "Application Loader".
When we try to deploy the app, we get the following error:
ERROR ITMS-90161: "Invalid Provisioning Profile. The provisioning profile included in the bundle nu.kodfabriken.ourapp [Payload/OurApp.app]" is invalid. [Missing code-signing certificate.] For more information, visit the iOS Developer Portal"
Some Googling and trial-and-error told us to recreate our certificates and provisioning profiles. So we did, and got the same result. We don't know what to do here. Feels like we are stuck, with no clue what to do.
Worth noting is that when Apple switched to "new TestFlight" we didn't change anything at first. We used the very same provisioning profiles as we used with old TestFlight, which worked.
What are we doing wrong? Is this somehow related to how Titanium packages the apps (as far as I know, it's actually Xcode which creates the final build)?

Testflight complains about developer certificate being used to sign the app

Suddenly I started getting this from Testflight when uploading a new build of an app:
This build is signed with a Developer certificate, it can only be installed by devices with the Developer feature enabled. We recommend signing with a distribution provisioning profile for best results.
And my users have problems installing the app. I've gone over the project settings again and again, but everything looks right.
I've set the team provisioning profile to be the provisioning profile for both debug and release, I've even changed to a different team, but still the same problem.
Am I looking in the wrong place here?
I just came across this exact same issue. It looks like TestFlight have added a new check and are flagging developer provisioning profiles when they didn't in the past. Take a read of this (posted yesterday):
Testflight article
I've just uploaded a build to test flight using my normal approach to signing (with a developer certificate), ignored the testflight message, and distributed to my test users. Seemed to work OK.

UIAutomation not working with Distribution type of IPA

I am trying to automate the app using UIAutomation. It works only with IPA built with development provisioning profile. It stucks in case of IPA built with distribution provisioning profile whether it is adhoc or app store distribution. It just launches app and then Instruments hang up with recording page and doesn't record any steps. But it is working fine in case of development provisioning profile. I have read this note from Instruments User Guide provided by apple
Note: For your protection, the Automation instrument enables you to process only apps that have been code signed with your provisioning profile. These apps include any copy that has been downloaded from the iTunes App Store.
Link for this Guide - http://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/UsingtheAutomationInstrument/UsingtheAutomationInstrument.html
According to this guide, I can automate the app also that has been downloaded from app store also if I have signed it with my provisioning profile. I have all provisioning profiles and certificates of my app but still not able to automate the app.
I have tried all things but it is not working whether there is mistake in documentation or I am doing something wrong..
If you look at the note on the page OP linked to, it says:
Note: The Automation instrument only works with apps that have been code signed with a development provisioning profile. Apps signed with a distribution provisioning profile can not be automated with the UI Automation programming interface.
You can only test on Apps that are code signed with a development profile. Once an app is signed for distribution, it can only be used by the App Store, as noted here.
I've been dealing with a similar problem as of late.
We have Jenkins build our ipas, and the usual workflow is to copy them to my machine and run the UI automation.
All had been working for me just fine. However, we changed provisioning profiles recently.
I verified that my UDIDs were on this provisioning profile, and that I had copied this latest and greatest provisioning profile both to my device and my computer.
When I start the UI Automation now (just like the above user) app is launched, no steps are recorded. Adding a -v for verbosity didn't seem to help either.
When I build locally from our latest trunk (same code), then archive to an ipa, UI automation runs fine.
It looks like the ipa from our Jenkins server is not matching up with what I have. However, talking to development, all looks like things should be working.
There must be something else I'm missing here.

Resources