Три слегка отличающихся приложения из одной кодовой базы

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

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

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

  3. MyApp (Выпуск)

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

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

4 12
ios iphone info-plist

4 ответа:

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

После еще нескольких исследований я понял, как получить лучшее из обоих миров с помощью только одной цели:
  • создайте нужные конфигурации в Xcode: ProjectName > ProjectName > Info. Например:
    • Debug
    • предварительный просмотр
    • освобождение
  • теперь эти три конфигурации доступны для всех параметров сборки.
  • Три приложения должны сосуществовать на одном устройстве. Я хочу иметь возможность иметь все три версии приложения на одном устройстве,для этого всем трем типам нужен другой идентификатор пакета. Исходный идентификатор может быть 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 вашего приложения.

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

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

Результат

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

26

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

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

4

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

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

2

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

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

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

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

Https://gist.github.com/2782045

0