J'ai ouvert la prime: "A la recherche d'une réponse tirée de sources crédibles et / ou officielles." mais je n'ai pas reçu de tel depuis lors.
Bien que la réponse fournie par @jackslash soit correcte, elle ne raconte qu'une partie de l'histoire, donc je veux écrire la mienne d'une manière que j'aurais aimé voir au moment où je posais cette question.
La réalité de cette réponse est: juillet 2015. Il est fort probable que les choses changeront.
Tout d'abord, affirmons que les actions nécessaires pour une signature correcte du code du framework doivent être divisées en étapes que le développeur du framework doit suivre et en étapes que le consommateur du framework doit prendre.
TLDR;
Pour le framework OSX: Le développeur est libre de distribuer le framework OSX sans le coder car le consommateur le recodifiera de toute façon.
Pour le framework iOS: le développeur est libre de distribuer le framework iOS sans le coder car le consommateur le recodifiera quand même, mais le développeur est obligé par Xcode de coder son framework lorsqu'il construit pour un appareil iOS.
À cause du radar: "Les frameworks iOS contenant des tranches de simulateur ne peuvent pas être soumis à l'App Store" Le consommateur du framework iOS est obligé d'exécuter un script spécial comme "copy_frameworks" ou "strip_frameworks" qui utilise lipo -removepour supprimer les tranches de simulateur du framework iOS et re -codesigns a dépouillé le framework car à ce stade, son identité de code, quelle qu'elle soit (ou non), est supprimée comme effet secondaire de la lipo -removemanipulation.
Une réponse plus longue suit.
Cette réponse n'est pas un «tirage à partir de sources crédibles et / ou officielles» mais est plutôt basée sur un certain nombre d'observations empiriques.
Observation empirique n ° 1: le consommateur s'en fiche car il reconcevera le cadre qu'il reçoit du développeur
Les distributions de framework binaire de projets open source bien connus sur Github ne sont pas codées . La commande codesign -d -vvvvdonne: "l'objet de code n'est pas du tout signé" sur tous les frameworks binaires iOS et OSX que j'ai utilisés pour explorer. Quelques exemples: ReactiveCocoa et Mantle , Realm , PromiseKit .
À partir de cette observation, il est clair que les auteurs de ces frameworks ont l'intention qu'ils soient codés par le consommateur, en leur nom, c'est-à-dire qu'un consommateur doit utiliser soit le drapeau «Code Sign on Copy» dans la phase de construction «Embed frameworks» fournie par Xcode, soit utiliser un shell personnalisé script qui fait la même chose manuellement: cadre de codesigns pour le compte du consommateur.
Je n'ai trouvé aucun exemple du contraire: un framework open source qui serait distribué avec une identité de code-signature, donc dans le reste de la réponse, je suppose que cette approche largement adoptée est correcte: il n'est pas nécessaire que le développeur de framework distribuer leur framework à d'autres développeurs avec une identité de code car le consommateur le recodifiera de toute façon .
Observation empirique n ° 2 qui s'applique uniquement à iOS et qui est entièrement une préoccupation des développeurs
Bien que la consommation ne se soucie pas si le cadre qu'ils reçoivent du développeur est ou non un des concepteurs, développeur doit encore leur cadre iOS concerter de façon décisive dans le cadre de son processus de construction quand ils construisent pour appareil iOS car sinon Xcode ne construit pas: CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'. Pour citer Justin Spahr-Summers :
Les frameworks OS X n'ont pas besoin d'être codés lors de la construction ... Malheureusement, Xcode nécessite que les frameworks iOS soient codés au moment de la construction.
Cela répond assez bien à ma question n ° 2: l'identité "iPhone Developer" suffit à cajoler Xcode afin qu'il crée un framework iOS pour l'appareil. Ce commentaire sur Carthage # 339 dit la même chose.
Observation empirique n ° 3: outil lipo
Comportement spécifique de l' outil de lipo: lorsqu'il est appliqué à binaire-cadre, il a toujours supprime récursive toutes les identités codesign de celui - ci : lipo -create/-remove codesigned framework ... -> not codesigned framework.
Cela pourrait expliquer pourquoi tous les exemples de l'observation n ° 1 ne sont pas du tout signés par un code: leur identité de signature de code est époustouflée après l'application de la lipo, mais puisque selon l'observation n ° 1, le consommateur ne s'en soucie pas.
Cette observation est particulièrement pertinente pour la prochaine observation n ° 4 sur l'AppStore.
Observation empirique n ° 4: les frameworks iOS contenant des tranches de simulateur ne peuvent pas être soumis à l'App Store
Ceci est largement discuté dans: Realm # 1163 et Carthage # 188 et le radar est ouvert: rdar: // 19209161 .
C'est entièrement la préoccupation du consommateur: pour le cadre universel iOS que le consommateur inclut dans son application, lorsque l'application est en cours de construction, il doit exécuter un script spécial (phase d'exécution de script personnalisée) qui supprime la tranche de simulateur du binaire de ce cadre afin que l'application puisse passer la validation AppStore.
Le bon exemple de frameworks binaires que j'ai trouvé dans Realm: strip-frameworks.sh .
Il utilise lipopour supprimer toutes les tranches d'architectures autres que ${VALID_ARCHS}, puis le recode avec l'identité du consommateur - c'est là que l'observation n ° 3 entre en jeu: le cadre doit être recodé à cause de manipulations lipo dessus.
Carthage a le script CopyFrameworks.swift qui fait la même chose à tous les frameworks inclus par Consumer: il supprime les tranches du simulateur et recode le framework pour le compte de Consumer.
Il existe également un bon article: Suppression des architectures indésirables des bibliothèques dynamiques dans Xcode .
Maintenant, l'aperçu des étapes nécessaires pour produire iOS et OSX du point de vue du développeur et du consommateur. D'abord le plus facile:
OSX
Développeur:
- Construit le cadre OSX
- Le donne au consommateur
Aucune activité de signature de code n'est requise de la part du développeur.
Consommateur:
- Reçoit le framework OSX du développeur
- Copie le framework dans le répertoire Frameworks / et le code automatiquement pour le compte du consommateur dans le cadre du processus «Code Sign on Copy».
iOS
Développeur:
- Construit le cadre iOS pour l'appareil. La signature de code est requise par Xcode, l'identité «iPhone Developer» suffit.
- Construit un cadre iOS pour le simulateur.
- Utilise lipo qui produit le cadre iOS universel des deux précédents. À ce stade, l'identité de signature de code de 1 étape est perdue: le cadre binaire universel "n'est pas signé du tout" mais c'est très bien puisque "le consommateur s'en fiche".
- Le donne au consommateur
Consommateur:
- Reçoit le framework iOS du développeur
- Copie le framework dans le répertoire Frameworks / (cette étape peut être redondante selon le script de l'étape 3).
- Utilise un script spécial dans le cadre du processus de construction: ce script supprime le simulateur du framework iOS, puis le recode au nom du consommateur.