Три немного разных приложения из одной кодовой базы - PullRequest
Новая
       28

Три немного разных приложения из одной кодовой базы

12 голосов
/ 22 января 2012

Привет, я хотел бы иметь три приложения в зависимости от того же кода:

  1. MyAppDevelopment (сборки из Xcode, развернутые на устройстве)

  2. MyAppPreview (бета-тестирование)

  3. MyApp (Выпуск)

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

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

Ответы [ 4 ]

26 голосов
/ 23 января 2012

Использование разных целей для разных выпусков приложений обеспечивает большую гибкость и позволяет легко изменять идентификатор пакета, значок и т. Д. После указания другого файла plist для цели. Однако конфигурации более глубоко интегрированы с XCode, и вы можете настроить любой build setting для конфигурации.

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

  • Создайте нужные конфигурации в Xcode: ProjectName > ProjectName > Info. Например:
    • Debug
    • Preview
    • 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
  • Нет необходимости в дополнительных целях
    Цели IMHO лучше для совершенно разных артефактов, таких как библиотеки или цели тестирования, которые имеют различную кодовую базу.
  • При необходимости конфигурации можно использовать в коде.
  • Различные сервисные URL и т. Д. Могут использоваться для разных сред. Посмотрите этот отличный пост (Спасибо Ионе!), Который показывает, как это сделать, используя специальный файл plist.
  • Не использовать хакерские скрипты, которые сложно поддерживать

Недостатки

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

  • Обновление : Нельзя использовать подстановки, такие как com.company.${PRODUCT_NAME:rfc1034identifier} для пользовательских настроек сборки. Так что в этом случае вам нужно будет выписать весь идентификатор пакета.

  • Обновление : Некоторые параметры, которые необходимо сделать «осведомленными о конфигурации», перемещаются в пользовательский раздел параметров сборки, что может показаться необычным для некоторых разработчиков.

Результат

Результат http://i.minus.com/jbwPgEiBra39dL.png

4 голосов
/ 22 января 2012

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

На самом деле я не вижу проблемы с «поддержанием» трех отдельных целей в одном проекте. Я делаю это все время (с двумя целями, но тем не менее). Это на самом деле очень элегантное решение.

2 голосов
/ 22 января 2012

В моих приложениях я часто добавлял шаг сборки «run script», чтобы скопировать специфический для среды plist на место перед сборкой приложения.При таком подходе я могу поменять весь Info.plist так, чтобы я мог изменять идентификаторы приложений в зависимости от настроек сборки.Я обычно устанавливаю среду для сборки на основе некоторой переменной среды, которую можно установить или изменить в настройках цели сборки.

Некоторые из моих коллег выбрали альтернативный подход, который позволяет вам использовать конфигурации XCode для определениясреда, но я не думаю, что это позволит вам изменить идентификатор приложения: http://blog.carbonfive.com/2011/06/20/managing-ios-configurations-per-environment-in-xcode-4/

0 голосов
/ 24 мая 2012

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

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

Одно важное добавление, которое я сделал, - это возможность определить основную среду, которая будет использоваться в качестве запасного варианта для других сред, если нет значения

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

https://gist.github.com/2782045

...