Как создать сборку релиза iOS, которую мой клиент может подписать на своем конце?

Question

Мой сценарий

Я написал приложение для iOS для клиента.Проект почти закончен, и теперь пришло время поместить его в App Store.Я отправлял им сборки для разработки на протяжении всего процесса разработки.Эти сборки имели идентификатор пакета, основанный на моей компании и проекте моего клиента, например: com.mycompany.clientname.projectname.Я подписал эти специальные сборки с помощью специального профиля обеспечения распространения, который я создал в своей собственной учетной записи на портале Provisioning Portal.

Теперь, когда пришло время перейти в App Store, мне нужно сделать Release Build и отправить егодля них, чтобы подписаться с их собственным профилем обеспечения распространения App Store.Это также подразумевает установку нового идентификатора пакета для проекта.

Моя проблема

Мне нужно доставить клиенту скомпилированное приложение, чтобы они могли подписать его с помощью своего профиля обеспечения,Тем не менее, мне нужно установить Bundle ID на то, что они собираются использовать в первую очередь.Допустим, это com.bestclientever.appname.Xcode 4 не позволяет мне архивировать проект сейчас, потому что это требует подписи кода.Я не могу подписать его кодом, потому что не могу создать профиль обеспечения с тем же идентификатором пакета, который был настроен на их портале обеспечения (портал обеспечения обеспечивает уникальность, как и должно быть).

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

Вопрос

Есть ли способ архивации илив противном случае построить приложение для iOS без кода, подписывающего его?Как установка «подписать позже» или что-то?

Или есть способ создать приложение с одним идентификатором пакета, но тогда кто-то другой сможет подписать его с помощью профиля обеспечения для другого идентификатора пакета (либо путем изменения идентификатора пакета скомпилированного приложения, либодругой метод подписи)?

Как мне собрать окончательную сборку релиза, но попросить кого-нибудь подписать приложение для распространения в App Store?

Что яПробовал или исследовал

• Действует для клиента.
  • С другими, менее подкованными клиентами я в итоге просто получил их учетные данные Provisioning Portal и iTunesConnect и выполнил окончательную сборку, как они.Это не будет летать с этим клиентом.Это большая компания со строгими правилами безопасности и большим количеством бюрократизма.
• Подмена в качестве клиента.
  • Это похоже на приведенное выше и не будет работать по тем же причинам.Звучит странно, спрашивая моего клиента: «Можете ли вы экспортировать свои личные ключи и отправить их мне»?Эта техника описана в этом ответе: Как я могу отправить приложение iOS клиенту, для них на кодовый знак
• Отправка клиенту исходного кода моего проекта и разрешениеони делают сборку релиза.
  • Лицензии на исходный код не было в нашем соглашении.Кроме того, этот клиент не хочет связываться с исходным кодом (а значит и с аутсорсингом).Я бы предпочел это как последний вариант, но должен быть лучший способ!
• Настройка в качестве разработчика уровня администратора в их Центре для разработчиков.
  • К сожалению, только пользователь уровня агента может создать профиль обеспечения (насколько я могу судить).Похоже, должен быть способ либо позволить мне создать профиль, который я могу использовать для подписи сборки, либо создать для меня профиль.Я не могу найти ни один из вариантов.

Answer 1

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

Это решение, которое я сейчас изучаю для своих собственных целей (не полностью протестировано):

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

Одна сложность заключается в том, что при создании архива с профилем разработчика атрибут права get-task-allow устанавливается в значение true, но для распространения необходимо установить значение false, поэтому вам придется обойти это, установив его вручную ваш Entitlements.plist - см. мой вопрос здесь: Могу ли я заархивировать с сертификатом разработчика, а затем повторно подписать его во время отправки с сертификатом распространения?

Answer 2

Я только что подтвердил на WWDC 2012, что работает следующая техника.Это наилучшим образом удовлетворяет моим ограничениям: небольшая вовлеченность клиентов, низкая квалификация клиентов, простой процесс подписания и владение исходным кодом.

1. Клиент приглашает разработчика в свою группу в Центре участников в качестве Администратора
2. Разработчик принимает приглашение (должно быть в вашем электронном письме)
3. Разработчик открывает Xcode Organizer -> вкладка «Устройства» -> Предоставление профилей и нажимает кнопку «Обновить» в правом нижнем углу.Убедитесь, что вы выбрали правильную команду, и у вас должно появиться несколько новых предметов.
4. В Xcode оставьте настройки идентификации подписи кода на их значения по умолчанию (или сбросьте их на iPhone Developer для любого iOS SDK)
5. Архивирование приложения
6. В Организаторе щелкните правой кнопкой мыши архив и выберите Показать в Finder
7. Отправьте файл .xcarchive своему клиенту
8. На клиенте должен быть установлен Xcode
9. Клиент дважды щелкает файл .xcarchive, который должен открыть его в Организаторе
10. Клиент нажимает Распределить и подписывает приложение под своей идентификационной информацией
11. Прибыль

Для этого клиенту необходимо использовать Центр участников на developer.apple.com и немного использовать XCode (но только Организатор!).Если у вашего клиента проблемы с техническими возможностями на этом уровне, тогда я рекомендую просто взять и сделать это для них (и взимать плату за это!).Спросите их логин и пароль разработчика и просто действуйте от их имени, как если бы вы были сотрудником.

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

Answer 3

У меня была такая же проблема.Вот как я наконец решил:

1. Клиент создал документация .
2. Клиент создал файл разработки с использованием того же идентификатора приложения, что и файл обеспечения распространения.
3. Экспортированный клиентом сертификат разработки (.p12).
4. Клиент отправил мне файл .p12 ифайл обеспечения разработки для мобильных устройств.
5. Я импортировал файл p12 клиентов в свою цепочку ключей
6. Я импортировал файл обеспечения клиента в Xcode.
7. Установите идентификатор подписи кода для конфигурации моей сборкииспользовать файл инициализации клиента.
8. Я заархивировал приложение.
9. Я отправил архив клиенту.
10. Клиент создал свою сборку дистрибутива, подписав приложение с их распределение файл обеспечения.(Они распространяли приложение для тестирования внутри компании.)

Клиент не очень заботился о совместном использовании сертификата development , так как они будут делиться своим распространениемCertificate.

Мне также пришлось создать entitlements.plist с параметром «Может быть отлажено» (get-task-allow), установленным на NO, и ссылаться на него в конфигурации сборки (в разделе «Подписание кода», «Подписание кода»).

Answer 4

Полагаю, я нашел способ сделать именно то, что вы хотите, я не проводил подробное тестирование и не пытался загрузить его в магазин приложений, но из проведенного тестирования это кажется хорошим.Отставка и добавление моего профиля обеспечения работают, поскольку я могу установить его на свои устройства, определенные в профиле AdHoc, без необходимости ручной установки профиля.Второй тест состоял в том, что я получил iPad и версию приложения для iPhone с тем же идентификатором пакета от xCode, сначала у меня не могло быть обоих в iTunes, но после изменения идентификатора пакета и изменения пакета я мог установить оба.Я также попытался изменить имя приложения, и это сработало, оно показывалось на устройстве и в iTunes с новым именем.Ниже приведен мой сценарий, он предназначен для отставки определенного приложения для меня, поэтому профиль и идентификатор пакета жестко закодированы.Я переключаюсь между версией приложения для iPhone и iPad, поэтому добавляю это в качестве параметра в скрипт.Но вы должны быть в состоянии взять принципы, которые у меня есть, и уточнить их для себя.

Суть этого строится на статьях вроде Дальнейшие приключения в отставке для iOS из Дэна Dev Diary и оченьпохож на Эрик Садун в App Signer, перечисленных выше.Основным дополнением, которое я сделал, было редактирование Info.plist до отставки.

#!/bin/sh

DestFile="Signed_$1"
SigningCertName="YOUR DISTROBUTION CERT NAME HERE FROM KEYCHAIN"
AppInternalName="APP NAME FROM INSIDE PAYLOAD FOLDER.app"

echo
echo "Going to take the app $1 and resign it as $DestFile"
echo

if [ "$2" = "iphone" ] ; then
        echo "Using iPhone Profile"
        echo
        BundleID="com.YOURCOMPANY"
        ProvProfile="/Users/YOURNAME/Library/MobileDevice/Provisioning Profiles/PROVISIONINGPROFILE.mobileprovision"
elif [ "$2" = "ipad" ] ; then
        echo "Using iPad Profile"
        echo
        BundleID="com.YOURCOMPANY.ipad"
        ProvProfile="/Users/YOURNAME/Library/MobileDevice/Provisioning Profiles/PROVISIONINGPROFILE_iPad.mobileprovision"
else
        echo "You must enter either iphone or ipad as the second parameter to choose the profile to sign with."
        echo
        exit 1
fi

rm -f Resigned.ipa
unzip -q $1 -d temparea
cd temparea/Payload
echo "*** Original Signing ***"
echo "************************"
codesign -d -vv $AppInternalName/
cp "$ProvProfile" ./$AppInternalName/embedded.mobileprovision
export EMBEDDED_PROFILE_NAME=embedded.mobileprovision
export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate

#Update the Info.plist with the new Bundle ID
sed 's/>ORIGINAL BUNDLEID HERE</>'$BundleID'</' ./$AppInternalName/Info.plist >./$AppInternalName/Info.plist.new
mv -f ./$AppInternalName/Info.plist.new ./$AppInternalName/Info.plist

# this will do a rename of the app if needed
# sed 's/>ORIGINAL APP NAME</>NEW APP NAME</' ./$AppInternalName/Info.plist >./$AppInternalName/Info.plist.new
# mv -f ./$AppInternalName/Info.plist.new ./$AppInternalName/Info.plist

# echo "Hit enter to proceed with signing."
# read TMP
codesign -f -vv -s "$SigningCertName" -i $BundleID $AppInternalName

echo
echo "*** New Signing ***"
echo "*******************"
codesign -d -vv $AppInternalName/
cd ..
zip -r -q ../Resigned.zip .
cd ..
rm -R temparea
mv Resigned.zip $DestFile
echo
echo "New IPA Created, $DestFile"

Answer 5

Лучший альтернативный способ - попросить клиента экспортировать закрытый ключ его сертификата распространения в файл .p12 и отправить его вам вместе с профилем распространения, с помощью которого вы можете сгенерировать сборку дистрибутива App Store для вашего клиента.

Удачи !!

С уважением, Sam

Answer 6

Да, все это выглядит намного сложнее, чем нужно.Я использую это это:

xcodebuild -scheme "$SCHEME" clean archive \ 
           -archivePath "build/$SCHEME" \
           -workspace $PRODUCT_NAME.xcworkspace \
           -allowProvisioningUpdates \ 
           -configuration Release \
           PRODUCT_NAME="$SCHEME" \ 
           PRODUCT_BUNDLE_IDENTIFIER="$BUNDLE_ID" \
           EXECUTABLE_NAME="$SCHEME" \ 
           DISPLAY_NAME="$DISPLAY_NAME" \
           CODE_SIGN_IDENTITY="" \ 
           CODE_SIGNING_REQUIRED=NO \ 
           CODE_SIGN_ENTITLEMENTS="" \
           CODE_SIGNING_ALLOWED=YES

Answer 7

iResign работает довольно хорошо.

Позволяет изменить идентификатор пакета и добавить права при подписании. Вероятно, будет работать для вашего случая использования.

При этом решение xcarchive более канонично. Имейте в виду, что совместное использование файла xcarchive дает им dsym.

Если в вашем коде есть какие-то операторы #ifdef DEBUG, убедитесь, что они отключены в той сборке, которую вы им предоставляете.

Answer 8

Хорошо, нашел способ сделать это без совместного использования профилей или сертификатов обеспечения .

Идея состоит в том, чтобы вставить фазу сборки "run script", чтобы обманным путем заставить XCode подписать приложение.не компилировались, поэтому вы можете отправить клиенту скомпилированное (без подписи) приложение, а затем его XCode подписывает это приложение своим сертификатом и профилем.

Как это сделать:

Шаг 1 : заставить XCode генерировать неподписанный выпуск .app (я назову это «Приложение A»).См. «Отключение подписи кода» здесь: https://stackoverflow.com/a/10171462/375486

Шаг 2 : создайте новый проект XCode iOS и удалите из него все фазы сборки, которые вы можете, так что он создает пустой .appфайл (я назову это «Приложение B»)

Шаг 3 : Добавить этап сборки «Run script» в проект B, который копирует содержимое «приложения A» в «приложение»B».В моем случае я использовал это:

cp -r A.app/* "$CODESIGNING_FOLDER_PATH"

Шаг 4 : отправьте клиенту проект "B" XCode со всеми необходимыми файлами.

Шаг 5 : клиент строит проект B.Под капотом XCode запустит команду «run script», затем подпишет получившееся приложение, и клиент получит прекрасно подписанное приложение.

И все:)

Answer 9

Я только что говорил по телефону с Apple.Они говорят, что это единственный способ сделать это: https://developer.apple.com/library/ios/#qa/qa1763/_index.html

Клиент добавляет вас в свою команду и дает вам определенные привилегии.

Answer 10

Я был там.Варианты 2 или 3 исключены.Вариант 4 был бы идеальным, но, как вы писали, Apple не позволит агенту делегировать свои привилегии для создания профилей распространения.

Таким образом, по сути, ваш единственный вариант - получить профиль распределения, определенный для их учетной записи.Для того, чтобы вы справились с этим, вам необходимо войти в систему в качестве их агента, что не является опцией.

Так что им придется сделать это.Обойти это невозможно.

Они также должны будут пригласить вас в качестве члена своей команды разработчиков продукта в своем аккаунте.Вам нужно будет быть администратором.Это значит, что вам нужно будет отправить запрос на подпись сертификата, как указано Apple.

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

При этом высможет подписать вашу заявку своими ресурсами.