Ответ 1
Использование разных целей для разных выпусков приложений обеспечивает большую гибкость и позволяет легко изменять идентификатор пакета и значок и т.д., как только вы укажете другой файл plist для каждой цели. Однако конфигурации более глубоко интегрированы с Xcode, и вы можете настроить любой build setting
для каждой конфигурации.
После нескольких исследований я выяснил, как получить лучшее из обоих миров только с одной целью:
- Создайте нужные конфигурации в Xcode:
ProjectName > ProjectName > Info
. Например:- Debug
- Предварительный просмотр
- Release
- Теперь эти три конфигурации доступны для всех настроек сборки.
-
Три приложения должны сосуществовать на устройстве. Я хочу иметь все три версии приложения на одном устройстве, для этого всем трем типам нужен другой идентификатор пакета. Исходный идентификатор может быть
com.company.${PRODUCT_NAME:rfc1034identifier}
.- Для этого перейдите к
MyProject > MyApp (Target) > Build settings
и нажмите кнопку(+) Add Build Setting
-
Добавьте новый ключ
${APP_ID}
и установите значения, подобные этому, и обратите внимание, что в конфигурацииrelease
не должно быть суффикса:APP_ID > 'com.company.MyApp-debug' > 'com.company.MyApp-preview' > 'com.company.MyApp'
- Теперь в
Info.plist
измените значениеBundle Identifier
на${APP_ID}
- Для этого перейдите к
-
Вы можете сделать то же самое с атрибутом
Bundle Display Name
илиIcon
, чтобы вы могли легко отличить приложение на один взгляд. - Вы можете установить
Preprocessor macros
для своих конфигураций, чтобы иметь возможность обнаруживать текущую конфигурацию в вашем коде. Это делается по умолчанию для конфигурацииdebug
:DEBUG=1
.
Преимущества
- Поскольку у трех приложений есть свой собственный идентификатор, вы не будете переопределять последнюю сборку предварительного просмотра при тестировании текущего приложения в Xcode.
- Хорошо интегрирован в Xcode и предлагает высокую гибкость
Все настройки сборки теперь могут быть индивидуально изменены для каждой конфигурации. - Новые конфигурации могут быть легко добавлены путем клонирования существующих конфигураций в Xcode
- Нет необходимости в дополнительных целях
Цели - ИМХО лучше для совершенно разных артефактов, например, библиотек или целей тестирования, имеющих другую базу кода. - Конфигурации могут использоваться в коде при необходимости.
- Различные URL-адреса службы и т.д. могут использоваться для разных сред. См. Этот отличный пост (спасибо Jonah!), Который показывает, как это сделать, используя специальный файл
plist
. - Не использовать хакерские скрипты, которые трудно поддерживать
Недостатки
-
При использовании целей можно было бы исключить некоторые фреймворки из типа приложения. Так, например, вы можете исключить некоторую библиотеку аналитики из версии
debug
вашего приложения. -
Обновить. Вы не можете использовать подстановки, такие как
com.company.${PRODUCT_NAME:rfc1034identifier}
для пользовательских настроек сборки. Таким образом, в этом случае вам придется записывать идентификатор пакета в целом. -
Обновить. Некоторые настройки, которые должны быть сделаны "с учетом конфигурации", переходят в раздел "Пользовательский" в настройках сборки, который может показаться необычным для некоторых разработчиков.