可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
I currently build all my applications with hudson using xcodebuild followed by a xcrun without any problems
I\'ve received a couple of IPA files from different people that I would like to re-sign with a enterprise account instead of the corporate account (for the app store, or sometimes ad-hoc distributed).
My problem is that when I try to resign the app, it won\'t install on my device (and it should since it\'s a Enterprise build). The error message is on the device (not in iTunes) and it tells me simply that it couldn\'t install the app. No more information is given.
I\'ve found some information, ( http://www.ketzler.de/2011/01/resign-an-iphone-app-insert-new-bundle-id-and-send-to-xcode-organizer-for-upload/ )
And this might be possible. The problem I\'m facing is that it doesn\'t seem to embed the mobile provisioning profile as I do with my normal builds (using xcrun) is this possible to control with the codesign tool, or is it possible to re-sign with xcrun?
With my resign script i currently do
- unzip app.ipa
- appname=$(ls Payload)
- xcrun -sdk iphoneos PackageApplication -s \"$provisioning_profile\" \"$project_dir/Payload/$appname\" -o \"$project_dir/app-resigned.ipa\" --sign \"$provisioning_profile\" --embed \"$mobileprovision\"
I\'ve looked in the resulting ipa file and it seems to be very similar to the original app. What files should really change here? I initially thought the the _CodeSignature/CodeResources would change, but the content looks pretty much exactly the same.
Pointers are much appreciated.
回答1:
Finally got this working!
Tested with a IPA signed with cert1 for app store submission with no devices added in the provisioning profile. Results in a new IPA signed with a enterprise account and a mobile provisioning profile for in house deployment (the mobile provisioning profile gets embedded to the IPA).
Solution:
Unzip the IPA
unzip Application.ipa
Remove old CodeSignature
rm -r \"Payload/Application.app/_CodeSignature\" \"Payload/Application.app/CodeResources\" 2> /dev/null | true
Replace embedded mobile provisioning profile
cp \"MyEnterprise.mobileprovision\" \"Payload/Application.app/embedded.mobileprovision\"
Re-sign
/usr/bin/codesign -f -s \"iPhone Distribution: Certificate Name\" --resource-rules \"Payload/Application.app/ResourceRules.plist\" \"Payload/Application.app\"
Re-package
zip -qr \"Application.resigned.ipa\" Payload
Edit: Removed the Entitlement part (see alleys comment, thanks)
回答2:
The answers to this question are a little out of date and missing potentially key steps, so this is an updated guide for installing an app from an external developer.
----- How to Resign an iOS App -----
Let\'s say you receive an app (e.g. MyApp.ipa) from another developer, and you want to be able to install and run it on your devices (by using ideviceinstaller, for example).
Prepare New Signing Assets
The first step is to attain a Provisioning Profile which includes all of the devices you wish to install and run on. Ensure that the profile contains a certificate that you have installed in your Keychain Access (e.g. iPhone Developer: Some Body (XXXXXXXXXX) ). Download the profile (MyProfile.mobileprovision) so you can replace the profile embedded in the app.
Next, we are going to prepare an entitlements file to include in the signing. Open up your terminal and run the following.
$ security cms -D -i path/to/MyProfile.mobileprovision > provision.plist
This will create an xml file describing your Provisioning Profile. Next, we want to extract the entitlements into a file.
$ /usr/libexec/PlistBuddy -x -c \'Print :Entitlements\' provision.plist > entitlements.plist
Replace The Provisioning Profile and Resign App
If you are working with a .ipa file, first, unzip the app (if you have a .app instead, you can skip this step).
$ unzip MyApp.ipa
Your working directory will now contain Payload/
and Payload/MyApp.app/
. Next, remove the old code signature files.
$ rm -rf Payload/MyApp.app/_CodeSignature
Replace the existing provisioning profile (i.e. embedded.mobileprovision) with your own.
$ cp path/to/MyProfile.mobileprovision Payload/MyApp.app/embedded.mobileprovision
Now sign the app with the certificate included in your provisioning profile and the entitlements.plist that you created earlier.
$ /usr/bin/codesign -f -s \"iPhone Developer: Some Body (XXXXXXXXXX)\" --entitlements entitlements.plist Payload/MyApp.app
IMPORTANT: You must also resign all frameworks included in the app. You will find these in Payload/MyApp.app/Frameworks
. If the app is written in Swift or if it includes any additional frameworks these must be resigned or the app will install but not run.
$ /usr/bin/codesign -f -s \"iPhone Developer: Some Body (XXXXXXXXXX)\" --entitlements entitlements.plist Payload/MyApp.app/Frameworks/*
You can now rezip the app.
$ zip -qr MyApp-resigned.ipa Payload
Done
You may now remove the Payload
directory since you have your original app (MyApp.ipa) and your resigned version (MyApp-resigned.ipa). You can now install MyApp-resigned.ipa on any device included in your provisioning profile.
回答3:
I successfully followed this answer, but since entitlements have changed, I simply removed the --entitlements \"Payload/Application.app/Entitlements.plist\"
part of the second to last statement, and it worked like a charm.
回答4:
Checked with Mac OS High Sierra and Xcode 10
You can simply implement the same using the application iResign.
Give path of
1).ipa
2) New provision profile
3) Entitlement file (Optional, add only if you have entitlement)
4) Bundle id
5) Distribution Certificate
You can see output .ipa file saved after re-sign
Simple and powerful tool
回答5:
None of these resigning approaches were working for me, so I had to work out something else.
In my case, I had an IPA with an expired certificate. I could have rebuilt the app, but because we wanted to ensure we were distributing exactly the same version (just with a new certificate), we did not want to rebuild it.
Instead of the ways of resigning mentioned in the other answers, I turned to Xcode’s method of creating an IPA, which starts with an .xcarchive from a build.
I duplicated an existing .xcarchive and started replacing the contents. (I ignored the .dSYM file.)
I extracted the old app from the old IPA file (via unzipping; the app is the only thing in the Payload folder)
I moved this app into the new .xcarchive, under Products/Applications
replacing the app that was there.
I edited Info.plist
, editing
ApplicationProperties/ApplicationPath
ApplicationProperties/CFBundleIdentifier
ApplicationProperties/CFBundleShortVersionString
ApplicationProperties/CFBundleVersion
Name
I moved the .xcarchive into Xcode’s archive folder, usually /Users/xxxx/Library/Developer/Xcode/Archives
.
In Xcode, I opened the Organiser window, picked this new archive and did a regular (in this case Enterprise) export.
The result was a good IPA that works.
回答6:
With Fastlane sigh\'s resign option you can do this very easily.
sigh resign -p <path-to-profile-with-mobileprovision-ext> -i <code-sighning-identity-of-your-app>
You can download the profile using sigh also, just before the command.
回答7:
Thank you, Erik, for posting this. This worked for me. I\'d like to add a note about an extra step I needed. Within \"Payload/Application.app/\" there was a directory named \"CACertChains\" that contained a file named \"cacert.pem\". I had to remove the directory and the .pem to complete these steps. Thanks again! –
回答8:
If you have an app with extensions and/or a watch app and you have multiple provisioning profiles for each extension/watch app then you should use this script to re-sign the ipa file.
Re-signing script at Github
Here is an example of how to use this script:
./resign.sh YourApp.ipa \"iPhone Distribution: YourCompanyOrDeveloperName\" -p <path_to_provisioning_profile_for_app>.mobileprovision -p <path_to_provisioning_profile_for_watchkitextension>.mobileprovision -p <path_to_provisioning_profile_for_watchkitapp>.mobileprovision -p <path_to_provisioning_profile_for_todayextension>.mobileprovision resignedYourApp.ipa
You can include other extension provisioning profiles too by adding it with yet another -p option.
For me - all the provisioning profiles were signed by the same certificate/signing identity.