В чем разница между конфигурациями сборки и целями?
У нас есть пять практически идентичных приложений, с несколькими разными иконками / именами / настройками. Это разные "бренды" одного и того же приложения, различающиеся только несколькими иконками, отдельными группами приложений и несколькими настройками по умолчанию в коде. Они созданы как их собственные цели в XCode. Это одна кодовая база, но на нее указывают 5 целей.
Сначала все выглядело очень красиво, с пятью разными целями. Однако теперь мы добавили два расширения в приложение. Один пользовательский "NotificationContentExtension" и один "TodayExtension"(виджет). Поскольку у нас есть 5 разных целей с 5 разными правами / группами, мы не нашли другого способа достичь этого, кроме как добавить эти расширения в КАЖДУЮ цель. Поскольку расширение является еще одной целью, это означает, что у нас теперь есть 15 различных целей.
Сейчас мы испытываем крайне медленное время компиляции, потому что каждый раз, когда мы открываем раскадровку, Xcode компилирует все сразу для КАЖДОЙ (основной) цели. Мне не нужно строить свою раскадровку 5 раз. Или любой из моих других файлов. У меня есть ОДНО приложение, но несколько разных файлов и несколько настроек времени выполнения.
Это заставило меня задуматься - у каждой из этих 15 целей по умолчанию есть две конфигурации сборки: RELEASE и DEBUG. Я заметил, что это можно настроить и добавить еще. Почему бы не добавить конфигурации вместо целей?
Например, вместо "RELEASE" и "DEBUG", сделайте их "MYAPP1", "MYAPP2", "MYAPP3" и т. Д. Каждая конфигурация может иметь собственное имя продукта, значки и т. Д., Верно?
Есть ли веские причины не делать этого? Возможно ли это при работе с разными группами приложений / правами и т. Д.? У нас есть CoreData-базы данных, хранящиеся в AppGroups. Важно, чтобы все эти приложения могли быть установлены на одном устройстве без повреждения друг другом. Насколько я могу подумать, это не должно быть проблемой, если есть несколько разных FLAG для каждой конфигурации и настройка кода как такового. Как насчет подписания?
Я прочитал эту статью / учебное пособие по этому вопросу, в котором объясняются основы и начинаются мои действия, но это будет огромная работа, чтобы на самом деле протестировать ее с базами данных, правами и всеми остальными.
0 ответов
Отвечая несколько лет спустя: да, кстати. Использование BuildConfigurations безопасно и отлично работает. Он также удалил все ненужное время сборки. Мы преобразовали настройку проекта и получили три цели (приложение, widget1, widget2) и несколько конфигураций BuildConfiguration.
Чтобы настроить конфигурацию сборки, щелкните свой проект в Project Navigator, затем щелкните синий "MyApp" (в разделе PROJECT, а не в TARGETS), затем выберите "Info" на верхней панели. Вы увидите список ваших конфигураций. По умолчанию они будут "DEBUG" и "RELEASE". Вы можете добавить / удалить / настроить здесь. Сделайте это "MyApp1", "MyApp2" и "MyApp3". Затем щелкните свое "Мое приложение" в разделе "Цели", перейдите в "Настройки сборки" и выполните поиск, например, "Название продукта". Если навести на него курсор, рядом с "Название продукта" появится стрелка, щелкните ее, чтобы развернуть, затем вы увидите, что вы можете изменить значение индивидуально для различных конфигураций, поэтому "MyApp3" можно назвать "MyApp3" без влияя на других.Это можно сделать для всех настроек сборки.
Если у вас есть несколько "разновидностей" и, возможно, вам придется добавить их позже, я рекомендую НЕ изменять отдельные значения непосредственно в "Настройках сборки", поскольку их труднее найти и легче забыть. Лучше сделать так, чтобы каждое соответствующее значение (например, ProductName) наследовало от внешнего ключа, и создать свои собственные.xcconfig-файлы для каждого "вкуса", который содержит все индивидуальные значения для этих ключей. Таким образом, если вам нужно добавить еще один вариант, вы можете просто добавить еще один файл.xcconfig, в котором есть все соответствующие изменения, и вам не нужно просматривать все значения в BuildSettings и потенциально забывать некоторые из них.
Когда вы это сделаете, чтобы иметь возможность создавать / запускать каждую конфигурацию, вам нужно будет добавить схему в каждую конфигурацию.
Единственный отрицательный побочный эффект, который я заметил при таком подходе, - неправильный значок приложения в выпадающем списке схемы. Все они будут одинаковыми, даже если "Имя набора значков приложения" отличается. Значок приложения будет правильным при запуске / установке, но он будет отображаться неправильно во встроенном раскрывающемся списке Xcode.
Однако будьте осторожны, вы должны знать, что делаете при изменении настроек сборки. По умолчанию, когда вы запускаете приложение, запускается DEBUG-config, а RELEASE используется, когда вы "Архивируете" (когда вы выпускаете). Если вы не уважаете различия между этими двумя и просто создаете ОДНУ конфигурацию сборки для каждого из ваших приложений / вариантов, вы либо получите более длительное время сборки при разработке, либо снизите производительность после выпуска. Это зависит от настроек сборки, таких как "Уровень оптимизации" и т. Д. Поэтому на всякий случай вы должны создать "MyApp1DEBUG" и "MyApp1Release" для каждого приложения, которые являются клонами исходных "DEBUG" и "RELEASE" соответственно.