Я відкрив нагороду: "Шукаю відповідь із надійних та / або офіційних джерел". але не отримували таких відтоді.
Незважаючи на те, що відповідь, надана @jackslash, є правильною, вона розповідає лише частину історії, тому я хочу написати свою власну, так, як би хотілося, щоб я бачив її в той момент, коли я задавав це питання.
Актуальність цієї відповіді: липень 2015 р. Найімовірніше, що все зміниться.
Перш за все, давайте стверджуватимемо, що дії, необхідні для правильного підписання коду фреймворку, повинні бути розділені на кроки, які повинен зробити розробник фреймворку, і кроки, які повинен зробити споживач фреймворку.
TLDR;
Для фреймворку OSX: розробник може вільно розповсюджувати фреймворк OSX без кодового дизайну, оскільки споживач все одно перепрограмує його.
Для фреймворку iOS: розробник може вільно розповсюджувати фреймворк iOS без кодового підпису, оскільки споживач все одно перепроектує його, але розробник змушений Xcode кодувати їх фреймворк, коли вони будують для пристрою iOS.
Через радара: "Фреймворки iOS, що містять фрагменти симулятора, не можуть бути надіслані в App Store". Споживач фреймворку iOS змушений запускати спеціальний сценарій, такий як "copy_frameworks" або "strip_frameworks", який використовує lipo -removeдля видалення фрагментів симулятора з фреймворку iOS і повторного використання -дизайнери позбавлені фреймворку, тому що в цей момент його ідентифікатор коду, яким би він не був (чи не був), видаляється як побічний ефект lipo -removeманіпуляції.
Далі йде довша відповідь.
Ця відповідь не є "черпанням з достовірних та / або офіційних джерел", а скоріше базується на ряді емпіричних спостережень.
Емпіричне спостереження №1: Споживачеві це байдуже, оскільки він перепрограмує структуру, отриману від розробника
Бінарні фреймворкові розподіли добре відомих проектів з відкритим кодом на Github не кодуються . Команда codesign -d -vvvvдає: "об'єкт коду взагалі не підписаний" на всіх двійкових фреймворках iOS та OSX, які я використовував для дослідження. Кілька прикладів: ReactiveCocoa and Mantle , Realm , PromiseKit .
З цього спостереження стає зрозумілим, що автори цих фреймворків мають намір підписувати їх споживачем, від їх імені, тобто споживач повинен використовувати або прапорець "Знак коду при копіюванні" у фазі побудови "Вбудовувати фреймворки", наданий Xcode, або використовувати якусь спеціальну оболонку скрипт, який робить те ж саме вручну: фреймворк кодових знаків від імені Споживача.
Я не знайшов жодного прикладу протилежного: фреймворк з відкритим кодом, який буде розповсюджений із ідентифікацією коду в ньому, тому в решті відповіді я вважаю цей широко прийнятий підхід правильним: немає необхідності в розробнику фреймворку поширювати їх фреймворк іншим розробникам із кодовою ідентифікацією, оскільки споживач у будь-якому випадку перепрограмує його .
Емпіричне спостереження №2, яке стосується лише iOS і яке цілком стосується розробника
У той час як Споживач не піклується структура отримувати їх від забудовника codesigned чи ні, розробник все ще потребує CodeSign своїх рамок IOS , як частина процесу складання , коли вони будують його для IOS пристроїв , оскільки в іншому випадку Xcode не будує: CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'. Цитую Джастін Spahr-Саммерс :
Фреймворки OS X не потрібно кодувати під час збірки ... На жаль, Xcode вимагає, щоб фреймворки iOS кодувались під час збірки.
Це досить хороші відповіді на моє запитання №2: «Ідентифікатора розробника iPhone» достатньо, щоб привабити Xcode, щоб він міг створити фреймворк iOS для пристрою. Цей коментар до Carthage # 339 говорить про те саме.
Емпіричне спостереження №3: інструмент lipo
Специфічну поведінку льего інструменту: при нанесенні на рамкову двійковий, вона завжди рекурсивно видаляє будь CodeSign тотожності з нього : lipo -create/-remove codesigned framework ... -> not codesigned framework.
Це може бути відповіддю на те, чому всі приклади у спостереженні №1 взагалі не підписані кодом: їх ідентифікатор кодового дизайну здувається після застосування lipo, але оскільки згідно з спостереженням №1 споживачеві все одно, це нормально.
Це спостереження особливо актуально для наступного спостереження № 4 щодо AppStore.
Емпіричне спостереження №4: фреймворки iOS, що містять фрагменти симулятора, не можуть бути надіслані в App Store
Це широко обговорюється в: Realm # тисяча сто шістьдесят три і Карфагена # 188 і відкритий радар: rdar: // 19209161 .
Це повністю турбує Споживача: для універсальної фреймворки iOS, яку Споживач включає в свій додаток, під час створення додатка вони повинні запускати спеціальний скрипт (спеціальна фаза запуску сценарію), який видаляє фрагмент симулятора з двійкового файлу цього фреймворку, щоб програма могла пройти перевірку AppStore.
Хороший приклад для двійкових фреймворків, який я знайшов у Realm: strip-frameworks.sh .
Він використовує lipoдля видалення всіх фрагментів архітектур, крім, ${VALID_ARCHS}а потім перекодує його з ідентифікацією споживача - саме тут починається спостереження №3: фреймворк повинен бути перекодований через маніпуляції з ним.
У Carthage є сценарій CopyFrameworks.swift, який робить те саме для всіх фреймворків, включених споживачем: він видаляє фрагменти симулятора та перекодує фреймворк від імені споживача.
Також є хороша стаття: Видалення небажаних архітектур із динамічних бібліотек у Xcode .
Тепер огляд кроків, необхідних для створення iOS та OSX як з точки зору розробника, так і з точки зору споживача. Спочатку простіший:
OSX
Розробник:
- Створює фреймворк OSX
- Віддає споживачеві
Від розробника не потрібні дії з кодування.
Споживач:
- Отримує фреймворк OSX від розробника
- Копіює фреймворк у Frameworks / каталог і автоматично підписує його від свого імені споживача в рамках процесу "Підпис коду під час копіювання"
iOS
Розробник:
- Створює фреймворк iOS для пристрою. Кодове проектування вимагає Xcode, достатньо ідентичності "iPhone Developer".
- Створює фреймворк iOS для симулятора.
- Використовує lipo, який створює універсальний фреймворк iOS із попередніх двох. На цьому етапі ідентифікація кодового дизайну в 1 крок втрачається: універсальний фреймворковий двійковий файл "взагалі не підписаний", але це нормально, оскільки "Споживачеві все одно".
- Віддає споживачеві
Споживач:
- Отримує фреймворк iOS від розробника
- Копіює фреймворк у Frameworks / каталог (цей крок може бути зайвим, залежно від сценарію на кроці 3).
- Використовує спеціальний скрипт як частину процесу збірки: цей скрипт позбавляє симулятор фрагментів від фреймворку iOS, а потім перекодує його від свого імені споживача.