I started to read the Keychain Services Programming Guide and in the Keychain Services Concepts there is a note:
On iPhone, Keychain rights depend on the provisioning profile used to sign your application. Be sure to consistently use the same provisioning profile across different versions of your application.
I don't understand this note... what if for example I need a build for adHoc deployment and I need to later edit the provisioning profile to add more devices? Or if I sometimes build the app for adHoc deployment with its appropriate adHoc provisioning profile, and another times I build it to use TestFlight with its provisioning profile for the App Store?
Thanks
I don't think that's true, I regenerate my provisioning profiles every year and haven't lost keychain access.
What exactly constitutes keychain "identity" is hard to pin down.
QA1726 seems to imply that your keychain access is based on BundleID Prefix/Team ID plus bundle ID. Although bundle IDs are allowed to differ if you use the keychain-access-groups entitlement.
I would also hazard that provisioning profile type now comes into play.
e.g. once upon a time I could read the keychain of the AppStore version of our app from an Ad Hoc version of the app, but not a dev version, but that seemed to stop working around iOS 7.
I hope somebody can contribute some slightly less conjectural information.
it says about the every year the profile expired and updated with new one.this should be same. see here, more here
Related
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".
I am getting an error when archiving:
Code Sign error: No matching provisioning profiles found: None of the valid provisioning profiles allowed the specified entitlements: com.apple.developer.in-app-payments.
I added apple pay capability since the last time I archived successfully, so it's probably to do with that. How do I add the entitlements to the provisioning profile? The whole certificates/provisioning profiles/app id concept is so confusing, wondering if there are any good reads (for dummies) on exactly what/why/how these work.
You need to go to developer.apple.com and log in as your developer account. Go to the Certificates, Identifiers, and Profiles section, and find the app ID for your app. Click on it to expend the capabilities for the app ID. Make sure In App Purchases is enabled for both development and distribution (more info here).
Once you've made sure it is there, you'll want to re-generate the provisioning profile for the app ID, and then re-download the profile to your Mac. I tend to remove all my old provisioning profiles when I do this, since having multiple profiles for the same application ID can sometimes confuse Xcode. Provisioning profiles on your Mac are stored in /Library/MobileDevice/Provisioning Profiles/
After doing this, it isn't necessary, but I usually recommend devs to quit and relaunch Xcode.
As for resources, I think Apple's session, What's New in Code Signing, from WWDC 2016 was a great one for understanding the components that are required for code signing to work.
The whole certificates/provisioning profiles/app id concept is so confusing
Not only for you :). You don't have to add entitlements to your provisioning profiles. Try to go to apple developer website add your mac (if you didn't do it already) and generate new provisioning profile. After that download it and click 2 times (xCode should automatically add it to the project). If it doesnt solve the problem try to look into project structure code and change developer/project numbers manually to proper one.
Suddenly all my provisioning profiles are in status Invalid (managed by XCode). Why?
Also I remember in XCode 4 that you always had to create your provisioning profile. Now XCode autocreates your provisioning profile for development. Is this a new feature on XCode 6?
I had the same problem today.
In the Apple Developer website, all of my company's Provisioning Profiles were marked as "Invalid (managed in Xcode)". None were out of them were date, none were using iOS Certificates which had expired, and the website gave zero suggestion that anything was actually wrong.
The solution, ridiculously, was to delete my perfectly valid iOS Certificates, and recreate them.
We write in-house apps aswell as apps for the App Store, and Apple (quietly) refuses to let you have more than 2 of these at once. So I was unable to create a third iOS Certificate which would allow me to use the "In house and Ad-hoc" option, hence the need to delete an iOS Certificate first.
Once I had pointlessly recreated the "iOS Certificate", the Provisioning Profiles came to life.
Part 2 of this farce is to go into Xcode, and delete your Provision Profiles (XCode \ Preferences \ select your iOS Certificate \ View Details, then select all of your provisioning profiles, right click and select "Move to trash".
At this point, absolutely nothing will change, and you'll think you've done something wrong.
But then, if you then quit Xcode, and go back in, then you'll see the Provisioning Profiles will have disappeared.
Now you can re-download the Provisioning Profiles from the Apple Developers website, and redownload the latest versions.
Until Xcode 7.2 comes along, and breaks something else.
(Seriously, I spend more time fighting with Xcode bugs than writing code..)
Apple introduced Xcode Managed profiles in Xcode 5 as a way to try and make the provisioning process less cumbersome and get Developers sending code to their devices without having to go through the manual upload/setup/download/install/build process. In effect, Xcode was completely automating the entire provisioning process whenever there was a code sign error detected. For developers that had already wrestled with understanding Provisioning, this new behavior was frustrating as the processes those teams put in place were unintentionally being wrecked by Xcode's best attempts to be helpful. That said, it is better today but not as transparent as it should be when it comes to affecting your Certificates, Identities, and Profiles data. If you are't familiar with what all is included in a provisioning profile or signing identity, there's some related reading you might want to skim: What are code signing identities?
Suddenly all my provisioning profiles are in status Invalid (managed by XCode). Why?
The most common reason for a profile to move to the "Invalid" state is because at least one of the profile's registered test devices has been deactivated / removed from the developer's account. By doing so, all profiles that included that device UDID are marked as invalid and require regeneration. This can be accomplished in Xcode > Preferences > Accounts, clicking 'View Details' on your Apple ID account, and then clicking the refresh button in the lower right corner of that account details screen.
Also I remember in XCode 4 that you always had to create your provisioning profile. Now XCode autocreates your provisioning profile for development. Is this a new feature on XCode 6?
As stated in the start of this answer, no. Autogenerated provisioning profiles were introduced in Xcode 5 and the workflow has been refined several times since Xcode 5.0 and modern Xcode. If you allow Xcode to assist you with Code Signing error messages, its default position is to check the validity of your development or distribution certificate (depending on what kind of code sign operation you were trying to do), check the validity of the AppId and Provisioning Profile, and revoke then reissue whichever part of the signing identity is in error.
Really it messing up on me. it destroyed my 4 hours fighting with Xcode. At last created another new provisioning file with selecting appleID as iOS Wildcard App ID (xxx.*)
I have a strange issue.
I have a distribution certificate for my app in my developer portal with two App IDs (one wildcard and one explicit) and I've had to adjust the app ID to include the iCloud entitlements because I'm working on an update (iOS 7 only) with iCloud support.
I'm now ready to distribute and so I created a new provisioning profile in the developer portal with that certificate. As soon as it's added to Xcode, it shows up as "invalid" in the Developer Portal.
If I archive and validate my app before the app distribution in Xcode, and use my Apple ID and this provisioning profile, it says "it passed without any errors".
I'm extremely nervous about uploading this to Apple because it doesn't make sense to me.
The other provisioning profiles I have in the developer portal are the iOS Team Provisioning Profile (managed by Xcode).
I've got the entitlements in Xcode and my app works in development with iCloud, but I really want to distribute this.
If I add in more distribution profiles, as soon as it's added to Xcode, it shows up as invalid in the developer portal member centre. That's with using the explicit App ID. If I create one using the wildcard ID, it remains active, but I've read on the Apple documentation that for iCloud, you have to use an explicit App ID.
I have managed to solve this, thankfully.
I contacted the Apple Developer Support team by phone with this (without having to create a new support request and have that take a while) and was sent the following link:
https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/MaintainingCertificates/MaintainingCertificates.html#//apple_ref/doc/uid/TP40012582-CH31-SW34
The specific header is "Re-Creating Certificates and Updating Related Provisioning Profiles”,
basically went through and revoked all of my certificates in the portal and removed the certificate and private key in the keychain access. From there, I removed all of my provisioning profiles as well.
Within Xcode on the accounts section, I got a popup asking if the development and distribution certificates should be generated. I said YES and it did it. In the developer portal, I now had two certificates. I created a developer profile and tested my app; it worked. I then created a distribution certificate and added it to Xcode. After refreshing the portal, it still showed active. I archived and validated my app, with no issues and then uploaded. The new distribution profile is still active.
This was great and I'm happy to have this resolved.
I am a bit lost in all the certificates/provisioning profiles.
When I am doing ad-hoc distribution by first doing "archive" and then "distribute" in XCode and chose then my ad-hoc distribution profile, does it matter at all what I have set up in the Project->Target->Build Settings->Code Signing?
On one hand I read in different places that when you archive a build, you can (and really should) use that same archive both for beta testing with ad-hoc and then when ready just sign/distribute the same archive with an appstore profile and upload to app store. That kind of makes sense. It also tells me that I can really leave blank the provisioning profile in the project settings, the one that is chosen during "distribute" action is actually used, and the signing identity is actually the private key associated with the distribution certificate listed in that provisioning profile. Right?
On the other hand, testflight instructions (http://help.testflightapp.com/customer/portal/articles/1333914) clearly state that project settings should be set to use Ad-hoc profile as well, and the same profile must be used in the project settings and in "distribute". That means that I can not use the same archive both for ad-hoc and app-store distribution, can I? Do I need to change project settings every time I want to release for this or that distribution?
Also, if project settings are making any differences in archive/distribute scenario, it is not clear what Code Signing Identity should be used there. Testflight screenshots show iOS Developer is set both for debug and release, yet neither ad-hoc nor app store distribution have the individual iOS developer certificate associated with them, distribution profiles usually are associated with one and one only distribution certificate.
Can someone please shed some light and explain how is it actually supposed to be working?
Thanks
Yes, your build settings matter. Xcode picks up various entitlements from your initial code signing/provisioning profile configuration and it only makes minimal changes to them in the Distribute... phase.
So if Xcode chooses the incorrect profile during the Archive step you can end up with incorrect bundle seed ID, keychain groups, APN environment and iCloud entitlements.
The Distribute... button calls the PackageApplication script, which makes sure that get-task-allow is false (debuggers can't connect), embeds a provisioning profile, then re-signs and zips your app (although I may have the order wrong).
PackageApplication is worth reading. One could fault it for not being very smart, but I think it should be stricter and refuse to package an app whose entitlements differ from the provisioning profile it is using.
You can find it here Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/PackageApplication
I think one stable workflow for distributing Ad Hoc builds is
remove all wildcard provisioning profiles from your system
select your App Store profile in Release Configuration (used in Archive phase)
in Distribute select your Ad Hoc profile
The reason for 1. is that wildcard profiles (profiles that match multiple BundleIDs, created either manually by you or automatically by Xcode) are not worth the trouble. Yes, they get you running code on a device quicker, but you soon have to abandon them if you want to use push notifications or any other interesting service and then they hang around on your system and sooner or later Xcode will silently pick one of them and sabotage your App Store submission.
As for point 2. (selecting the App Store provisioning profile), I'm a little hesitant of specifying profile in the project, but the App Store one only needs to change once a year when your certificate expires (unless you edit the App Identifier in the Certificates, Identifiers & Profiles portal, then you'll need to regenerate your profile & re-select it in your project settings).
Since the Ad Hoc and App Store profiles are based on the same App Identifier, their entitlements will always be in sync.
Point 2. should make point 1. unnecessary, but wildcard profiles will also happily screw up your dev builds too, so why give them the chance to stab you in the back?
Point 3. - you can change your Ad Hoc profile as much as you like - just remember to select the right one in Distribute; the entitlements are taken from the App Store profile which should change rarely. There's nothing stopping you distributing to the App Store from here. That's perfectly natural.
p.s. I don't know why TestFlight recommend selecting Ad Hoc in release instead of App Store.