Насколько похожи эти приложения на самом деле? Если цель состоит в том, чтобы они отличались только по некоторым параметрам, я предпочитаю не поддерживать дублированные цели или проекты. Я считаю, что избыточные конфигурации, которые не должны изменяться, но которые другие разработчики и я должны пытаться синхронизировать, являются приглашением для внесения несоответствий, которые могут привести к ошибкам и, в конечном итоге, могут непреднамеренно порождать проекты.
Вместо этого я пытаюсь автоматизировать весь процесс и по возможности избегать создания дублирующих конфигураций. Я бы добавил фазу сборки сценария запуска в качестве первого шага в процессе сборки, который перед установкой собирает ссылки или копирует набор ресурсов, соответствующих текущему приложению, в положение. Таким образом, вы можете позволить переменной среды выбирать, какой набор ресурсов используется приложением. Разработчики должны иметь возможность добавлять неиспользуемые схемы в свою локальную рабочую область, если им нужен удобный способ устанавливать и менять значения этих переменных среды при сборке из xcode.
Я обнаружил, что это очень хорошо работает для небольших изменений конфигурации, таких как переключение приложения для взаимодействия с бэкэнд-системами разработки / подготовки / производства, и я упустил тот же уровень согласованности при работе над большим проектом, в котором изложено создавать несколько приложений, основанных только на разных наборах ресурсов, но быстро расходящихся в несовместимые системы, использующие единую кодовую базу.
Теперь, если вы считаете, что существует реальная необходимость добавить уникальное поведение к этим различным приложениям, я предлагаю создать общую цель построения статической библиотеки для общего кода, которая может быть включена целями сборки приложения для каждого приложения. Разделяйте весь кластер как рабочее пространство, и разработчики могут переключать приложения, просто выбирая соответствующую схему. Это должно поддерживать четкое разделение между общим и специфичным для приложения кодом без дополнительных накладных расходов.
По мере роста и стабилизации приложений вы, возможно, захотите перейти в несколько репозиториев с проектом статической библиотеки, что является общей зависимостью других. Это приведет к затратам на работу как с приложением, так и с разделяемой библиотекой, но это может быть желательно, если вы должны быть осторожны при внесении изменений в эту базу общего кода. Несколько репозиториев также позволят каждому приложению блокировать определенные ревизии общих библиотек и контролировать, когда они принимают новые изменения, в зависимости от вашего процесса, который может рассматриваться как хороший или плохой.