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

Я изучаю, как создавать рамки iOS и OSX. Например, возьмем iOS, следующие шаги для меня работают:

инфраструктура xcodebuild с использованием -sdk iphonesimulator и действие сборки
инфраструктура xcodebuild с использованием -sdk iphoneos и действие сборки
Используйте инструмент lipo для создания универсального двоичного файла, чтобы lipo -info ожидал:

Архитектуры в файле жира: Foo.framework/Foo: i386 x86_64 armv7 arm64

Вопросы:

Я прочитал, что мои фреймворки могут быть повторно подписаны разработчиком, который его использует: "Code Sign on Copy", но я не понимаю, какие предпосылки для него, т.е. следует добавить код с кодом кодирует, что универсальный двоичный код с моим идентификатором подписи, прежде чем распространять его другим разработчикам?
если предыдущий положительный - следует ли использовать мой идентификатор "iPhone Distribution:..." или "iPhone Developer:..." достаточно (чтобы моя инфраструктура была частью какого-либо проекта iOS, проходит все виды валидации, особенно проверки в App Store)?.

Фон для моего ответа - это "Ошибка CodeSign: требуется подписание кода для типа продукта" Framework "в SDK" iOS 8.3 ", которое я видел в ряде сторонних фреймворков и Carthage # 235 или" объект кода вообще не подписан "(один пример: проблема, о которой я сообщал в Realm # 1998.

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

P.S. Этот вопрос становится еще более интересным, когда применяется не к одному разработчику, а к организации, которая является поставщиком инфраструктуры.

Ответ 1

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

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

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

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

TL;DR;

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

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

Из-за радара: "Рамки iOS, содержащие ломтики симулятора, не могут быть отправлены в App Store" Потребитель iOS-инфраструктуры вынужден запускать специальные script как "copy_frameworks" или "strip_frameworks", который использует lipo -remove для удаления срезов симулятора из инфраструктуры iOS и перекодирует разделяемую фреймворк, поскольку в этот момент его идентификация кодов, независимо от того, что она была (или не была), удаляется как побочный эффект lipo -remove.

Далее следует более длинный ответ.

Этот ответ не является "извлечением из достоверных и/или официальных источников", а скорее основан на ряде эмпирических наблюдений.

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

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

Из этого наблюдения ясно, что авторы этих фреймворков предполагают, что они будут координироваться потребителем от их имени, то есть потребитель должен использовать флаг "Code Sign on Copy" в фазе построения "Встроенные фреймворки", предоставляемый Xcode, или использовать некоторая пользовательская оболочка script, которая делает то же самое вручную: структура кодовых обозначений для имени пользователя.

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

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

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

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

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

Эмпирическое наблюдение № 3: липо-инструмент

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

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

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

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

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

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

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

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

Carthage имеет CopyFrameworks.swift script, который делает то же самое ко всем фреймворкам, включенным в Consumer: он удаляет фрагменты симулятора и re-codesigns framework на от имени потребителя.

Также есть хорошая статья: Удаление нежелательных архитектур из динамических библиотек в Xcode.

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

OSX

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

Создает инфраструктуру OSX
Предоставляет его потребителю

Никакие операции с кодами не требуются от разработчика.

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

Получает инфраструктуру OSX от разработчика
Копирует фреймворк в Frameworks/directory и codesigns автоматически на своих, Потребителях, от имени как часть процесса "Копировать подпись".

IOS

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

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

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

Получает инфраструктуру iOS от разработчика
Копирование рамки в каталог Frameworks/(этот шаг может быть избыточным в зависимости от того, что script на шаге 3).
Использует специальный script как часть процесса сборки: этот script слой симулятора разделяет структуру iOS, а затем перекодирует ее на своих пользователей, от имени пользователя.

Ответ 2

Из чтения связанной темы в репозитории Карфагена кажется относительно простым. Если вы распространяете двоичную структуру, вам нужно подписать ее код, и если вы распространяете исходный код через carthage или cocoa pods, вы не выполняете эти инструменты с помощью разных методов.

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

CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'

Не имеет значения, какой идентификатор вы подписываете под фреймворком (iPhone Developer или iPhone Distribution), потому что, как вы заметили, структура будет перекодирована с настройкой "кодовый знак при копировании". Это означает, что ваша инфраструктура будет перекодирована соответствующим сертификатом из профиля профиля пользователя инфраструктуры, когда ваша инфраструктура будет скопирована в их приложение. Это означает, что в App Store не будет проблем, поскольку он увидит только конечную подпись кода у пользователя инфраструктуры.

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