Три несколько разных приложения из одной базы кода

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

  • MyAppDevelopment (Создается из Xcode, которые развернуты на устройстве)

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

  • MyApp (Release)

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

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

Ответы

Ответ 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} для пользовательских настроек сборки. Таким образом, в этом случае вам придется записывать идентификатор пакета в целом.

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

Результат

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

https://gist.github.com/2782045