Создание фреймворков iOS / OSX: необходимо ли их кодировать перед распространением другим разработчикам?

Я открыл баунти: "ищу ответ, взятый из надежных и/или официальных источников.- но с тех пор я такого не получал.

хотя ответ, предоставленный @jackslash, верен, он рассказывает только часть истории, поэтому я хочу написать свой собственный способ, которым я хотел бы видеть его в тот момент, когда я задавал этот вопрос.

актуальность этого ответа: июль 2015 года. Скорее всего, все изменится.

прежде всего, давайте утверждать, что действия, необходимые для правильного подписания кода фреймворка, следует разделить на шаги, которые разработчик фреймворка должен предпринять и шаги, которые должен предпринять потребитель фреймворка.

TLDR;

для OSX framework:разработчик может свободно распространять OSX framework без кодирования, так как потребитель будет повторно кодировать его в любом случае.

для iOS framework:разработчик может свободно распространять iOS фреймворк без кодирования его как потребитель будет повторно кодировать его в любом случае, но разработчик вынужден Xcode кодировать их фреймворк, когда они строят для устройства iOS.

из-за РЛС: "фреймворки iOS, содержащие фрагменты симулятора, не могут быть отправлены в магазин приложений" потребитель iOS framework вынужден запускать специальный скрипт, такой как" copy_frameworks "или" strip_frameworks", который использует lipo -remove для удаления срезов симулятора из фреймворка iOS и re-codesigns лишил фреймворк, потому что в этот момент его идентификатор кодирования, каким бы он ни был (или не был), удаляется как побочный эффект lipo -remove манипуляции.

более подробный ответ ниже.

---

эмпирическое наблюдение №1: потребитель не заботится, потому что они будут повторно кодировать структуру, которую они получают от Разработчик

Бинарные рамочные дистрибутивы известных проектов с открытым исходным кодом на Github не codesigned. Команда codesign -d -vvvv дает: "объект кода не подписан вообще" на всех бинарных платформах iOS и OSX, которые я использовал для изучения. Некоторые примеры: ReactiveCocoa и плащевой,область,PromiseKit.

из этого наблюдения ясно, что авторы этих структур намерены они должны быть разработаны потребителем, от их имени, Т. е. потребитель должен использовать либо флаг "Code Sign on Copy" в фазе сборки "Embed Framework", предоставленной Xcode, либо использовать какой-либо пользовательский сценарий оболочки, который делает то же самое вручную: codesigns framework от имени потребителя.

Я не нашел ни одного примера противоположного: open source framework, который будет распространяться с идентификатором codesigning в нем, поэтому в остальной части ответа я предполагаю, что этот широко принятый подход как правильно: разработчику фреймворка нет необходимости распространять свою фреймворк другим разработчикам с идентификатором codesigning в нем, потому что потребитель в любом случае перепроектирует его.

эмпирическое наблюдение #2, которое относится только к iOS и которое полностью касается разработчика

в то время как потребитель не заботится о том, является ли фреймворк, который они получают от разработчика, кодовым или нет, разработчик все еще нужно кодировать их iOS framework как часть процесса сборки, когда они строят его для устройства iOS потому что в противном случае Xcode не строит: CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'. Цитировать Джастин Спар-Саммерс:

фреймворки OS X не должны быть кодированы при сборке... К сожалению, Xcode требует, чтобы фреймворки iOS были разработаны во время сборки.

это довольно хорошо отвечает на мой вопрос #2: идентичности" iPhone Developer " достаточно, чтобы задобрить Xcode, чтобы он построил iOS framework для устройства. этот комментарий о Карфагене#339 говорит то же самое.

эмпирическое наблюдение #3: инструмент lipo

специфическое поведение инструмента lipo:при применении к бинарному фреймворку он всегда рекурсивно удаляет из него любые идентификаторы codesign:lipo -create/-remove codesigned framework ... -> not codesigned framework.

это может быть ответом, почему все примеры в наблюдении №1 вообще не кодируются: их идентичность кодирования сдувается после lipo применяется, но поскольку в соответствии с наблюдением № 1 потребитель не заботится, это нормально.

это наблюдение особенно актуально для следующего наблюдения №4 О AppStore.

эмпирическое наблюдение #4: фреймворки iOS, содержащие фрагменты симулятора, не могут быть отправлены в магазин приложений

это широко обсуждается в: Царство#1163 и Карфаген#188 и радар : rdar://19209161.

это полностью забота потребителя: для универсальной платформы iOS, которую потребитель включает в свое приложение, когда приложение создается, они должны запускать специальный скрипт (фаза пользовательского сценария запуска), который удаляет фрагмент симулятора из двоичного файла этой платформы, чтобы приложение могло пройти проверку AppStore.

хороший пример для бинарных фреймворков я нашел в Realm:strip-frameworks.sh.

It использует lipo чтобы удалить все фрагменты архитектуры, отличные от ${VALID_ARCHS} а затем повторно кодирует его с идентичностью потребителя - здесь начинается наблюдение №3: фреймворк должен быть перепроектирован из-за манипуляций lipo на нем.

у Карфагена есть CopyFrameworks.Свифт скрипт, который делает то же самое со всеми фреймворками, включенными потребителем: он удаляет срезы симулятора и повторно кодирует фреймворк от имени потребителя.

также есть хорошая статья: Удаление Нежелательных Архитектур Из Динамических Библиотек В Xcode.

---

теперь обзор шагов, необходимых для создания iOS и OSX как с точки зрения разработчика, так и с точки зрения потребителя. Сначала самый простой:

OSX

разработчик:

1. создает OSX framework
2. дает его потребителю

никаких действий по разработке кода не требуется от разработчиков.

потребитель:

1. получает OSX framework от разработчика
2. копирует фреймворк в фреймворки/ каталог и кодирует его автоматически от их имени, от имени потребителя, как часть процесса "Code Sign on Copy".

iOS

разработчик:

1. строит iOS framework для устройства. Кодирование требуется Xcode, идентичность" iPhone Developer " - это достаточно.
2. строит iOS framework для симулятора.
3. использует lipo, который производит универсальные рамки iOS из предыдущих двух. На этом этапе идентичность кодирования 1 шага теряется: универсальный фреймворк binary "вообще не подписан", но это нормально, так как "потребитель не заботится".
4. дает его потребителю

потребитель:

1. получает iOS framework от разработчика
2. копии базы для Рамки/ каталог (этот шаг может быть избыточным, в зависимости от того, какой сценарий в шаге 3.)
3. использует специальный скрипт как часть процесса сборки: этот скрипт удаляет симулятор срезает фреймворк iOS, а затем повторно кодирует его от имени своего потребителя.