I have just finished an iOS app for a client, and have received a copy of their distribution profile (.cer format). I have dragged it into XCode as described in the docs from Apple. Now, I can select that profile for a distribution build, in the build settings for the project, but when I go to the target, I cannot select that profile? Any ideas on how to resolve that?
Also, is this the right way to go to create a distribution build, that the client can submit for approval?
Thanks!
- Lasse
You not only need their iOS Distribution Certificate, but the private key for that certificate as well (a password protected .p12 export from their Keychain will work).
You might want to install the client's certificates in a separate Mac User account as well (which will have its own Keychain), so as not to confuse your Keychain, since yours may already have your own certificates.
You need a copy of your client's signing identity. They can export it as a .p12 file from the keychain manager.
Related
I have some trouble with Xcode11, and anual renew certificates. So I'm lot of lost and have no response about my trouble.
So I add a new question, perhaps more simple:
What happen if I remove ALL trace of certificate, profile, if I clean all. Can it affect my current production app, or can i still update ?
I suspect conflict from lot of certificate test, but no other idea.
Thank you
Let's say you go to the developer center and revoke/delete all certificates and profiles. And on your computer you delete all certificates from your Keychain, and you delete all profiles from the MobileDevice folder.
Then if you have an app on the App Store, it will continue to work; users can still download it. But you will not be able to submit any updates to it and you will not be able to run any projects on a device.
You could then fix that by obtaining new certificates and profiles, which you can probably do automatically; in fact, if you try to run a project on a device, it will likely all happen automatically.
I have an electron app that originally was distributed with a certificate for an individual developer.
I'd like to now sign the next update to that app with a certificate from my organization, but when I do so, existing installations (upon auto update) throw an error that the code requirements aren't met.
Is there a way to properly sign an electron app with both the old and new certificate? I'd like to prevent my existing users from being interrupted.
Any help appreciated!
Thanks
We had a similar situation, with an Electron application for MacOS using auto-update, and we needed to switch to a new certificate without making everyone download and re-install the application manually. The auto-update process needs to recognize the new certificate. Rightfully so, the old version will refuse to update if the new certificate is not recognized.
Our strategy was:
look at the designated requirement (or DR) of the application, when signed with the old certificate, using codesign -d -v -r - <path-to-app>
look at the designated requirement of the application when signed with the new certificate
place the combined designated requirement, that includes both certificates, into an electron-builder-requirements.txt file
make sure that you do not include the identifier in the combined designated requirement string
make a reference to the electron-builder-requirements.txt in the electron-builder.yaml file (add a line under mac: like this requirements: electron-builder-requirements.txt)
publish a new version of the app, signed with the old certificate, but with the DR that contains information about both certificates
wait until nearly everyone has the version running on their desktop that includes mention of both certificates in the DR
update the build so that it uses the new certificate instead, and remove the electron-builder-requirements.txt file
release a new version of the app signed with the new certificate (no requirements file is needed, and it will list only its own cert in the DR)
An older version of the application that has a DR that includes information about both certificates will allow an auto-update to a new version that uses either certificate.
I found this document about signing code manually helpful in understanding the "designated requirement".
Update: here's an example of the electron-builder-requirements.txt file (I've modified some of the letters/numbers for privacy purposes):
designated => certificate leaf = H"2323ce6b0XXXXXXXX39f2064be999999997272b1" or anchor apple generic and certificate 1[field.1.2.840.199995.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.199995.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "6ZXXXXXXUY"
I'm about to update my app that is now in App Store.But when I was preparing my updates development in Xcode, I accidentally revoked my certificates and I regenerate them. After regenerating all of my certificates, I made a ipaFile and I'm now trying to upload it to iTunes connect.But before that, I found that the Development provisioning file was invalid.(not the distribution one)
And I have about three questions with this situation.
•Is it necessary to regenerate my development provisioning files?
•And if I regenerate my development provisioning file, do I have to regenerate my ceritificates again?
•Are there any problems by uploading an ipa file while my development provisioning file is invalid?
Yes,you can generate Proviosing Profile.
Go to Developer Account ->Click on Invalied Proviosing Profile ->Edit ->Certificate select your developer Certificate -> Rename provisiong Profile -> Click on Generate -> Done -> Download
Please Follow Following Steps.
Please don't dismiss this as a duplicate without reading fully - I've scoured the net and stackoverflow and found many questions like this, but none of the fixes work and I'm not sure why.
It doesn't help that the xcode configuration is still offline at the dev center, but I should still be able to do this manually.
I'm preparing an app for submission and the code signing of the Archive isn't working.
Provisioning profile 'Company Distribution' specifies the
Application Identifier 'Company.*' which doesn't match the current
setting '2Cxxxxx3D5.Company.App'
So the issue is that it thinks the provisioning profile doesn't have the prefix of my apple developer ID, and when you look at the code signing options under settings you'd be inclined to agree, it says "Company Distribution for Profile Bundles 'Company.*'"
However, in organiser the profile clearly says '2Cxxxxx3D5.Company.*'. The App ID is right in Organiser but for some reason is then wrong in the code signing dropbox.
So far I have
Deleted all the profiles from my machine
Deleted all the profiles from the ios center
Cleaned the build, emptied the build directories
Restarted my mac
Restarted my iPad
Used the javascript hack to insert the Device IDs into a new provisioning profile, with a new appID, re-downloaded it and re-imported it.
I have exactly the same error with exactly the same symptoms again, I just can't work out why the profile is clearly correct in Organiser but then doesn't seem to translate through to the profile screen.
Can anyone throw any insight my way please? :)
Ahh the joys of codesign -- it has tripped up many developers trying to get build configuration setup. This too is a mismatch between a few different settings in Xcode and potentially your App Store Distribution Profile. There are three places that you have to make sure are set identically to ensure this error clears, each of which is tied to the AppID. I answered a similar question relating to a Development Certificate and Provisioning Profile, however the same set of checks is required for your App Store distribution certificates and provisioning profile:
A valid provisioning profile matching the application's identifier could not be found
That question includes some additional information about where particular settings are located, and the process by which one would go through to go from code to device build. A nearly identical process could be used to setup for App Store Distribution -- replace references from "Development Provisioning Profile" to "App Store Distribution" profile as well as omit those test device configurations that aren't applicable to Distribution builds and you should be good to go.
Should you rather try and debug using what you currently have, then read on:
At the core of code sign is the need for your AppIDs to match up in each of the documents issued by the 'Certificates, Identifiers, and Profiles' tool as well as in the build configuration of your Xcode project. There are a few ways in which you can solve the issue, either changing your provisioning profile and signing settings to match the same AppId, or changing the AppID to match your provisioning profiles. It is important to understand the ramifications of this decisions -- Unless you specifically need shared keychain access and specifically do not need any entitled services (In-App Purchase, Push Notifications, iCloud, Game Center, Newsstand, Data Protection, etc.) the option with the least restrictive results is to change your provisioning profile to match your current AppId.
Quickest (but most restrictive) route to a successful codesign build
Your description of the error certainly confirms the root problem -- You have a Distribution Profile named "Company Distribution" set to an AppID from the Certificates, Identifiers, and Profiles tool that is "Company.", however your App Specifies an AppID of "2Cxxxxx3D5.Company.App" which does not match the AppID that code sign is using. Put a different way, your project is configured to set the Bundle ID to "2Cxxxxx3D5.Company.App" while you are attempting to codesign a bundle "Company.". The "2Cxxxxx2D5." part violates the provisioning profile you (or perhaps the Xcode Automatic Profile Selector) has picked for your archive codesign operation.
The "2Cxxxxx3D5." part of your AppID looks suspiciously like an App ID Prefix -- this should not be specified in the Xcode App ID field (or in the Info.plist where that field's value is derived. Xcode automatically handles the App ID Prefix for you based on the Provisioning Provisioning Profile used to do code sign. If your Xcode App ID contains this prefix value remove it so that your App ID becomes "Company.App". In doing so, your Application's App ID becomes a valid App ID given the "Company.*" Distribution Provisioning profile that the error indicates is being used during code sign.
More sustainable fix -- Fix the AppID and Reissue the Distribution Provisioning Profile
As Apple continues to release 'entitlement' based services, it may not be agreeable to issue this app under the wildcard Provisioning Profile. Instead, the best way to retain the widest flexibility is to issue an explicit AppID for your Company's app, reconfigure Xcode, and reissue the Distribution Profile for that new explicit AppID. The linked answer above serves as a step-by-step guide for how to do each of these tasks except the Distribution Provisioning Profile. At a high level, the tasks to complete are:
Update the App ID in the Xcode project to omit the TeamID / App ID Prefix.
Ensure that the edited App ID is registered with Apple's Certificates, Identifiers, and Profiles tool.
Issue a Distribution Provisioning profile for the new bare-bones App ID
Install to Xcode, restart Xcode, then ensure that the Codesign Settings are using the new Provisioning Profile and Signing Identity.
Run the Archive.
Once you get the App ID matched up to the one encoded in the Distribution Provisioning profile you should be in a much better state to run your Archive. If you run into additional questions or problem, tack a comment on to this answer and we can see what we can do.
The instructions given in the Distribution page on the iOS Provisioning portal clearly still describe the process of creating, and including the Entitlements.plist file in a build for an ad-hoc distribution. The iOS Development Guide's Distributing Applications page, on the other hand, makes no mention of the Entitlements.plist file.
When I tried to "Build and Archive" our latest app following the instructions from the iOS Development Guide, the resulting ad-hoc app.ipa wouldn't install on my development device, due to a problem with the entitlements. When I rebuilt with the Entitlements.plist file, the new app.ipa installed fine.
Unfortunately, including the Entitlements.plist in the app.ipa means that the resulting build can't simply be re-signed and submitted to the app store - Right? Instead, I have to rebuild without the Entitlements.plist and submit the result to the app store.
I guess that I really have a few related questions:
Would the app.ipa produced as directed in the iOS Development Guide (no Entitlements.plist, just sign with the ad-hoc distribution provisioning profile) install OK on a non-dev device that was properly identified in the test distribution provisioning profile?
Is there any way for me to test the exact results of a "Build and Archive" on my dev machine, so that I can just re-sign it and submit it to the App Store from Xcode?
Will an app.ipa that explicitly includes an Entitlements.plist file be rejected if I did submit it?
Thanks!
As of Xcode 4.2 you no longer have to create an Entitlements.plist file when creating applications that do not require any special permissions to run. The get-task-allow entitlement is automatically set to true or false, depending on what kind of provisioning profile you sign your application with (Developer, Ad Hoc, or App Store).
ref:http://help.testflightapp.com/customer/portal/articles/535398-invalid-profile-distribution-build-entitlements-must-have-get-task-allow-set-to-false-
i just tried , no need entitlements for simply ad-hoc , simply using ad-hoc profile to archive and share , then fine .
From the iOS Developer library:
If you're doing an Ad Hoc distribution, you must properly configure your project to include an Entitlements.plist file and uncheck the get-task-allow checkbox (which sets it to False).
http://developer.apple.com/library/ios/#technotes/tn2242/_index.html
There's no issue with leaving the Entitlements.plist file in the Distribution build, I've had several apps submitted with it.
Actually, Entitlements.plist is also for other iOS features that your app may use:
Entitlements. These files define
properties that provide your
application access to iOS features
(such as push notifications) and
secure data (such as the user’s
keychain).
http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/iphone_development/115-Configuring_Applications/configuring_applications.html
Also check this answer:
The executable was signed with invalid entitlements
Get-task-allow is now called "Can be debugged" in Xcode 4.1 if you've used the modernization tool
I don't have answers to all your questions, but I needed to add an Entitlements.plist when I recently used ad hoc distribution for some testing. I think the documentation still talks about the 'get-task-allow' setting in the .plist, but when I followed the instructions exactly I had problems signing the app. Instead, I created an Entitlements.plist using Xcode's template. It has two or three settings, none of which are get-task-allow. I left it exactly as it was when created, and the build succeeded.
My experience in the past has been that apps submitted to the app store with an Entitlements.plist included failed the verification step.