Otworzyłem nagrodę: „Szukam odpowiedzi na podstawie wiarygodnych i / lub oficjalnych źródeł”. ale od tamtej pory ich nie otrzymałem.
Odpowiedź udzielona przez @jackslash jest prawidłowa, ale opowiada tylko część historii, więc chcę napisać własną w taki sposób, w jaki chciałbym ją widzieć w momencie, gdy zadawałem to pytanie.
Aktualność tej odpowiedzi brzmi: lipiec 2015 r. Najprawdopodobniej sytuacja się zmieni.
Przede wszystkim upewnijmy się, że czynności potrzebne do prawidłowego podpisania kodu frameworka należy podzielić na kroki, które musi wykonać Programista frameworka oraz kroki, które musi wykonać Konsument frameworka.
TLDR;
W przypadku frameworka OSX: Programista może rozpowszechniać framework OSX bez kodowania go, ponieważ Konsument i tak będzie go ponownie kodował.
W przypadku platformy iOS: programista może dystrybuować framework iOS bez kodowania go, ponieważ konsument i tak go ponownie koduje, ale programista jest zmuszony przez Xcode do kodowania ich struktury podczas kompilacji dla urządzenia z systemem iOS.
Z powodu radaru: „Struktury iOS zawierające wycinki symulatora nie mogą być przesłane do App Store” Konsument frameworku iOS jest zmuszony do uruchomienia specjalnego skryptu, takiego jak „copy_frameworks” lub „strip_frameworks”, który służy lipo -removedo usuwania wycinków symulatora ze środowiska iOS -codesigns pozbawiony frameworka, ponieważ w tym momencie jego tożsamość kodowania, czymkolwiek był (lub nie był), jest usuwana jako efekt uboczny lipo -removemanipulacji.
Następuje dłuższa odpowiedź.
Ta odpowiedź nie jest „czerpaniem z wiarygodnych i / lub oficjalnych źródeł”, ale raczej opiera się na szeregu obserwacji empirycznych.
Obserwacja empiryczna nr 1: Konsumentów to nie obchodzi, ponieważ przeprogramują framework, który otrzymają od programisty
Binarne dystrybucje ram dobrze znanych projektów open source na Github nie są kodowane . Polecenie codesign -d -vvvvpodaje: „obiekt kodu nie jest w ogóle podpisany” we wszystkich binarnych frameworkach iOS i OSX, których używałem do eksploracji. Kilka przykładów: ReactiveCocoa and Mantle , Realm , PromiseKit .
Z tej obserwacji jasno wynika, że autorzy tych frameworków zamierzają być podpisane przez konsumenta w ich imieniu, tj. Konsument musi użyć flagi „Code Sign on Copy” w fazie budowy „Embed frameworks” dostarczonej przez Xcode lub użyć niestandardowej powłoki skrypt, który robi to samo ręcznie: koduje framework w imieniu Konsumenta.
Nie znalazłem ani jednego przykładu odwrotnego: framework open source, który byłby dystrybuowany z tożsamością kodowania, więc w pozostałej części odpowiedzi przyjmuję to szeroko przyjęte podejście jako poprawne: nie ma potrzeby, aby programista frameworków rozpowszechniać ich framework innym programistom z kodowaniem tożsamości, ponieważ Konsument i tak go przeprogramuje .
Empiryczna obserwacja nr 2, która dotyczy tylko iOS i która jest całkowicie troską dewelopera
Podczas gdy konsument nie obchodzi czy ramy otrzymują oni od deweloper jest codesigned lub nie, Programista musi jeszcze codesign ich ramy iOS jako część procesu kompilacji, gdy budować go na urządzeniu z iOS , bo inaczej Xcode nie buduje: CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'. Cytując Justina Spahra-Summersa :
Frameworki OS X nie muszą być kodowane podczas kompilacji ... Niestety, Xcode wymaga, aby struktury iOS były kodowane w czasie kompilacji.
To całkiem dobra odpowiedź na moje pytanie nr 2: tożsamość „programisty iPhone'a” wystarczy, aby zmusić Xcode do zbudowania struktury iOS dla urządzenia. Ten komentarz do Kartaginy nr 339 mówi to samo.
Obserwacja empiryczna nr 3: narzędzie lipo
Specyficzne zachowanie narzędzia lipo: po nałożeniu na ramowej binarnym, to zawsze rekurencyjnie usuwa wszelkie codesign tożsamości od niego : lipo -create/-remove codesigned framework ... -> not codesigned framework.
To może być odpowiedź, dlaczego wszystkie przykłady w obserwacji nr 1 nie są w ogóle oznakowane kodem: ich tożsamość kodowa zostaje zniweczona po zastosowaniu lipo, ale ponieważ zgodnie z obserwacją nr 1 Konsument nie dba o to, jest w porządku.
Ta obserwacja jest szczególnie istotna dla następnej obserwacji # 4 dotyczącej AppStore.
Obserwacja empiryczna nr 4: frameworków iOS zawierających wycinki symulatora nie można przesłać do App Store
Jest to szeroko omawiane w: Realm # 1163 i Carthage # 188, a radar zostaje otwarty: rdar: // 19209161 .
Jest to całkowicie kwestia konsumenta: w przypadku uniwersalnej platformy iOS, którą konsument zawiera w swojej aplikacji, podczas budowania aplikacji muszą oni uruchomić specjalny skrypt (niestandardowa faza uruchamiania skryptu), który usuwa wycinek symulatora z pliku binarnego tej platformy, aby aplikacja mogła przejść walidację AppStore.
Dobry przykład dla binarnych frameworków, który znalazłem w Realm: strip-frameworks.sh .
Używa lipodo usunięcia wszystkich fragmentów architektur innych niż, ${VALID_ARCHS}a następnie ponownie koduje go z tożsamością konsumenta - w tym miejscu pojawia się obserwacja nr 3: framework ma zostać ponownie zakodowany z powodu manipulacji lipo.
Carthage ma skrypt CopyFrameworks.swift, który robi to samo ze wszystkimi frameworkami zawartymi przez Consumer: usuwa fragmenty symulatora i ponownie koduje framework w imieniu konsumenta.
Jest też dobry artykuł: Usuwanie niechcianych architektur z bibliotek dynamicznych w Xcode .
Teraz przegląd kroków wymaganych do stworzenia systemu iOS i OSX z perspektywy dewelopera i konsumenta. Najpierw łatwiejszy:
OSX
Deweloper:
- Buduje framework OSX
- Daje to Konsumentowi
Od programisty nie są wymagane żadne czynności związane z kodowaniem.
Konsument:
- Otrzymuje framework OSX od Developer
- Kopiuje framework do Frameworks / katalogu i automatycznie podpisuje go w swoim imieniu Konsumenta w ramach procesu "Code Sign on Copy".
iOS
Deweloper:
- Buduje platformę iOS dla urządzenia. Xcode wymaga kodowania, wystarczy tożsamość „programisty iPhone'a”.
- Buduje strukturę iOS dla symulatora.
- Używa lipo, który tworzy uniwersalną strukturę iOS z dwóch poprzednich. W tym momencie tożsamość kodowania 1 kroku zostaje utracona: plik binarny uniwersalnej struktury „w ogóle nie jest podpisany”, ale to jest w porządku, ponieważ „Konsument nie obchodzi”.
- Daje to Konsumentowi
Konsument:
- Odbiera strukturę iOS od dewelopera
- Kopiuje framework do katalogu Frameworks / (ten krok może być zbędny w zależności od tego, jaki skrypt w kroku 3 jest).
- Używa specjalnego skryptu jako części procesu budowania: ten skrypt usuwa symulator z platformy iOS, a następnie ponownie koduje go w swoim imieniu konsumenta.