I am never very clear regarding to which Code Signing Identity I should use in the Build Configuration concerning which scenario, and would love if someone can explain it in the most simple way.
This is what I know:
I create in the Provisioning Portal and implement in my apps both a Development Profile and a Distribution Profile.
Then I assign the Project >> Build Settings >> Code Signing according to the different profiles:
Here is the first question: What is the difference between Release and Distribution? Which one should be connected to the Developer profile and which one should be connected to the Distribution profile?
Now, if I understand correctly, I'm supposed to set the "Scheme" before I run the app:
There are 5 different steps in which I'm required to define the Build Configuration by selecting one of the Code Signing Identity:
Here is the BIG QUESTION... In which scenario I should select which Code Signing Identity?
I always run the app on the same 2 devices: my iPhone and my iPad; both are defined in the Provisioning Portal and set into the profiles.
I only want to make sure I run it OK for testing on Simulator and on Device and later on to build the app for uploading to App Store.
Any assistance / direction will be much appreciated.
By default, the standard Apple templates only create Debug and Release configurations. Distribution seems to be redundant with Release.
Debug is the configuration used when you are actually working on the code, and Release is used when you archive it for other people to install. You should use your developer profile for Debug and your distribution profile for Release.
You should also probably use your distribution profile for distribution, but you should really check with whoever created that configuration to see what its purpose is first.
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".
while i am trying to build my project its giving me this error,i am using xcode 7 :
what i was tried:
Deleted the development and distribution certificated and then i have create it again.
about xcode ->preference->account->viewdetails ,in xcode 7 there is no refresh button is there.
Debug-iphoneos/Demofb.app: User canceled the operation.
Command /usr/bin/codesign failed with exit code 1
in simulator its running.
but i don't know where problem is from keychainaccess or from the xcode.
Please anybody help me to solve this problem ,i am struggle here for more then half day.
I surfed a bit and found the following things. Hope it helps you some way.
While choosing a signing identity, you have the choice of submitting your Mac app to the store, signing it with a Developer ID certificate to distribute it outside of the store, or not code signing it at all. If you select Mac App Store, you assign your Xcode project to a team and can enable app services, as described in Adding Capabilities. If you select Developer ID, you assign your Xcode project to a team but the available capabilities are limited (read Distributing Apps Outside the Mac App Store for how to create a Developer ID-signed app)
Xcode detects when you’re missing a signing identity. Typically, this happens when you move from one Mac to another or recreating the certificates and provision profiles. Click here to know more on provision profiles, but I am not sure this might not be your issue.
If you use the team provisioning profile that Xcode manages for you during development, as described in Team Provisioning Profiles in Depth, Xcode fixes code signing and provisioning issues for you before you attempt to build your app. In this case, you shouldn’t set the Code Signing Identity build settings yourself. However, if you want to use a custom development provisioning profile and set these build settings, as described in Using Custom Provisioning Profiles, you may encounter build issues described in this section. Common build errors tend to involve incorrect code signing identities.
Every time when i deal with code signing and provisioning profiles strange things happens. Most times i get the error "no code signing identity found" and if not then something like "no matching provisioning profiles found" and "no provisioning profiles with a valid signing identity".
Although i am quiet familiar with the theory and the things behind code signing and provisioning, there are still lots of pitfalls I everytime ran into and i don't know how to deal with. Sometimes it fails when setting up a new App, sometimes not.
There are 5*2 different ways to select code signing identity. What is the difference between them? And if i select one for debug and one for release, what is the reason for the "Any iOS SDK"?
Also, there are two places giving this dialog: Project-Settings -> Buildsettings is the first place, and also for the Target under Build Settings. Both are not in sync, so if i change the code signing at the first place, i have to change it twice in the second place. Is there a way to keep them in sync?
Which code signing identity would fit best into the various lines (debug, debug -> any ios sdk, release, release -> any ios sdk), since i can choose between developer identities and distribution identities (i could imagine, that the distribution one is for release and the developer one is for debug, but because of everything fails, i don't know.
What I did:
There a valid certificates in the Member Center deposited for each developer of our team and one for ad hoc distribution for the Team.
We also created AppIDs which reflects exactly the same setting in the Project Settings. In between we avoid using Variables and use the exactly appid also in project-settings to reduce risks on this side and to simplify things.
When switching the provisioning profile from "Automatic" to a specific Profile for this App, the code signing identities change to different values, which are also not in sync between the project settings and target build settings:
On the Target->Build Settings we get this result:
On the Project -> Build Settings we get a different result:
Which one would be more accurate?
After "Product" -> "Archive" -> "Validate" we get the following error:
It doesnt matter here if we select different Code signing identities or not. Actually, just for playing 'trail-and-error', we tried out nearly every multiple combinations of code signing identities to learn what XCode would do then.
After this error message from Archive->Validate the previous selected provisioning profile is replaced with another one named by a randomly generated string:
Who can tell me what happens here and how to solve these issues?
I've read a lot of documents regarding this topic. But most tutorials around this topic are outdated since several changes happened between XCode 4 and XCode 6. Even the apple documents offer mostly screenshots based on outdated XCode versions and also outdated versions of Member Developer Center.
Update
As Ian McDonald pointed out correctly, the last question (covered by the last 2 screenshots) is answered. After recreating the Provisioning Profile it won't be replaced by randomly generated strings, but the IPA-creation is still not working with "no code signing identities found".
What it looks like now:
you have a long question , but If you face problem with archive or publish your app there are some steps you should follow
First code signing
If you build your app with Debug , then debug must sign with iPhone developer --> general if you use many or specific one "depend of certificate you have in your key-chain "
but If you build your app with release then you should you certification iPhone distribution ---> general or specific one
Second Provisioning Profile
If you build with Debug then the provision profile Debug should match match your bundle detail and be development
release be distribution one that you create on developer apple site
I hope this help you have a look at this also please
From what I'm reading you have changed your provisioning profile in your target from "xxx.xxx" to "xxx.xxxTests" which is in fact a different bundle identifier making the error valid. You really have two courses of action:
Change your bundle identifier back to just "xxx.xxx". This is the appropriate path of least resistance.
Create a new bundle identifier in the portal as "xxx.xxxTests" as well as a new provisioning profile for "xxx.xxxTests" tied to the same certificate. With XCode closed drag the new provisioning profile onto your XCode app icon then open your project.
You shouldn't have to change your bundle identifier to conduct testing. When you go to deploy you will only have to change which provisioning profile your target is compiling with (development vs distribution).
EDIT:
I have some more tips on provisioning profiles here: How to become familiar with code signing issues?
The quick and dirty side of provisioning works like this:
When you are added to the Apple Provisioning Portal your cert is the keys to the castle. Any code you compile has to be associated with your cert or you won't be able to properly compile/export your code.
Your bundle identifier is essentially the way iOS identifies your application. Conceptually speaking if you want to install your app multiple times on the same device create multiple bundle identifiers.
Your provisioning profile ties all of the pieces together. The prov profile tells XCode that you plan on using your cert to compile your app identified by your bundle identifier. If it's a development build it will only the devices specifically assigned to the prov profile in the portal will be able to install your app.
Within XCode you need to make sure your target bundle identifier matches what bundle identifier is in the provisioning profile. Likewise make sure your code signing identity matches the cert you setup in the portal and tied to the provisioning profile. Lastly select the appropriate provisioning profile from the drop down list below the code signing identity.
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.
I have read the Apple documentation, and many postings on the subject on SO, along with various tutorials, and yet I have to admit I don't 100% understand what profiles to use when and how, and usually resort to trial and error until I find a combination that works.
However at the moment I'm in the situation that an ad-hoc app (that used to install) via iTunes now no longer does either on my phone or on tester's phones, though it will install using XCode. The error message on the phone is juts "ZZZ failed to install.".
I have the following profiles installed in XCode:
1) Ad-hoc distribution profile
2) Team provisioning profile
3) Development profile
4) Apple Push Profile
Some questions:
1) Which profile should I use in the Code Signing Identity section of the Target Build Settings and why?
2) Which profile should I use when distributing an Ad-Hoc Deployment?
I would assume for 2) it should be the Ad-hoc distribution profile? If not what/when should that profile be used?
If the Ad-Hoc distribution profile is used in step 2) then I guess I have to use the Apple Push Profile in step 1)? Otherwise how can I receive APNs?
When then should I be using the other profiles?
A few follow up questions:
3) In what circumstances would or should you set a different code signing identity in the Project to the Target?
4) By default there are 5 sections in the Code Signing Identity (Code Signing Identity, Debug, Debug Any iOS SDK, Release, Release Any iOS SDK). In general should these all be the same? Under what circumstances would or should they be different?
5) What is the Code Signing Entitlements section used for?
I've been working with iOS development for quite a while, and would consider myself advanced in many areas, but this one just does my head in.
Many thanks if somebody can demystify this.
1) Development profile, must be generated after APNS profile. You don't sign bundles with APNS certificate, it is for server. But in you development and ad-hoc profile will be part with info about Push Notifications, so you need to re-creare dev and ad-hoc profiles after changes in APNS settings in provisioning portal. For proper usage of APNS you should read additional materials, like that or any other. If app has no APNS, you can use team provisioning profile with your developer name for debugging as well.
2) Yep, Ad-hoc.
3) If you have more then one target in the project
4) I used development profile as "Debug" (same in "Debug Any iOS SDK") and ad-Hoc profile as "Release" (same in "Release Any iOS SDK)".
Welcome to crazy world of app signing!