클라이언트가 서명 할 수있는 iOS 릴리스 빌드를 어떻게 생성합니까?
내 시나리오
클라이언트 용 iOS 앱을 작성했습니다. 프로젝트는 거의 끝났고 이제 App Store에 넣을 시간입니다. 저는 개발 프로세스 전반에 걸쳐 개발 빌드를 보내 왔습니다. 이러한 빌드에는 내 회사와 내 고객의 프로젝트를 기반으로 한 번들 ID가 com.mycompany.clientname.projectname있습니다. 내 자신의 프로비저닝 포털 계정에서 생성 한 Ad Hoc 배포 프로비저닝 프로필을 사용하여 해당 Ad Hoc 빌드에 서명했습니다.
이제 App Store로 이동할 때가되었으므로 Release Build를 수행하고 자신의 App Store 배포 프로비저닝 프로파일로 서명하도록 보내야합니다. 이것은 또한 프로젝트에 대한 새 번들 ID 설정을 의미합니다.
내 문제
프로비저닝 프로필로 서명 할 수 있도록 클라이언트에 컴파일 된 앱을 가져와야합니다. 그러나 번들 ID를 먼저 사용할 항목으로 설정해야합니다. 그것이 com.bestclientever.appname. Xcode 4에서는 코드 서명이 필요하기 때문에 지금 프로젝트를 보관할 수 없습니다. 프로비저닝 포털에서 설정 한 것과 동일한 번들 ID로 프로비저닝 프로파일을 생성 할 수 없기 때문에 코드 서명을 할 수 없습니다 (프로비저닝 포털은 고유성을 적용합니다.).
여기서 잘못된 가정이나 오해를 한 적이 있습니까? 즉. 서명 할 대상에 번들 ID를 설정해야합니까?
질문
코드 서명없이 iOS 앱을 보관하거나 빌드 할 수있는 방법이 있습니까? "나중에 서명"설정 같은 건가요?
또는 하나의 번들 ID로 앱을 빌드하는 방법이 있지만 다른 사람이 다른 번들 ID에 대한 프로비저닝 프로파일로 서명 할 수 있습니까 (컴파일 된 앱의 번들 ID 또는 다른 서명 방법 변경)?
최종 릴리스 빌드를 빌드하지만 다른 사람이 App Store에 배포하기 위해 앱에 서명하도록하려면 어떻게해야합니까?
내가 시도하거나 탐색 한 것
- 클라이언트를 위해 행동합니다.
- 익숙하지 않은 다른 클라이언트를 사용하면 프로비저닝 포털 및 iTunesConnect 자격 증명을 얻고 최종 빌드를 수행했습니다. 이 클라이언트와 함께하는 것은 아닙니다. 엄격한 보안 지침과 많은 관료를 가진 대기업입니다.
- 클라이언트로 스푸핑.
- 이것은 위의 것과 유사하며 같은 이유로 작동하지 않습니다. 제 고객에게 " 비공개 키를 내 보내서 저에게 보낼 수 있습니까? "라고 물으면 정말 수상 쩍게 들립니다 . 이 기술은 다음 답변에 설명되어 있습니다. 코드 서명을 위해 iOS 앱을 클라이언트에 보내는 방법
- 클라이언트에게 내 프로젝트 소스 코드를 보내고 릴리스 빌드를 수행하도록합니다.
- 소스 코드에 대한 라이선스는 우리 계약에 없었습니다. 또한이 클라이언트는 소스 코드에 관여하지 않기를 원합니다 (따라서 아웃소싱). 나는 이것을 최후의 수단 옵션으로 즐겁게 할 것이지만 더 나은 방법이 있습니다!
- 개발자 회원 센터에서 관리자 수준 개발자로 설정하기.
- 안타깝게도 에이전트 수준 사용자 만 프로비저닝 프로필을 만들 수 있습니다 (내가 말할 수있는 한). 빌드에 서명하는 데 사용할 수있는 프로필을 만들거나 나를 위해 프로필을 생성 할 수있는 방법이 있어야하는 것 같습니다. 두 가지 옵션을 찾을 수 없습니다.
이러한 답변의 대부분은 복잡하고 오래된 것 같습니다. 간단한 대답은 개발자 프로필로 아카이브 를 만드는 것 입니다.
이것은 현재 내 목적을 위해 조사하고있는 솔루션입니다 (완전히 테스트되지 않음).
해당 계정에 대한 개발자 액세스 권한 (팀 에이전트 아님)이 필요하고 지정된 앱 ID를 빌드 할 수있는 권한을 부여하는 개발 프로비저닝 프로필을 생성하기 만하면됩니다 (컴파일되기 때문에 앱 ID를 지정해야 함). 그런 다음 개발 프로필로 앱을 보관하고 클라이언트와 보관을 공유합니다. 그런 다음 자신의 배포 프로필을 사용하여 아카이브에 다시 서명 할 수 있습니다.
한 가지 문제는 개발자 프로필로 아카이브를 빌드 할 때 자격 속성 get-task-allow가 true로 설정되지만 배포를 위해 false로 설정되어야하므로 수동으로 Entitlements를 설정하여 문제를 해결해야한다는 것입니다. .plist-여기에서 내 질문보기 : 개발자 인증서로 보관 한 다음 배포 인증서로 제출하는 동안 다시 서명 할 수 있습니까?
나는 WWDC 2012에서 다음 기술이 작동한다는 것을 방금 확인했습니다. 적은 클라이언트 참여, 낮은 클라이언트 전문성, 간단한 서명 프로세스 및 소스 코드 소유권이라는 제약 조건을 가장 잘 충족시킵니다.
- 고객이 회원 센터의 팀에 관리자 로 개발자를 초대합니다.
- 개발자가 초대를 수락합니다 (이메일에 있어야 함).
- 개발자는 Xcode의 오거나이저-> 장치 탭-> 프로비저닝 프로파일을 열고 오른쪽 하단에서 새로 고침을 누릅니다. 올바른 팀을 선택하고 몇 가지 새로운 항목을 받아야합니다.
- Xcode에서 코드 서명 ID 설정을 기본값으로 그대로 둡니다 (또는 iOS SDK의 경우 iPhone 개발자로 재설정).
- 앱 보관
- 오거나이저에서 아카이브를 마우스 오른쪽 단추로 클릭하고 Finder에 표시를 선택합니다.
- .xcarchive 파일을 클라이언트에 보냅니다.
- 클라이언트에 Xcode가 설치되어 있어야합니다.
- 클라이언트가 .xcarchive 파일을 두 번 클릭하여 오거나이저에서 열어야합니다.
- 클라이언트가 배포를 클릭하고 ID로 앱에 서명합니다.
- 이익
이를 위해서는 클라이언트가 developer.apple.com의 Member Center를 사용하고 Xcode를 약간 사용해야합니다 (그러나 오거나이저 만!). 고객이이 수준에서 기술적 인 기능 문제를 가지고있는 경우, 대신 처리하고 비용을 청구하는 것이 좋습니다. 개발자 로그인 및 비밀번호를 요청하고 마치 직원 인 것처럼 대신 행동하세요.
Ed 참고 : 키를 거래하는 것은 더 기술적이고 클라이언트에게는 관여하고 개발자에게는 더 위험하고 위험하기 때문에 끔찍한 타협입니다. 이 두 가지 더 나은 옵션을 고려할 때 옵션이 아닌 것으로 간주되어야합니다.
나는 같은 문제가 있었다. 이것이 내가 마침내 그것을 해결 한 방법이었습니다.
- 클라이언트가 개발 인증서를 생성했습니다 .
- 클라이언트 는 배포 프로비저닝 파일과 동일한 앱 ID를 사용하여 개발 프로비저닝 파일을 생성했습니다 .
- 클라이언트에서 내 보낸 개발 인증서 (.p12).
- 클라이언트가 .p12 파일과 개발 모바일 프로비저닝 파일을 보냈습니다.
- 클라이언트 p12 파일을 키 체인으로 가져 왔습니다.
- 클라이언트의 프로비저닝 파일을 Xcode로 가져 왔습니다.
- 클라이언트의 프로비저닝 파일을 사용하도록 빌드 구성에 대한 코드 서명 ID를 설정합니다.
- 앱을 보관했습니다.
- 나는 클라이언트에게 아카이브를 보냈다.
- 클라이언트는 배포 프로비저닝 파일로 앱에 서명하여 배포 빌드를 생성했습니다 . (그들은 테스트를 위해 내부적으로 앱을 배포했습니다.)
클라이언트는 배포 인증서를 공유하는 것처럼 개발 인증서 를 공유하는 데 그렇게 신경 쓰지 않았습니다 .
또한 entitlements.plist"디버깅 가능"(get-task-allow)을 NO로 설정하여 만들고 빌드 구성 (코드 서명, 코드 서명 권한 아래)에서 참조해야했습니다.
나는 당신이 원하는 것을 정확하게 할 수있는 방법을 찾았다 고 생각한다. 나는 광범위한 테스트를하지 않았거나 앱 스토어에 업로드하려고 시도하지 않았지만 내가 한 테스트에서 그것은 좋은 것 같다. 사임 및 프로비저닝 프로파일 추가는 수동 프로파일 설치없이 AdHoc 프로파일에 정의 된 내 장치에 설치할 수 있으므로 작동합니다. 두 번째 테스트는 xCode에서 동일한 번들 ID를 가진 앱의 iPad 및 iPhone 버전을 얻었습니다. 처음에는 iTunes에서 둘 다 가질 수 없었지만 사임 및 번들 ID 변경 후 둘 다 설치할 수있었습니다. 나는 또한 앱 이름을 변경해 보았는데, 그것은 장치와 iTunes에 새로운 이름으로 표시되었습니다. 아래는 내 스크립트이며 특정 앱을 사임하도록 설계되었으므로 프로필과 번들 ID가 하드 코딩됩니다. iPhone과 iPad 버전의 앱을 전환하여 스크립트에 매개 변수로 추가했습니다. 하지만 여러분은 제가 여기에있는 원칙을 취하고 스스로를 다듬을 수 있어야합니다.
이것의 배짱은 Dan의 Dev Diary에서 iOS를 사임하는 추가 모험 과 같은 기사를 기반으로하며 위에 나열된 Erica Sadun의 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"
가장 좋은 대안은 클라이언트에게 배포 인증서 개인 키를 .p12 파일로 내보내고 클라이언트에 대한 App Store 배포 빌드를 생성 할 수있는 배포 프로필과 함께 전송하도록 요청하는 것입니다.
행운을 빌어 요!!
감사합니다, 샘
좋아, 프로비저닝 프로파일 또는 인증서를 공유하지 않고 수행 할 수있는 방법을 찾았습니다 .
The idea is to insert a "run script" build phase to trick XCode into signing an App it didn't compile, so you can send a compiled (unsigned) App to the client, and then their XCode signs that App with their cert and profile.
How to do it:
Step 1: Make XCode generate an unsigned Release .app (I'll call this "App A"). See "To Disable Code Signing" here: https://stackoverflow.com/a/10171462/375486
Step 2: Create a new XCode iOS project and remove from it all build phases you can, so it creates an empty .app file (I'll call this "App B")
Step 3: Add a "run script" build phase to Project B which copies the contents of "App A" into "App B". In my case I used this:
cp -r A.app/* "$CODESIGNING_FOLDER_PATH"
Step 4: Send the "B" XCode project to the client, with all the necessary files.
Step 5: The client builds the B project. Under the hood, XCode will run the "run script" command, then sign the resulting app, and the client gets a perfectly signed App.
And that's it :)
iResign works quite well.
It allows you to change the bundle id and add entitlements when signing. Probably would work for your use case.
That being said, the xcarchive solution is more canonical. Be aware that sharing the xcarchive file gives them the dsym.
If you have any #ifdef DEBUG statements in your code, make sure they are disabled in the build you give them.
Huh, all these look way more complicated then they have to. I use this this:
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
I've been there. Options 2 or 3 are out of question. Option 4 would be ideal, but as you wrote, Apple will not let the agent delegate her privileges to create distribution profiles.
So basically, your only option is for you to get the distribution profile defined with their account. In order for you to handle it, you would need to login as their agent, which is not an option.
So they will have to do it. There is no way around that.
They will also have to invite you as a member of their product development team on their account. You will need to be an admin. That's mean you will have to send a signing certificate request as outlined by Apple.
Finally, they will have to download and send you the distribution provisioning profiles they created.
With all that, you will be able to sign your application with their resources.
I just got off the phone with Apple. They say this is the only way to do it: https://developer.apple.com/library/ios/#qa/qa1763/_index.html
The client adds you to their team, and gives you specific privileges.
'Programing' 카테고리의 다른 글
| 페이지 간 데이터 전달을위한 모범 사례 (0) | 2020.11.22 |
|---|---|
| MongoDB 대 MySQL (0) | 2020.11.22 |
| Java 8에서 "기능적 인터페이스"의 정확한 정의 (0) | 2020.11.22 |
| PHP 구성 : 시스템의 시간대 설정에 의존하는 것은 안전하지 않습니다. (0) | 2020.11.22 |
| 제네릭으로 인터페이스를 구현하는 Java 추상 클래스 (0) | 2020.11.22 |