我如何生成一个我的客户端可以签名的iOS发布版本?

My scenario

我的场景

I wrote an iOS app for a client. The project is almost over and now it's time for them to put it in the App Store. I've been sending them development builds throughout the development process. Those builds had a bundle id based on my company and my client's project like so: com.mycompany.clientname.projectname. I signed those Ad Hoc builds with an Ad Hoc Distribution Provisioning Profile that I created in my own Provisioning Portal account.

我为一个客户写了一个iOS应用。这个项目快结束了，现在是时候把它放到App Store里了。在整个开发过程中，我一直在向他们发送开发构建。这些构建基于我的公司和我的客户的项目，比如com.mycompany.client .project . name。我使用我在自己的供应门户帐户中创建的一个临时分发供应配置文件签署了这些临时构建。

Now that it's time to go to the App Store, I need to do a Release Build and send that for them to sign with their own App Store Distribution Provisioning Profile. This also implies setting a new Bundle ID for the project.

现在是去App Store的时候了，我需要做一个发布构建，并将其发送给他们，让他们使用自己的App Store分发供应配置文件进行签名。这也意味着为项目设置一个新的Bundle ID。

My problem

我的问题

I need to get a compiled app to the client for them to sign with their provisioning profile. However, I need to set the Bundle ID to what they're going to use first. Let's say it's com.bestclientever.appname. Xcode 4 won't let me archive the project now because doing so requires code signing. I can not code sign it because I can not create a provisioning profile with the same Bundle ID as what they have set up in their Provisioning Portal (the Provisioning Portal enforces uniqueness—as it should).

我需要一个编译好的应用程序到客户端，让他们用配置文件签名。但是，我需要将Bundle ID设置为他们首先要使用的内容。假设它com.bestclientever.appname。Xcode 4现在不允许我归档项目，因为这样做需要代码签名。我不能对它进行编码，因为我不能创建一个配置文件，它的包ID与它们在配置门户中设置的相同(配置门户强制执行惟一性——应该是这样)。

Have I made any incorrect assumptions or misunderstandings here? ie. Do I really have to set the Bundle ID to what they're going to sign with?

我在这里做过错误的假设或误解吗?ie。我真的需要将Bundle ID设置为他们要签名的内容吗?

The Question

这个问题

Is there any way to archive, or otherwise build, an iOS app without code signing it? Like a "sign later" setting or something?

有没有什么方法可以存档或者构建一个没有代码签名的iOS应用程序?像是“后签”之类的设置?

Or, is there a way to build the app with one bundle id but then someone else be able to sign it with a provisioning profile for another bundle id (either by changing the bundle id of the compiled app or some other signing method)?

或者，是否有一种方法可以用一个bundle id来构建应用程序，但是其他人可以用另一个bundle id的配置文件(或者通过更改已编译应用程序的bundle id或其他签名方法)来签署它?

How can I build the final release build but have someone else sign the app for distribution to the App Store?

我如何构建最终的发布版本，却让别人在app Store上签名发布?

What I've tried or explored

我所尝试或探索的!

• Acting for the client.
  • With other, less savvy clients, I've ended up just getting their Provisioning Portal and iTunesConnect credentials and just doing the final build as them. That won't fly with this client. It's a big company with strict security guidelines and a lot of red tape.
  • 对于其他不那么精明的客户端，我最终只获得了它们的供应门户和iTunesConnect凭据，并作为它们执行最终的构建。这个客户不会同意的。它是一个大公司，有严格的安全指导方针和大量的繁文缛节。
• 代表客户端。对于其他不那么精明的客户端，我最终只获得了它们的供应门户和iTunesConnect凭据，并作为它们执行最终的构建。这个客户不会同意的。它是一个大公司，有严格的安全指导方针和大量的繁文缛节。
• Spoofing as the client.
  • This is similar to the one above and won't work for the same reasons. It sounds really fishy to ask my client "can you export your private keys and send them to me"? This technique is described in this answer: How can I send iOS app to client, for them to code-sign
  • 这与上面的类似，但由于同样的原因不会起作用。问我的客户“你能导出你的私钥并发给我吗?”这个技巧在回答中有描述:如何将iOS应用发送给客户端，让他们进行代码签名
• 欺骗客户。这与上面的类似，但由于同样的原因不会起作用。问我的客户“你能导出你的私钥并发给我吗?”这个技巧在回答中有描述:如何将iOS应用发送给客户端，让他们进行代码签名
• Sending the client my project source code and letting them do the release build.
  • A license to the source code was not in our agreement. Additionally, this client does not want to get involved with source code (hence outsourcing it). I would entertain this as a last-resort option, but there's gotta be a better way!
  • 我们的协议中没有源代码的许可。此外，此客户端不希望参与源代码(因此将其外包)。我想把这当作最后的选择，但肯定有更好的办法!
• 向客户端发送我的项目源代码并让他们进行发布构建。我们的协议中没有源代码的许可。此外，此客户端不希望参与源代码(因此将其外包)。我想把这当作最后的选择，但肯定有更好的办法!
• Getting set up as an Admin-level developer in their Developer Member Center.
  • Unfortunately, only the Agent-level user can create a Provisioning Profile (as far as I can tell). It seems like there ought to be a way to either let me create a profile that I can use to sign the build or generate a profile for me. I can't find either option.
  • 不幸的是，只有代理级别的用户才能创建配置文件(据我所知)。似乎应该有一种方法，要么让我创建一个可以用来签名构建的概要文件，要么为我生成概要文件。我找不到任何一个选项。
• 在开发人员成员中心中设置为管理员级别的开发人员。不幸的是，只有代理级别的用户才能创建配置文件(据我所知)。似乎应该有一种方法，要么让我创建一个可以用来签名构建的概要文件，要么为我生成概要文件。我找不到任何一个选项。

10 个解决方案

#1

Most of these answers seem complicated and out dated. I think the simple answer is to make an archive with a Developer profile.

大多数的答案似乎都很复杂，过时了。我认为简单的答案是使用开发人员配置文件创建一个存档。

This is a solution which I am currently investigating for my own purposes (not fully tested):

这是我目前正在研究的一种解决方案(尚未完全测试):

You just need developer access (not team agent) to their account and create a Development provisioning profile that authorizes you to build the specified App ID (you need to specify the App ID, because it gets compiled in). Then Archive the app with the Development profile, and share the archive with your client. They can then re-sign the archive with their own Distribution profile.

您只需要开发人员访问他们的帐户(而不是团队代理)，并创建一个开发配置文件，授权您构建指定的应用程序ID(您需要指定应用程序ID，因为它被编译)。然后将应用程序与开发概要文件归档，并与客户共享存档。然后，他们可以用自己的发行文件重新签署归档文件。

One complication is that when you build an archive with a developer profile, the entitlement attribute get-task-allow gets set to true, but needs to be set to false for distribution, so you have to work around that by setting it manually your Entitlements.plist - see my question here: Can I archive with a Developer certificate, then re-sign it during submission with a Distribution certificate?

一个复杂的问题是，当您使用一个开发人员概要构建一个归档时，权限属性get-task-allow被设置为true，但是需要设置为false用于分发，所以您必须通过手动设置您的权限来解决这个问题。plist——请参见我的问题:我可以使用开发人员证书进行归档，然后在提交过程中使用发布证书重新签名吗?

#2

I just confirmed at WWDC 2012 that the following technique works. It best satisfies my constraints of little client involvement, low client expertise, a simple signing process, and source code ownership.

我刚刚在2012年WWDC上确认以下技术是有效的。它最能满足我的约束:很少的客户参与、较低的客户专业知识、简单的签名过程和源代码所有权。

1. Client invites developer to their team in the Member Center as an Admin
2. 客户以管理员的身份邀请开发人员到成员中心的团队中
3. Developer accepts the invite (should be in your email)
4. 开发人员接受邀请(应该在您的电子邮件中)
5. Developer opens Xcode's Organizer -> Devices Tab -> Provisioning Profiles and hits Refresh in the lower-right corner. Make sure you choose the right team and you should get a few new items.
6. Developer打开Xcode的组织者—>设备选项卡—>供应配置文件并在右下角点击Refresh。确保你选择了正确的团队，你应该得到一些新的项目。
7. In Xcode, leave Code Signing Identity settings to their default values (or reset them to iPhone Developer for Any iOS SDK)
8. 在Xcode中，将代码签名身份设置保留为默认值(或将其重置为任何iOS SDK的iPhone Developer)
9. Archive the app
10. 归档应用程序
11. In Organizer, right-click the archive and select Show in Finder
12. 在组织者中，右键单击存档并在Finder中选择Show。
13. Send the .xcarchive file to your client
14. 将.xcarchive文件发送给您的客户
15. Client must have Xcode installed
16. 客户端必须安装Xcode
17. Client double-clicks the .xcarchive file which should open it in Organizer
18. 客户端双击应该在管理器中打开的.xcarchive文件
19. Client clicks Distribute and signs the app with their identity
20. 客户点击“分发”并在应用程序上签名
21. Profit
22. 利润

This does require the client to use the Member Center on developer.apple.com and to use Xcode a little bit (but just the Organizer!). If your client has technical capability problems at this level then I recommend just taking over and doing it for them (and charging for it!). Ask for their developer login and password and just act on their behalf as if you were an employee.

这确实需要客户端使用developer.apple.com上的成员中心，并稍微使用Xcode(但只使用组织者!)如果您的客户在这个级别上有技术能力问题，那么我建议您接管并为他们做这件事(并为此收费!)询问他们的开发人员登录名和密码，就像你是员工一样代表他们行事。

Ed note: Trading keys around is a terrible compromise because it's more technical and involved for the client and more hacky and risky for the developer. It should be considered a non-option given these two better options.

交易钥匙是一种可怕的妥协，因为它对客户来说更有技术含量，也更复杂，对开发人员来说更危险。考虑到这两个更好的选择，它应该被认为是不可选的。

#3

I had the same problem. This was how I finally solved it:

我也有同样的问题。我就是这样解决的:

1. Client created a development certificate.
2. 客户端创建了一个开发证书。
3. Client created a development provisioning file using the same App ID as the distribution provisioning file.
4. 客户端使用与分发准备文件相同的应用程序ID创建一个开发准备文件。
5. Client exported development certificate (.p12).
6. 客户端导出开发证书(.p12)。
7. Client sent me the .p12 file and the development mobile provisioning file.
8. 客户端给我发送了.p12文件和开发移动配置文件。
9. I imported the clients p12 file into my keychain
10. 我将客户端p12文件导入到我的密钥链中
11. I imported the client's provisioning file into Xcode.
12. 我将客户端准备文件导入到Xcode中。
13. Set the code signing Identity for my build configuration to use the client's provisioning file.
14. 为我的构建配置设置代码签名标识，以使用客户端配置文件。
15. I Archived the app.
16. 我归档应用程序。
17. I Sent the Archive to the client.
18. 我将归档文件发送给客户端。
19. The client created their distribution build by signing the app with their distribution provisioning file. (They were distributing the app internally for testing.)
20. 客户端通过向应用程序签名分发准备文件来创建他们的分发构建。(他们在内部发布这款应用进行测试。)

The client was not so concerned with sharing a development certificate as they would be sharing their distribution certificate.

客户端不太关心共享开发证书，而更关心共享分发证书。

I also had to create entitlements.plist with "Can be debugged" (get-task-allow) set to NO, and reference it in the build configuration (under Code Signing, Code Signing Entitlements).

我还必须创造权利。plist的“Can be debug”(get-task-allow)设置为NO，并在构建配置(在代码签名、代码签名权限下)中引用它。

#4

I believe I have found a way to do exactly what you want, I haven't done extensive testing or tried to upload to the app store but from the testing I have done it seems to be good. The resign and the addition of my provisioning profile is working as I can install it on my devices defined in the AdHoc profile with no manual profile installation needed. Second test was I got an iPad and an iPhone version of an app with the same bundle ID from xCode, at first I could not have both in iTunes but after the resign and bundle ID change I was able to have both installed. I also tried changing the app name and that worked as well, it showed on the device and in iTunes with the new name. Below is my script, it's designed to resign a specific app for me, so the profile and bundleID are hardcoded. I flip between an iPhone and iPad version of the app so I added that as a parameter to the script. But you should be able to take the principles I have here and refine them for yourself.

我相信我已经找到了一种方法来做你想做的事情，我没有做过大量的测试，也没有尝试过上传到应用商店，但是从我的测试来看，我做的似乎很好。我的准备配置文件的辞职和添加是工作的，因为我可以将它安装在我的设备上，这些设备是在临时配置文件中定义的，不需要手动配置文件。第二个测试是，我有一个iPad和一个iPhone版本的应用程序，它与xCode的捆绑ID相同，一开始我不能同时在iTunes上使用，但在辞职和捆绑ID更改之后，我可以同时安装两个。我也尝试过改变应用程序的名字，这也很有效，在设备上和iTunes上都有新的名字。下面是我的脚本，它为我设计了一个特定的应用程序，所以配置文件和bundleID都是硬编码的。我在iPhone和iPad版本的应用程序之间切换，所以我把它作为参数添加到脚本中。但你应该能够采纳我这里的原则，并为自己完善它们。

The guts of this builds upon articles like Further adventures in resigning for iOS from Dan's Dev Diary and very similar to Erica Sadun's App Signer listed above. The main addition I made was the editing of the Info.plist prior to resigning.

这篇文章的核心是建立在一些文章的基础之上的，比如从Dan的开发日记中退出iOS的进一步冒险，和上面列出的Erica Sadun的App Signer非常相似。我做的主要是编辑信息。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"

#5

Best alternative way would be to ask the client to export his distribution certificate private key into .p12 file and send it across to you alongwith the distribution profile with which you can generate a App Store distribution build for your client.

最好的替代方法是让客户将他的发行证书私钥导出到.p12文件中，并将其发送给您，并与您可以为您的客户端生成应用程序商店发行版的发行配置文件一起发送。

Best of luck!!

好运! !

Regards, Sam

问候,山姆

#6

Ok, found a way to do it without sharing provisioning profiles or certificates.

好的，找到了一种不共享配置文件或证书的方法。

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.

这个想法是要插入一个“运行脚本”构建阶段，以欺骗XCode来签署一个未编译的应用程序，这样你就可以将一个编译好的(未签名的)应用程序发送给客户端，然后他们的XCode用他们的cert和配置文件显示应用程序。

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://*.com/a/10171462/375486

第一步:让XCode生成一个unsigned Release . App(我称之为“App A”)。参见“禁用代码签名”:https://*.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")

步骤2:创建一个新的XCode iOS项目，并从其中删除所有可以构建的阶段，因此它创建一个空的.app文件(我称之为“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:

步骤3:在项目B中添加“运行脚本”构建阶段，将“App a”的内容复制到“App B”中。在我的例子中，我使用了这个:

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

Step 4: Send the "B" XCode project to the client, with all the necessary files.

步骤4:将“B”XCode项目连同所有必要的文件发送给客户端。

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.

步骤5:客户端构建B项目。在引擎盖下，XCode将运行“run script”命令，然后对生成的应用程序进行签名，客户端将获得一个完全签名的应用程序。

And that's it :)

就是这样:)

#7

iResign works quite well.

iResign工作得很好。

It allows you to change the bundle id and add entitlements when signing. Probably would work for your use case.

它允许您在签名时更改bundle id并添加权限。可能对您的用例有用。

That being said, the xcarchive solution is more canonical. Be aware that sharing the xcarchive file gives them the dsym.

也就是说，xcarchive解决方案更规范。注意，共享xcarchive文件会给它们dsym。

If you have any #ifdef DEBUG statements in your code, make sure they are disabled in the build you give them.

如果您的代码中有任何#ifdef调试语句，请确保在您所提供的构建中禁用它们。

#8

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.

我去过那里。选项2或3是不可能的。选项4是理想的，但是正如您所写的，苹果不会让代理委托她的特权来创建发行配置文件。

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.

有了这些，您就可以使用它们的资源来签署应用程序了。

#9

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

我刚和苹果公司通完电话。他们说这是唯一的方法:https://developer.apple.com/library/ios/#qa/qa1763/_index.html

The client adds you to their team, and gives you specific privileges.

客户端将您添加到他们的团队，并给予您特定的特权。

#10

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