Ho aperto la taglia: "Alla ricerca di una risposta attingendo a fonti credibili e / o ufficiali". ma da allora non lo ricevo.
Sebbene la risposta fornita da @jackslash sia corretta, racconta solo una parte della storia, quindi voglio scriverne una mia in un modo in cui vorrei averla vista nel momento in cui stavo facendo questa domanda.
L'attualità di questa risposta è: luglio 2015. È molto probabile che le cose cambieranno.
Innanzitutto affermiamo che le azioni necessarie per la corretta firma del codice del framework dovrebbero essere suddivise in passaggi che lo sviluppatore del framework deve eseguire e in passaggi che il consumatore del framework deve eseguire.
TLDR;
Per il framework OSX: lo sviluppatore è libero di distribuire il framework OSX senza codificarlo poiché il consumatore lo ricodificherà comunque.
Per il framework iOS: lo sviluppatore è libero di distribuire il framework iOS senza codificarlo poiché il consumatore lo ricodificherà comunque, ma lo sviluppatore è costretto da Xcode a codificare il proprio framework quando costruisce per il dispositivo iOS.
A causa del radar: "I framework iOS contenenti sezioni del simulatore non possono essere inviati all'App Store" Il consumatore di framework iOS è costretto a eseguire uno script speciale come "copy_frameworks" o "strip_frameworks" che utilizza lipo -removeper rimuovere le sezioni del simulatore dal framework iOS e ri -codesigns ha spogliato il framework perché a questo punto la sua identità di codesigning qualunque fosse (o non fosse) viene rimossa come effetto collaterale della lipo -removemanipolazione.
Segue una risposta più lunga.
Questa risposta non è "attingendo a fonti credibili e / o ufficiali" ma si basa piuttosto su una serie di osservazioni empiriche.
Osservazione empirica n. 1: al consumatore non interessa perché ricodificherà il framework che riceve dallo sviluppatore
Le distribuzioni di framework binari di noti progetti open source su GitHub non sono codificate . Il comando codesign -d -vvvvfornisce: "l'oggetto codice non è firmato affatto" su tutti i framework binari iOS e OSX che ho usato per esplorare. Alcuni esempi: ReactiveCocoa and Mantle , Realm , PromiseKit .
Da questa osservazione è chiaro che gli autori di questi framework intendono che siano codificati dal Consumatore, per loro conto cioè un Consumatore deve utilizzare il flag "Code Sign on Copy" nella fase di compilazione "Embed frameworks" fornita da Xcode o utilizzare una shell personalizzata script che fa la stessa cosa manualmente: codeigns framework per conto del Consumatore.
Non ho trovato alcun singolo esempio del contrario: framework open source che verrebbe distribuito con identità di codeigning, quindi nel resto della risposta presumo che questo approccio ampiamente adottato sia corretto: non è necessario che Framework Developer distribuire il loro framework ad altri sviluppatori con identità di codeigning perché Consumer lo ricodificherà comunque .
Osservazione empirica n. 2 che si applica solo a iOS e che è interamente una preoccupazione dello sviluppatore
Mentre dei consumatori non si preoccupa se quadro che ricevono da sviluppatore è codesigned o no, sviluppatore ha ancora bisogno di codesign loro quadro iOS come parte del suo processo di generazione quando costruiscono per dispositivo iOS perché altrimenti Xcode non costruisce: CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'. Per citare Justin Spahr-Summers :
I framework OS X non devono essere codificati al momento della compilazione ... Sfortunatamente, Xcode richiede che i framework iOS siano codificati al momento della compilazione.
Questo risponde abbastanza bene alla mia domanda n. 2: l'identità di "iPhone Developer" è sufficiente per persuadere Xcode in modo che possa costruire il framework iOS per il dispositivo. Questo commento su Cartagine n. 339 dice la stessa cosa.
Osservazione empirica n. 3: strumento lipo
Comportamento specifico di strumento lipo: quando applicato al binario quadro, è sempre rimuove ricorsivamente qualsiasi identità codesign da esso : lipo -create/-remove codesigned framework ... -> not codesigned framework.
Questa potrebbe essere una risposta al motivo per cui tutti gli esempi nell'osservazione n. 1 non sono affatto codificati: la loro identità di siglatura del codice viene spazzata via dopo l'applicazione di lipo, ma poiché secondo l'osservazione n. 1 al consumatore non interessa, va bene.
Questa osservazione è particolarmente rilevante per la prossima osservazione n. 4 su AppStore.
Osservazione empirica n. 4: i framework iOS contenenti sezioni del simulatore non possono essere inviati all'App Store
Questo è ampiamente discusso in: Realm # 1163 e Carthage # 188 e il radar è aperto: rdar: // 19209161 .
Questa è interamente una preoccupazione del consumatore: per il framework universale iOS che il consumatore include nella sua applicazione, quando l'applicazione viene creata, devono eseguire uno script speciale (Custom Run Script Phase) che rimuove la slice del simulatore dal binario di quel framework in modo che l'app possa superare la convalida di AppStore.
Il buon esempio di framework binari che ho trovato in Realm: strip-frameworks.sh .
Viene utilizzato lipoper rimuovere tutte le sezioni di architetture diverse da ${VALID_ARCHS}e quindi ricodificarlo con l'identità del consumatore : è qui che entra in gioco l'osservazione n. 3: il framework deve essere ri-codificato a causa delle manipolazioni lipo su di esso.
Carthage ha lo script CopyFrameworks.swift che fa la stessa cosa a tutti i framework inclusi da Consumer: rimuove le sezioni del simulatore e ricodifica il framework per conto del consumatore.
Inoltre c'è un buon articolo: Rimozione di architetture indesiderate da librerie dinamiche in Xcode .
Ora la panoramica dei passaggi necessari per produrre sia iOS che OSX dal punto di vista dello sviluppatore e del consumatore. Prima quello più facile:
OSX
Sviluppatore:
- Costruisce il framework OSX
- Lo dà al consumatore
Non sono richieste attività di code design da parte dello sviluppatore.
Consumatore:
- Riceve il framework OSX dallo sviluppatore
- Copia il framework su Frameworks / directory e lo codifica automaticamente per conto del Consumatore come parte del processo "Code Sign on Copy".
iOS
Sviluppatore:
- Crea un framework iOS per il dispositivo. La firma del codice è richiesta da Xcode, l'identità di "iPhone Developer" è sufficiente.
- Crea un framework iOS per il simulatore.
- Utilizza lipo che produce un framework iOS universale dai due precedenti. A questo punto l'identità di codeigning di 1 passo è persa: il binario del framework universale "non è firmato affatto" ma va bene perché "al consumatore non interessa".
- Lo dà al consumatore
Consumatore:
- Riceve il framework iOS dallo sviluppatore
- Copia il framework nella directory Frameworks / (questo passaggio potrebbe essere ridondante a seconda dello script nel passaggio 3).
- Utilizza uno script speciale come parte del processo di compilazione: questo script elimina il simulatore dal framework iOS e quindi lo ricodifica per conto del consumatore.