Ich öffnete das Kopfgeld: "Auf der Suche nach einer Antwort aus glaubwürdigen und / oder offiziellen Quellen." habe aber seitdem keine mehr erhalten.
Die Antwort von @jackslash ist zwar korrekt, erzählt aber nur einen Teil der Geschichte. Daher möchte ich meine eigene so schreiben, wie ich es gerne gesehen hätte, als ich diese Frage gestellt habe.
Die Aktualität dieser Antwort lautet: Juli 2015. Es ist sehr wahrscheinlich, dass sich die Dinge ändern werden.
Lassen Sie uns zunächst behaupten, dass die für die korrekte Codesignatur des Frameworks erforderlichen Aktionen in Schritte unterteilt werden müssen, die der Entwickler des Frameworks ausführen muss, und in Schritte, die der Consumer des Frameworks ausführen muss.
TLDR;
Für das OSX-Framework: Es steht dem Entwickler frei, das OSX-Framework zu verteilen, ohne es zu codieren, da Consumer es ohnehin neu codiert.
Für iOS-Framework: Es steht dem Entwickler frei, das iOS-Framework zu verteilen, ohne es zu codieren, da der Verbraucher es trotzdem neu codiert. Der Entwickler wird jedoch von Xcode gezwungen, sein Framework beim Erstellen für iOS-Geräte zu codieren.
Aufgrund des Radars: "iOS-Frameworks, die Simulator-Slices enthalten, können nicht an den App Store gesendet werden" Consumer of iOS-Framework muss ein spezielles Skript wie "copy_frameworks" oder "strip_frameworks" ausführen, mit lipo -removedem Simulator-Slices vom iOS-Framework entfernt und erneut entfernt werden -Codesigns entfernt das Framework, da zu diesem Zeitpunkt seine Codesign-Identität, was auch immer es war (oder nicht war), als Nebeneffekt der lipo -removeManipulation entfernt wird.
Eine längere Antwort folgt.
Diese Antwort ist keine "Zeichnung aus glaubwürdigen und / oder offiziellen Quellen", sondern basiert auf einer Reihe empirischer Beobachtungen.
Empirische Beobachtung Nr. 1: Der Verbraucher kümmert sich nicht darum, weil er das vom Entwickler erhaltene Framework neu codiert
Binäre Framework-Distributionen bekannter Open-Source-Projekte auf Github sind nicht mit einem Code versehen . Der Befehl codesign -d -vvvvgibt an: "Codeobjekt ist überhaupt nicht signiert" auf allen binären iOS- und OSX-Frameworks, die ich untersucht habe. Einige Beispiele: ReactiveCocoa and Mantle , Realm , PromiseKit .
Aus dieser Beobachtung geht hervor, dass die Autoren dieser Frameworks beabsichtigen, sie vom Verbraucher mit einem Code zu signieren, dh ein Verbraucher muss entweder das Flag "Code Sign on Copy" in der von Xcode bereitgestellten Erstellungsphase "Frameworks einbetten" verwenden oder eine benutzerdefinierte Shell verwenden Skript, das dasselbe manuell ausführt: Codesigns Framework im Namen des Verbrauchers.
Ich habe kein einziges Beispiel für das Gegenteil gefunden: ein Open-Source-Framework, das mit einer Codesignatur-Identität verteilt wird. In der restlichen Antwort gehe ich von diesem weit verbreiteten Ansatz als richtig aus: Es besteht keine Notwendigkeit für Framework-Entwickler Verteilen Sie ihr Framework an andere Entwickler mit darin enthaltener Codesignatur, da Consumer es ohnehin neu codiert .
Empirische Beobachtung Nr. 2, die nur für iOS gilt und ausschließlich dem Entwickler ein Anliegen ist
Während es dem Verbraucher egal ist, ob das vom Entwickler erhaltene Framework mit einem Codesign versehen ist oder nicht, muss der Entwickler sein iOS-Framework im Rahmen seines Erstellungsprozesses beim Erstellen für ein iOS-Gerät mit einem Codesign versehen, da Xcode sonst nicht erstellt : CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'. Um Justin Spahr-Summers zu zitieren :
OS X-Frameworks müssen beim Erstellen nicht codiert werden ... Leider erfordert Xcode, dass iOS-Frameworks beim Erstellen codiert werden.
Dies beantwortet meine Frage Nr. 2 ziemlich gut: Die Identität des "iPhone-Entwicklers" reicht aus, um Xcode so zu beschwichtigen, dass ein iOS-Framework für das Gerät erstellt wird. Dieser Kommentar zu Karthago # 339 sagt dasselbe.
Empirische Beobachtung Nr. 3: Lipo-Tool
Spezifisches Verhalten des Lipo-Tools: Wenn es auf die Framework-Binärdatei angewendet wird, werden immer rekursiv alle Codesign-Identitäten daraus entfernt : lipo -create/-remove codesigned framework ... -> not codesigned framework.
Dies könnte eine Antwort sein, warum alle Beispiele in Beobachtung Nr. 1 überhaupt nicht mit einem Code versehen sind: Ihre Identität mit dem Code wird nach dem Auftragen von Lipo weggeblasen, aber laut Beobachtung Nr. 1 ist es dem Verbraucher egal, ob es in Ordnung ist.
Diese Beobachtung ist besonders relevant für die nächste Beobachtung Nr. 4 über AppStore.
Empirische Beobachtung Nr. 4: iOS-Frameworks mit Simulator-Slices können nicht an den App Store gesendet werden
Dies wird ausführlich diskutiert in: Realm # 1163 und Carthage # 188 und Radar wird geöffnet: rdar: // 19209161 .
Dies ist ganz und gar das Anliegen des Verbrauchers: Für das universelle iOS-Framework, das der Verbraucher in seine Anwendung einbezieht, muss er beim Erstellen einer Anwendung ein spezielles Skript (benutzerdefinierte Skriptphase ausführen) ausführen, mit dem das Simulator-Slice aus der Binärdatei dieses Frameworks entfernt wird, damit die App die AppStore-Validierung bestehen kann.
Das gute Beispiel für binäre Frameworks, das ich in Realm gefunden habe: strip-frameworks.sh .
Es wird verwendet lipo, um alle ${VALID_ARCHS}Teile von Architekturen außer zu entfernen und sie dann mit der Identität des Verbrauchers neu zu codieren. Hier setzt Beobachtung Nr. 3 an: Das Framework muss aufgrund von Lipo-Manipulationen neu codiert werden.
Karthago verfügt über das Skript CopyFrameworks.swift, das für alle von Consumer enthaltenen Frameworks dasselbe bewirkt: Es entfernt die Simulator-Slices und signiert das Framework im Auftrag von Consumer neu.
Es gibt auch einen guten Artikel: Entfernen unerwünschter Architekturen aus dynamischen Bibliotheken in Xcode .
Nun die Übersicht über die Schritte, die erforderlich sind, um sowohl iOS als auch OSX aus Sicht von Entwicklern und Verbrauchern zu erstellen. Zuerst das einfachere:
OSX
Entwickler:
- Erstellt das OSX-Framework
- Gibt es dem Verbraucher
Vom Entwickler sind keine Codesignierungsaktivitäten erforderlich.
Verbraucher:
- Erhält das OSX-Framework vom Entwickler
- Kopiert das Framework in das Frameworks / -Verzeichnis und signiert es automatisch im Namen des Verbrauchers im Rahmen des Prozesses "Code Sign on Copy".
iOS
Entwickler:
- Erstellt ein iOS-Framework für das Gerät. Für Xcode ist eine Codesignierung erforderlich. Die Identität des "iPhone-Entwicklers" reicht aus.
- Erstellt ein iOS-Framework für den Simulator.
- Verwendet Lipo, das ein universelles iOS-Framework aus den beiden vorherigen erstellt. Zu diesem Zeitpunkt geht die Codesignaturidentität von 1 Schritt verloren: Universal Framework Binary "ist überhaupt nicht signiert", aber das ist in Ordnung, da "Consumer ist das egal".
- Gibt es dem Verbraucher
Verbraucher:
- Erhält das iOS-Framework vom Entwickler
- Kopiert das Framework in das Frameworks / Verzeichnis (dieser Schritt kann redundant sein, je nachdem, welches Skript in Schritt 3 verwendet wird.)
- Verwendet ein spezielles Skript als Teil des Erstellungsprozesses: Dieses Skript entfernt Simulator-Slices vom iOS-Framework und signiert es dann im Namen des Verbrauchers neu.