Créer des frameworks iOS / OSX: est-il nécessaire de les coder avant de les dissortingbuer à d'autres développeurs?

J'ai ouvert la générosité: "À la search d'une réponse tirée de sources crédibles et / ou officielles." mais ne l'ai pas reçu depuis.

Bien que la réponse fournie par @jackslash soit correcte, elle ne raconte qu'une partie de l'histoire, je veux donc é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 vont changer.

Tout d'abord, affirmons que les actions nécessaires à la signature correcte du framework doivent être divisées en étapes que le développeur du framework doit suivre et que le consommateur doit suivre.

TLDR;

Pour le framework OSX: Developer est libre de dissortingbuer le framework OSX sans le coder car Consumer le recode de toute façon.

Pour le framework iOS: Developer est libre de dissortingbuer le framework iOS sans le coder car Consumer le recode de toute façon, mais Developer est obligé par Xcode de coder son framework lors de sa construction pour le périphérique iOS.

En raison de radar: "Les frameworks iOS contenant des tranches de simulateur ne peuvent pas être soumis à l'App Store" Consumer of iOS framework est obligé d'exécuter un script spécial comme "copy_frameworks" ou "ssortingp_frameworks" qui utilise lipo -remove pour enlever les tranches de simulateur d'iOS cadre et re-codesigns cadre ssortingpped car à ce stade, son identité de codesigning quel qu'il soit (ou n'était pas) est supprimé comme effet secondaire de la manipulation lipo -remove .

Une réponse plus longue suit.

Cette réponse n'est pas un «tirage à partir de sources crédibles et / ou officielles» mais repose plutôt sur un certain nombre d'observations empiriques.

Observation empirique n ° 1: le consommateur ne s'en soucie pas car il re-codeignera le framework qu'il reçoit du développeur

Les dissortingbutions de framework binary de projets Open Source bien connus sur Github ne sont pas codées . La command codesign -d -vvvv donne: "l'object de code n'est pas du tout signé" sur tous les frameworks binarys iOS et OSX que j'avais l'habitude d'explorer. Quelques exemples: ReactiveCocoa et Mantle , Realm , PromiseKit .

De cette observation, il est clair que les auteurs de ces frameworks veulent qu'ils soient codés par Consumer, en leur nom, ie un Consumer doit utiliser soit le flag "Code Sign on Copy" dans la phase de construction "Embed frameworks" fournie par Xcode, soit un shell personnalisé script qui fait la même chose manuellement: codesigns framework pour le count du consommateur.

Je n'ai pas trouvé un seul exemple du contraire: le framework open source qui serait dissortingbué avec l'identité de codesigning dans le rest de la réponse. Je suppose que cette approche largement adoptée est correcte: il n'y a pas besoin de framework Developer pour dissortingbuer leur framework à d'autres développeurs avec une identité de codesigning, car Consumer le re-codeignera de toute façon .

L'observation empirique # 2 qui s'applique uniquement à iOS et qui est entièrement une préoccupation du développeur

Alors que Consumer ne se soucie pas de savoir si le framework reçu par Developer est codé ou non, Developer doit encore coder son framework iOS dans le cadre de son process de construction lorsqu'il le construit pour un périphérique iOS, 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 :

Malheureusement, Xcode exige que les frameworks iOS soient codés au moment de la construction.

Cela répond assez bien à ma question # 2: l'identité "iPhone Developer" est suffisante pour cajoler Xcode afin qu'il construise un framework iOS pour l'appareil. Ce commentaire sur Carthage # 339 dit la même chose.

Observation empirique # 3: outil lipo

Comportement spécifique de l'outil lipo: lorsqu'il est appliqué au framework binary, il en supprime toujours récursivement toutes les identités de codesign : lipo -create/-remove codesigned framework ... -> not codesigned framework .

Cela pourrait être une réponse pourquoi tous les exemples dans l'observation n ° 1 ne sont pas du tout codés: leur identité de codesigning est époustouflée après l'application de lipo mais puisque selon l'observation # 1 le consommateur s'en fout c'est bien.

Cette observation est particulièrement pertinente pour la prochaine observation # 4 sur 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 .

Cela concerne entièrement Consumer: pour le framework universel iOS que Consumer inclut dans son application, lors de la création de l'application, il doit exécuter un script spécial (Run Script Phase personnalisé) qui supprime la tranche de simulateur du binary de ce framework.

Le bon exemple pour les frameworks binarys que j'ai trouvés dans Realm: ssortingp-frameworks.sh .

Il utilise le lipo pour supprimer toutes les tranches d'architectures autres que ${VALID_ARCHS} , puis le re-code avec l'identité du consommateur – c'est là que l'observation # 3 intervient: le framework doit être reconçu en raison des manipulations lipo.

Carthage a un script CopyFrameworks.swift qui fait la même chose pour tous les frameworks inclus par Consumer: il supprime le framework de tranches de simulateurs et re-codesigns pour le count de Consumer.

Il y a aussi un bon article: Décaper les architectures indésirables des bibliothèques dynamics dans Xcode .

Maintenant, la vue d'set des étapes nécessaires pour produire à la fois iOS et OSX à la fois du sharepoint vue du développeur et du consommateur. D'abord le plus facile:

OSX

Développeur:

1. Construit le cadre OSX
2. Le donne au consommateur

Aucune activité de codesigning n'est requirejse du développeur.

Consommateur:

1. Reçoit le framework OSX du développeur
2. Copie le framework dans le directory Frameworks / et le code automatiquement au nom du consommateur, dans le cadre du process "Code Sign on Copy".

iOS

Développeur:

1. Construit un framework iOS pour le périphérique. Le codeigning est requirejs par Xcode, l'identité "iPhone Developer" est suffisante.
2. Construit un framework iOS pour simulateur.
3. Utilise lipo qui produit un cadre iOS universel des deux précédents. A ce stade, l'identité de code de 1 étape est perdue: le framework binary universel "n'est pas du tout signé" mais c'est bien puisque "le consommateur s'en fout".
4. Le donne au consommateur

Consommateur:

1. Reçoit le framework iOS du développeur
2. Copie le framework dans le directory Frameworks / (cette étape peut être redondante en fonction du script de l'étape 3).
3. Utilise un script spécial dans le cadre du process de construction: ce script supprime les tranches de simulateur de l'infrastructure iOS et les recode ensuite en leur nom, pour le count du consommateur.

De la lecture du fil lié sur le repo de Carthage, il semble relativement simple. Si vous dissortingbuez le framework binary, vous devez le codez le signer et si vous dissortingbuez la source via carthage ou cosses de cacao vous ne le faites pas car ces outils prennent soin de cela via différentes methods.

La raison pour laquelle vous avez besoin de le signer lors de la dissortingbution du framework binary est que Xcode ne produira pas de binary de framework sans que le code le signe. Si vous tentez de ne pas signer le cadre binary, vous obtenez cette erreur:

 CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1' 

Peu importe l'identité avec laquelle vous codez signer le framework (iPhone Developer ou iPhone Dissortingbution) car, comme vous l'avez indiqué, le framework sera reconçu avec le paramètre "code sign on copy". Cela signifie que votre infrastructure sera reconçue par le certificate approprié à partir du profil de développeur du consommateur d'infrastructure lorsque votre infrastructure est copiée dans son application. Cela signifie qu'il n'y aura pas de problèmes avec l'App Store, car il ne verra que la signature de code finale du consommateur de l'infrastructure.

À la fin de la journée, vous pourriez aussi bien signer votre binary .framework que vous ne voulez pas avoir à maintenir un process de construction exotique, et comme Xcode ne sortira que des frameworks signés, vous ne devriez pas vous éloigner trop du par défaut. Cela n'a pas vraiment d'importance parce que le consommateur final le re-signera.