Comment puis-je produire une version iOS Release que mon client peut signer de son côté?
Mon scénario
J'ai écrit une application iOS pour un client. Le projet est presque terminé et il est maintenant temps pour eux de le mettre sur l'App Store. Je leur ai envoyé des builds de développement tout au long du processus de développement. Ces builds avaient un identifiant de bundle basé sur mon entreprise et le projet de mon client comme ceci: com.mycompany.clientname.projectname. J'ai signé ces versions ad hoc avec un profil d'approvisionnement de distribution ad hoc que j'ai créé dans mon propre compte de portail d'approvisionnement.
Maintenant qu'il est temps d'aller sur l'App Store, je dois faire une version Release et l'envoyer pour qu'ils se connectent avec leur propre profil d'approvisionnement de distribution App Store. Cela implique également de définir un nouvel ID de bundle pour le projet.
Mon problème
J'ai besoin d'obtenir une application compilée pour le client afin qu'il signe avec son profil d'approvisionnement. Cependant, je dois définir l'ID de l'ensemble sur ce qu'ils vont utiliser en premier. Disons que c'est com.bestclientever.appname. Xcode 4 ne me permet pas d'archiver le projet maintenant car cela nécessite la signature de code. Je ne peux pas coder le signer car je ne peux pas créer un profil d'approvisionnement avec le même ID de bundle que celui qu'ils ont configuré dans leur portail d'approvisionnement (le portail d'approvisionnement applique l'unicité — comme il se doit).
Ai-je fait des suppositions incorrectes ou des malentendus ici? c'est à dire. Dois-je vraiment définir l'ID du bundle avec quoi ils vont signer?
La question
Existe-t-il un moyen d'archiver ou de créer une application iOS sans le signer? Comme un paramètre "signer plus tard" ou quelque chose?
Ou, existe-t-il un moyen de créer l'application avec un ID de bundle, mais quelqu'un d'autre peut ensuite le signer avec un profil d'approvisionnement pour un autre ID de bundle (soit en changeant l'ID de bundle de l'application compilée, soit par une autre méthode de signature)?
Comment puis-je créer la version finale de la version mais demander à quelqu'un d'autre de signer l'application pour la distribution sur l'App Store?
Ce que j'ai essayé ou exploré
- Agir pour le client.
- Avec d'autres clients moins avertis, j'ai fini par obtenir leurs informations d'identification de portail de provisionnement et iTunesConnect et je fais juste la version finale en leur qualité. Cela ne volera pas avec ce client. C'est une grande entreprise avec des directives de sécurité strictes et beaucoup de paperasserie.
- Usurpation d'identité en tant que client.
- Ceci est similaire à celui ci-dessus et ne fonctionnera pas pour les mêmes raisons. Cela semble vraiment louche de demander à mon client "pouvez-vous exporter vos clés privées et me les envoyer"? Cette technique est décrite dans cette réponse: Comment puis-je envoyer une application iOS au client, pour qu'il signe le code
- Envoyer au client le code source de mon projet et le laisser faire la compilation de la version.
- Une licence pour le code source n'était pas dans notre accord. De plus, ce client ne veut pas s'impliquer avec le code source (donc l'externaliser). Je considérerais cela comme une option de dernier recours, mais il doit y avoir un meilleur moyen!
- Configuration en tant que développeur de niveau administrateur dans leur Centre des membres développeurs.
- Malheureusement, seul l'utilisateur au niveau de l'agent peut créer un profil d'approvisionnement (pour autant que je sache). Il semble qu'il devrait y avoir un moyen de me laisser créer un profil que je peux utiliser pour signer la génération ou de générer un profil pour moi. Je ne trouve aucune option.
La plupart de ces réponses semblent compliquées et dépassées. Je pense que la réponse simple est de créer une archive avec un profil de développeur .
Il s'agit d'une solution que j'étudie actuellement pour mes propres fins (non entièrement testée):
Vous avez juste besoin d'un accès développeur (et non d'un agent d'équipe) à leur compte et créez un profil d'approvisionnement de développement qui vous autorise à créer l'ID d'application spécifié (vous devez spécifier l'ID d'application, car il est compilé). Archivez ensuite l'application avec le profil de développement et partagez l'archive avec votre client. Ils peuvent ensuite signer à nouveau l'archive avec leur propre profil de distribution.
Une complication est que lorsque vous créez une archive avec un profil de développeur, l'attribut de droit get-task-allow est défini sur true, mais doit être défini sur false pour la distribution, vous devez donc contourner cela en le définissant manuellement vos droits .plist - voir ma question ici: Puis-je archiver avec un certificat de développeur, puis le re-signer lors de la soumission avec un certificat de distribution?
Je viens de confirmer à la WWDC 2012 que la technique suivante fonctionne. Il répond le mieux à mes contraintes de faible implication des clients, de faible expertise client, de processus de signature simple et de propriété du code source.
- Le client invite le développeur à son équipe dans le Centre des membres en tant que Admin
- Le développeur accepte l'invitation (devrait figurer dans votre e-mail)
- Le développeur ouvre l'organisateur de Xcode -> onglet Périphériques -> Profils de provisioning et frappe Actualiser dans le coin inférieur droit. Assurez-vous de choisir la bonne équipe et vous devriez obtenir quelques nouveaux articles.
- Dans Xcode, laissez les paramètres d'identité de signature de code à leurs valeurs par défaut (ou réinitialisez-les sur iPhone Developer pour tout SDK iOS)
- Archiver l'application
- Dans l'Organiseur, cliquez avec le bouton droit sur l'archive et sélectionnez Afficher dans le Finder
- Envoyez le fichier .xcarchive à votre client
- Le client doit avoir installé Xcode
- Le client double-clique sur le fichier .xcarchive qui devrait l'ouvrir dans l'Organiseur
- Le client clique sur Distribuer et signe l'application avec son identité
- Profit
Cela nécessite que le client utilise le Member Center sur developer.Apple.com et utilise un peu Xcode (mais juste l'Organisateur!). Si votre client a des problèmes de capacité technique à ce niveau, je recommande simplement de prendre le relais et de le faire pour lui (et de le facturer!). Demandez leur identifiant et mot de passe développeur et agissez simplement en leur nom comme si vous étiez un employé.
Remarque: les échanges de clés sont un terrible compromis car ils sont plus techniques et impliqués pour le client et plus hacky et risqué pour le développeur. Il devrait être considéré comme une non-option étant donné ces deux meilleures options.
J'ai eu le même problème. C'est ainsi que je l'ai finalement résolu:
- Le client a créé un certificat de développement .
- Le client a créé un fichier de développement utilisant le même ID d'application que le fichier de distribution.
- Certificat de développement exporté par le client (.p12).
- Le client m'a envoyé le fichier .p12 et le fichier de provisioning mobile de développement.
- J'ai importé le fichier clients p12 dans mon trousseau
- J'ai importé le fichier d'approvisionnement du client dans Xcode.
- Définissez l'identité de signature de code pour ma configuration de génération afin d'utiliser le fichier d'approvisionnement du client.
- J'ai archivé l'application.
- J'ai envoyé l'archive au client.
- Le client a créé sa version de distribution en signant l'application avec son fichier de provisionnement . (Ils distribuaient l'application en interne pour les tests.)
Le client n'était pas tellement préoccupé par le partage d'un certificat de développement qu'il partagerait son certificat de distribution.
J'ai aussi dû créer entitlements.plist avec "Peut être débogué" (get-task-allow) défini sur NO, et référencez-le dans la configuration de génération (sous Signature de code, Droits de signature de code).
Je crois avoir trouvé un moyen de faire exactement ce que vous voulez, je n'ai pas fait de tests approfondis ni essayé de télécharger sur l'App Store, mais d'après les tests que j'ai faits, cela semble être bon. La démission et l'ajout de mon profil d'approvisionnement fonctionnent car je peux l'installer sur mes appareils définis dans le profil AdHoc sans aucune installation manuelle de profil requise. Le deuxième test était que j'ai obtenu un iPad et une version iPhone d'une application avec le même ID de bundle de xCode, au début, je ne pouvais pas avoir les deux sur iTunes mais après la démission et le changement d'ID de bundle, j'ai pu avoir les deux installés. J'ai également essayé de changer le nom de l'application et cela a également fonctionné, cela s'est montré sur l'appareil et dans iTunes avec le nouveau nom. Ci-dessous mon script, il est conçu pour résigner une application spécifique pour moi, donc le profil et le bundleID sont codés en dur. Je bascule entre une version iPhone et iPad de l'application, j'ai donc ajouté cela en tant que paramètre au script. Mais vous devriez pouvoir prendre les principes que j'ai ici et les affiner par vous-même.
Le courage de cela s'appuie sur des articles comme D'autres aventures de démission pour iOS du journal de développement de Dan et très similaire au signataire d'application d'Erica Sadun répertorié ci-dessus. Le principal ajout que j'ai fait a été la modification de l'Info.plist avant de démissionner.
#!/bin/sh
DestFile="Signed_$1"
SigningCertName="YOUR DISTROBUTION CERT NAME HERE FROM KEYCHAIN"
AppInternalName="APP NAME FROM INSIDE PAYLOAD FOLDER.app"
echo
echo "Going to take the app $1 and resign it as $DestFile"
echo
if [ "$2" = "iphone" ] ; then
echo "Using iPhone Profile"
echo
BundleID="com.YOURCOMPANY"
ProvProfile="/Users/YOURNAME/Library/MobileDevice/Provisioning Profiles/PROVISIONINGPROFILE.mobileprovision"
Elif [ "$2" = "ipad" ] ; then
echo "Using iPad Profile"
echo
BundleID="com.YOURCOMPANY.ipad"
ProvProfile="/Users/YOURNAME/Library/MobileDevice/Provisioning Profiles/PROVISIONINGPROFILE_iPad.mobileprovision"
else
echo "You must enter either iphone or ipad as the second parameter to choose the profile to sign with."
echo
exit 1
fi
rm -f Resigned.ipa
unzip -q $1 -d temparea
cd temparea/Payload
echo "*** Original Signing ***"
echo "************************"
codesign -d -vv $AppInternalName/
cp "$ProvProfile" ./$AppInternalName/embedded.mobileprovision
export EMBEDDED_PROFILE_NAME=embedded.mobileprovision
export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate
#Update the Info.plist with the new Bundle ID
sed 's/>ORIGINAL BUNDLEID HERE</>'$BundleID'</' ./$AppInternalName/Info.plist >./$AppInternalName/Info.plist.new
mv -f ./$AppInternalName/Info.plist.new ./$AppInternalName/Info.plist
# this will do a rename of the app if needed
# sed 's/>ORIGINAL APP NAME</>NEW APP NAME</' ./$AppInternalName/Info.plist >./$AppInternalName/Info.plist.new
# mv -f ./$AppInternalName/Info.plist.new ./$AppInternalName/Info.plist
# echo "Hit enter to proceed with signing."
# read TMP
codesign -f -vv -s "$SigningCertName" -i $BundleID $AppInternalName
echo
echo "*** New Signing ***"
echo "*******************"
codesign -d -vv $AppInternalName/
cd ..
Zip -r -q ../Resigned.Zip .
cd ..
rm -R temparea
mv Resigned.Zip $DestFile
echo
echo "New IPA Created, $DestFile"
La meilleure alternative serait de demander au client d'exporter sa clé privée de certificat de distribution dans un fichier .p12 et de vous l'envoyer avec le profil de distribution avec lequel vous pouvez générer une version de distribution App Store pour votre client.
Bonne chance!!
Cordialement, Sam
iResign fonctionne assez bien.
Il vous permet de modifier l'ID de l'ensemble et d'ajouter des droits lors de la signature. Cela fonctionnerait probablement pour votre cas d'utilisation.
Cela étant dit, la solution xcarchive est plus canonique. Sachez que le partage du fichier xcarchive leur donne le dsym.
Si vous avez des instructions #ifdef DEBUG dans votre code, assurez-vous qu'elles sont désactivées dans la génération que vous leur donnez.
Huh, tout cela a l'air bien plus compliqué que nécessaire. J'utilise ceci ceci:
xcodebuild -scheme "$SCHEME" clean archive \
-archivePath "build/$SCHEME" \
-workspace $PRODUCT_NAME.xcworkspace \
-allowProvisioningUpdates \
-configuration Release \
PRODUCT_NAME="$SCHEME" \
PRODUCT_BUNDLE_IDENTIFIER="$BUNDLE_ID" \
EXECUTABLE_NAME="$SCHEME" \
DISPLAY_NAME="$DISPLAY_NAME" \
CODE_SIGN_IDENTITY="" \
CODE_SIGNING_REQUIRED=NO \
CODE_SIGN_ENTITLEMENTS="" \
CODE_SIGNING_ALLOWED=YES
Ok, trouvé un moyen de le faire sans partager les profils de provisioning ou les certificats .
L'idée est d'insérer une phase de construction de "script d'exécution" pour inciter XCode à signer une application qu'il n'a pas compilée, vous pouvez donc envoyer une application compilée (non signée) au client, puis leur XCode signe cette application avec leur certificat et profil.
Comment faire:
Étape 1 : Faire en sorte que XCode génère une version .app non signée (je l'appellerai "App A"). Voir "Pour désactiver la signature de code" ici: https://stackoverflow.com/a/10171462/375486
Étape 2 : Créez un nouveau projet XCode iOS et supprimez-en toutes les phases de construction, de sorte qu'il crée un fichier .app vide (je vais appeler cette "App B")
Étape 3 : Ajoutez une phase de construction "exécuter le script" au projet B qui copie le contenu de "App A" dans "App B". Dans mon cas, j'ai utilisé ceci:
cp -r A.app/* "$CODESIGNING_FOLDER_PATH"
Étape 4 : Envoyez le projet XCode "B" au client, avec tous les fichiers nécessaires.
Étape 5 : Le client construit le projet B. Sous le capot, XCode exécutera la commande "exécuter le script", puis signera l'application résultante et le client obtiendra une application parfaitement signée.
Et c'est tout :)
J'ai été là. Les options 2 ou 3 sont hors de question. L'option 4 serait idéale, mais comme vous l'avez écrit, Apple ne permettra pas à l'agent de déléguer ses privilèges pour créer des profils de distribution.
Donc, fondamentalement, votre seule option consiste à obtenir le profil de distribution défini avec leur compte. Pour que vous puissiez le gérer, vous devez vous connecter en tant qu'agent, ce qui n'est pas une option.
Alors ils devront le faire. Il n'y a pas de chemin aux alentours.
Ils devront également vous inviter en tant que membre de leur équipe de développement de produits sur leur compte. Vous devrez être administrateur. Cela signifie que vous devrez envoyer une demande de certificat de signature, comme indiqué par Apple.
Enfin, ils devront télécharger et vous envoyer les profils d'approvisionnement de distribution qu'ils ont créés.
Avec tout cela, vous pourrez signer votre candidature avec leurs ressources.
Je viens de raccrocher avec Apple. Ils disent que c'est la seule façon de le faire: https://developer.Apple.com/library/ios/#qa/qa1763/_index.html
Le client vous ajoute à son équipe et vous donne des privilèges spécifiques.