Ответ 1
Пока я соглашался с Абхи Беккером, что время выполнения - это неправильное время для этого (используйте директивы препроцессора и настройки сборки!), я хотел уточнить некоторые детали и спекуляции в предыдущем ответе/комментариях и подсвечивать некоторый свет о вещах, которые вы могли бы сделать. Потерпите меня, это будет более длинный ответ...
Есть куча данных, которые могут находиться под общим зонтиком "Build Information". Неисчерпывающий список таких вещей будет включать в себя: Конфигурация сборки, идентификатор подписи кода, время сборки, дату сборки, номер версии маркетинга, номер ревизии SCM, имя ветки SCM, идентификатор профиля профиля предоставления, истечение срока действия профиля, номер сборки CI... список можно продолжать и продолжать.
Предполагая, что на данный момент ваш вопрос был сфокусирован на получении информации о типе сертификата iOS и профиле Provisioning Profile, используемом для сборки, тогда мне придется идти с очень твердым "Нет" в качестве ответа на вопрос: Есть ли способ проверить [сборку информации с использованием существующего метода API] во время выполнения? Вкратце: в совокупности эти две точки данных называются "Идентификация подписи кода" в настройках Xcode 4.6.x или "CODE_SIGN_IDENTITY" для настройки командной строки энтузиасты.
С момента, когда задавался этот вопрос, нет единого публичного API iOS, который вы можете вызвать для получения информации о типе подписи кода для текущего приложения. Вероятных причин этого много, но вот несколько примеров:
- Разработчикам разрешено создавать собственные схемы сборки и строить конфигурации. Это означает, что мы можем иметь одну схему и одну конфигурацию сборки, или одну схему, и десятки конфигураций сборки, или даже тысячи из них. Естественно, каждой схеме может быть назначена другая конфигурация сборки, и каждому из этих конфигураций может быть присвоен другой идентификатор подписи кода. Как вы могли догадаться, разработчик или команда не требует большой настройки, чтобы быстро получить хаотичность.
- Идентификаторы подписи кода требуют только, чтобы не прошедший просрочку профиль Provisioning Profile, выданный для текущего идентификатора приложения, содержит копию открытого ключа для сертификата, используемого для подписи двоичного файла. Для тех, кто работает в команде, у вас может быть один профиль Provisioning Profile, содержащий все сертификаты разработчиков в команде, или вы можете сделать отдельные профили Provisioning Profiles для каждого разработчика в команде, содержащей только свои сертификаты. Это еще одна разновидность вариаций в том, как разработчики могут выбирать для создания своего приложения.
- Разработчики могут использовать один сертификат (tsk tsk) или выдавать свои собственные сертификаты... yep, вы догадались, еще больше вариантов.
Этот гипотетический однонаправленный API затем должен иметь доступ во время выполнения ко всем вашим данным конфигурации сборки, сертификатам и профилям подготовки, чтобы иметь возможность раскручивать "эффективные" настройки, применяемые во время компиляции, и уменьшать все эти данные вплоть до конечной строки... просто для просмотра диагностики разработчика... не невозможный подвиг по какой-либо части воображения, но такая потенциально интенсивно работающая с вычислительной точки зрения операция для незначительной выгоды для разработчиков определенно будет стоить минимум почти на любом списке приоритетов. Это будет вызвано еще больше в списке приоритетов, учитывая, что другие параметры (такие как флаговые значения времени компиляции!) Более надежны, дешевле в настройке и проще поддерживать в конечном итоге.
Теперь, что касается полузасушливого вопроса "Могу ли я сделать это во время выполнения?" Я бы решительно сказал: "Да, ты можешь".
Как вы знаете, сборки устройств - это единственные виды сборок, которые требуют подписи кода. Часть процесса создает файл в основном пакете под названием "embedded.mobileprovision". Это файл, принадлежащий вашей песочнице приложений, и, таким образом, вы абсолютно можете открывать программно:
[[NSBundle mainBundle] pathForResource:@"embedded.mobileprovision" ofType:nil]
.mobileprovision кодируются PCKS # 7 и содержат как двоичные, так и текстовые данные. Информация, которую вы ищете, - это текстовый планшет, встроенный в данные PCKS # 7. Во-первых, использование OS X позволяет взглянуть на эти текстовые данные из одного из ваших устройств:
- Щелкните правой кнопкой мыши на вашей сборке для набора устройств .app и выберите "Показать содержимое пакета"
- Скопируйте файл embedded.mobileprovision где-нибудь, легко доступный.
- Откройте этот файл с предпочтительным текстовым редактором.
Вы сразу заметите, что существует множество двоичных данных, но вы можете разглядеть части текстовых данных. Прокручивая вправо, вы увидите XML-стиль в стиле plist, но в этом представлении читать не так просто. Мы можем использовать инструмент командной строки OS X для более удобного просмотра этих данных:
- Откройте терминал и "cd" в папку, содержащую вашу копию встроенного .mobileprovision.
- Запуск: безопасность cms -D -i embedded.mobileprovision
Это отобразит plist xml в окне терминала для вашего прочтения в удобном формате с вкладками. Если вы повторите этот процесс для сборки Ad-Hoc, сборки Dev и сборки App Store, вы начнете замечать ключи в этом тексте, которые указывают на соответствующие типы сборок. Для сборки, подписанной с сертификатом "iPhone Developer:..." (или "Dev", как вы указали в исходном сообщении), найдите:
<key>get-task-allow</key>
<true/>
Ключ 'get-task-allow' - это то, что используется для указания iOS, если приложение позволит отладчику подключиться к нему. В случае с бинарником, подписанным "iPhone Developer", это имеет смысл. Обычно вам нужно будет отлаживать устройство при нажатии кода с Xcode на ваше устройство для целей тестирования.
Разница между "Ad-Hoc" и "App Store" требует дополнительных проверок. Этот же ключ get-task-allow будет установлен как false для обоих этих типов распределений:
<key>get-task-allow</key>
<false/>
Однако сборки Ad-Hoc имеют определенный набор "ProvisionedDevices", не присутствующих в сборках "App Store":
<key>ProvisionedDevices</key>
<array>
<string>abcdef01234567890abcdef01234567890abacde</string>
<string>1abcdef01234567890abcdef01234567890abacd</string>
<string>2abcdef01234567890abcdef01234567890abacd</string>
</array>
Итак, что это означает в практическом отношении для проверки времени выполнения? Да, вы можете это сделать, открыв файл embedded.mobileprovision из основного пакета и проанализировав данные из него, чтобы принять обоснованное решение, но это то, что вы несете полную ответственность за реализацию себя. Вам нужно будет добавить логику для обработки случаев, когда этот файл отсутствует (например, симулятор сборки) и либо проанализировать данные PCKS # 7, либо надежно извлечь содержимое ASCII файла, на котором ваш код может запускать последовательность поиска строк, Как это очевидно, это потребует нетривиальных усилий для некоторого хрупкого решения, которое в противном случае легко можно было бы установить с помощью настроек сборки и макросов перед процессором, как сказал Абхи Бекерт в предыдущем ответе.
Как насчет риска отклонения App Store? Является ли это "незаконным" или "подрывным"?
Предполагая, что вы используете все публичные API при чтении и анализе содержимого файла embedded.mobileprovision, это вполне допустимо с учетом текущих условий App Store. Все, что есть в песочнице вашего приложения, - это честная игра, в том числе встроенная .mobileprovision, если она присутствует. Я все еще настоятельно предупреждаю вас о том, чтобы спуститься по этой дороге, повторяя комментарии Абхи Беккерта. Это значительный объем усилий для менее 1% случаев использования, и есть гораздо более простые решения! Кроме того, объявления разработчика не должны быть в версиях выпуска App Store, однако решение о включении постороннего кода полностью находится в ваших руках.
Я надеюсь, что это очистит любые затяжные вопросы, но если нет, пожалуйста, бросьте комментарий, и мы можем видеть, что мы можем сделать.