Вам нужны разные package name (Android) и bundle id (iOS), потому что вам нужно использовать плагин Firebase Auth?
В этом случае для проекта iOS вы должны рассмотреть возможность использования PlistBuddy, и вы можете установить его, добавив Run Script в ваш XCode build phases как этот
if [ "${CONFIGURATION}" = "Debug" ]; then
/usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier com.example.developmento.appName" "$PROJECT_DIR/Runner/Info.plist"
echo "Changed bundle id for developement $PROJECT_DIR/Runner/Info.plist"
else
echo "Nothing to do"
fi
В любом случае, если вы не используете Firebase Auth, у вас может быть один и тот же идентификатор пакета в разных проектах Firebase.
Если вам нужно, чтобы дифференцировать файл проектов Firebase между этапамии производство, вы можете посмотреть здесь:
Как выбрать между разработкой и производственным проектом Firebase, основанным на вариантах сборки?
ОБНОВЛЕНИЕ
Итак, после OP-чата, зная, что он следует этому учебнику , чтобы настроить flutter flavors Я попытался понять, где мы застряли.
Отправной точкой является следующее:
- Два
Firebase project - Использование модуля
Firebase Auth (поэтому необходимо изменить идентификатор пакета между проектами) - И, конечно, два разных
GoogleService-Info.plist
Я начинаю с Xcode bundle id и GoogleService-Info.plist, настроенных на продуктИон (просто опция)
Затем я сохраняю и GoogleServices-Info-staging.plist, и GoogleServices-Info-production.plist, сохраняю в своей папке ios / Runner
Затем я установил этот сценарий сборки перед сценарием для Compile Sources
# Type a script or drag a script file from your workspace to insert its path.
if [ "${CONFIGURATION}" == "Debug" ] || [ "${CONFIGURATION}" == "Debug-Runner-staging" ]; then
echo "Setting up staging firebase environment"
/usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier com.example.staging.flutterAppAuthFlavours" "${PROJECT_DIR}/Runner/Info.plist"
cp -r "${PROJECT_DIR}/Runner/GoogleService-Info-staging.plist" "${PROJECT_DIR}/Runner/GoogleService-Info.plist"
echo "$(date) staging flavour - Configuration: ${CONFIGURATION}" > "${PROJECT_DIR}/environment.txt"
elif [ "${CONFIGURATION}" == "Debug-Runner-production" ]; then
echo "Setting up production firebase environment"
/usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier com.example.flutterAppAuthFlavours" "${PROJECT_DIR}/Runner/Info.plist"
cp -r "${PROJECT_DIR}/Runner/GoogleService-Info-production.plist" "${PROJECT_DIR}/Runner/GoogleService-Info.plist"
echo "$(date) production flavour - Configuration: ${CONFIGURATION}" > "${PROJECT_DIR}/environment.txt"
fi
И я назвал его Setup Firebase Environment (вы можетеназывайте это как хотите)
Этот сценарий также хранит некоторые журналы (с отметкой времени) в файле с именем environment.txt внутри папки ios вЧтобы легко проверить, что сделала сборка xcode
А теперь о Schemes и Build Configurations:
У меня естьсделано два Build Configuration, которые являются точной копией моего Debug Build Configuration, и я назвал их
Debug-Runner-stagingDebug-Runner-production
Практическое правило заключается в том, чтобы назвать конфигурации сборки как 'Debug-<your flavor>', и вам необходимо иметь схему для каждого варианта у вас есть, поэтому у меня есть эти:
Runner-staging чей Run вызывает отладка-Runner-staging build configuration Runner-production, чьи вызовы Run Debug-Runner-production конфигурация сборки
Так что теперь, если я позвоню flutter run --flavor Debug-staging, у меня будет сборка, которая запускается в моем staging firebase проекте.
и если яcall flutter run --flavor Debug-production У меня есть сборка, которая выполняется на моем проекте firebase.
ОБНОВЛЕНИЕ 2
Просто для полноты вы можете изменить идентификатор пакета также здесь:
В любом случае кажется, что странное поведение , что когда вы строите flavour во второй раз flutter, команда правильно строит аромат, но запускает предыдущие версии.build flavor .
При сборке с XCode и переключении со схемами все работает как положено (даже запуск правильного приложения) Я предполагаю, что это может быть проблема с командой флаттера.Поэтому я предлагаю вам попытаться подать проблему здесь , ссылающуюся также на этот ТАК вопрос / ответ.
ОБНОВЛЕНИЕ 3
После небольшого количества информации об интеллекте я обнаружил, что flutter tools устанавливает среду запуска приложения перед сборкой проекта.Поэтому, когда мы изменяем CFBundleIdentifier внутри Info.plist в первый раз, во второй раз, когда мы запускаем flutter run, он принимает предыдущее измененное значение и пытается запустить этот идентификатор пакета, в то время как во время сборки мы меняем его, потому что мы строим другой вариант.
Возможным решением может быть запуск сценария , который изменяет CFBundleIdentifier внутри Info.plist перед вызовом fluetter run.
Например, начиная с Info.plist с идентификатором производственного комплекта com.example.flutterAppAuthFlavours мы могли бы сделать что-то подобное
Здесь я использовал команду sed только для того, чтобы думать иначе, но вы могли бы всегда вызывать наш ниже PlistBuddy, чтобы внести изменения перед вызовом flutter run.