If you, like myself, tend to be a part of projects where we’re delivering several builds of an iOS app, this blogpost might concern you. Up until now, Apple has allowed you to specify which parts of your archive should be signed, but this has changed a while ago.
This blogpost aims to bring you knowledge of what you can do to get your build process working again.
TL;DR
- If you build and upload using Xcode’s UI, this blogpost is not intended for you, since you’re not affected
- Apple will reject apps and updates hereof if the submitted archive contains a
ResourceRules.plistfile (they’ll either tell you directly, or you’ll get notified regarding signature issues regarding your submitted archive) - You can change the perl script
PackageApplicationbundled with Xcode to remove the usage of the deprecated--resource-rulesoption for the codesign command (do this with great care and remember to backup the original script) - If you use 3rd party applications to build and upload your app to either TestFlight or App Store, you might also be affected by this issue.
Explanation
In Yosemite, the --resource-rules option is deprecated (obsoleted in Mavericks), and it’s one of the scripts Apple include in the Xcode bundle. In our use case, we do a codesign after the app has been archived, and the thing to note is the PackageApplication script which amongst other things signs the app.
The PackageApplication script will fail with an error and warning:
Warning: --resource-rules has been deprecated in Mac OS X >= 10.10! error: /usr/bin/codesign --force --preserve-metadata=identifier,entitlements,resource-rules --sign foo —resource-rules=/path/to/foo/bar.app failed with error 1
If you getting this error, then you’re missing the Code Signing Resource Rules Path build setting for the target you’re building. If you try to ask e.g StackOverflow about this error, you’ll most likely end up with a solution that tells you to set the missing setting to something like $(SDKROOT)/ResourceRules.plist.
This will get rid of the error, since the resource-rules parameter now points to an actual ResourceRules.plist file, but will however result in your app getting rejected, since Apple won’t allow the ResourceRules.plist to be included anymore.
Solution
My suggestion for a solution is not a great one, nor is it a permanent one – I’ll explain in the end.
First, locate and backup the script PackageApplication, e.g with the command
xcrun -sdk iphoneos -f PackageApplication
The resulting path will mostly yield the following path
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/PackageApplication
Now, find the lines including the following code in the script
...
my @codesign_args = ("/usr/bin/codesign", "--force", "--preserve-metadata=identifier,entitlements,resource-rules",
"--sign", $opt{sign},
“--resource-rules=$destApp/ResourceRules.plist");
Here you can see the --resource-rules option which is deprecated. For the sake of backwards compatibility, and development of OS X apps, I’ll recommend a solution that excludes the --resource-rules option if nothing is specified in the Code Signing Resource Rules Path path for your target.
Replace this code with the following:
...
my @codesign_args;
if (-e '$destApp/ResourceRules.plist') { # If ResourceRules.plist exists, include it in codesign arguments, for backwards compatability
@codesign_args = ("/usr/bin/codesign", "--force", "--preserve-metadata=identifier,entitlements,resource-rules",
"--sign", $opt{sign},
"--resource-rules=$destApp/ResourceRules.plist");
} else { # If ResourceRules.plist isn't found, don't include it in the codesign arguments
@codesign_args = ("/usr/bin/codesign", "--force", "--preserve-metadata=identifier,entitlements",
"--sign", $opt{sign});
}
This change to the script requires your Code Signing Resource Rules Path parameter to be blank in Xcode to have the desired effect. When you try to run your script again, you will now see that neither the warning nor the error will occur, and you’re now one step closer to submitting you app or update.
Thoughts
I generally won’t recommend editing scripts bundled with Xcode, and my opinion towards this is that Apple should fix it, not us the developers. But until then, this is one approach to getting the job done. Or, since one could get the assumption that Apple doesn’t really care about us developers in these kinda projects, you could change your entire building process.
If you adopt this hack, please be aware that you have to do the script change every time you update Xcode, since the script will be overwritten then.
If you don’t want to handle both scenarios, (where the ResourceRules.plist exists and where it doesn’t) you could simply modify the script to not include resource-rules and --resource-rules=$destApp/ResourceRules.plist in the @codesign_args. Simply delete those, and the script will work as well.
My final advice is that you retain a copy of both the original script and the modified one – how is up to you.
use shell :
Warning: default usage of –preserve-metadata implies “resource-rules” (deprecated in Mac OS X >= 10.10)!
Thank you, this was tremendously helpful!
Sad part is here we are with XCode 8 just released, and it still has this problem…. :(
Thanks for the article.
thanks very very very much
Hi Can some body help me to how to use above workaround….I am using Xcode 8 and Swift3.0 and trying to build the iOS application using below command
– xcodebuild -project $TRAVIS_XCODE_PROJECT -scheme $TRAVIS_XCODE_SCHEME -sdk $TRAVIS_XCODE_SDK -configuration “$APP_BUILD_ENV” OBJROOT=”$PWD/build” SYMROOT=”$PWD/build” ONLY_ACTIVE_ARCH=NO | xcpretty -c
I am not understanding how to use above workaround.
Thanks in advance.
Hi Nitesh
It’s hard to help when I don’t know what you can’t understand in the above workaround, I can only suggest you take your time and read it throughly. And remember that the post was written when Yosemite was the most recent macOS.
HI Jimmie,
Thank you for you reply in this blog it’s explained about perl script where as I am using shell script with below line of code.
– xcodebuild -project $TRAVIS_XCODE_PROJECT -scheme $TRAVIS_XCODE_SCHEME -sdk $TRAVIS_XCODE_SDK -configuration “$APP_BUILD_ENV” OBJROOT=”$PWD/build” SYMROOT=”$PWD/build” ONLY_ACTIVE_ARCH=NO | xcpretty -c
I understand we have to add something line below in my script :
{ # If ResourceRules.plist isn’t found, don’t include it in the codesign arguments
@codesign_args = (“/usr/bin/codesign”, “–force”, “–preserve-metadata=identifier,entitlements”,
“–sign”, $opt{sign});
}
The main issue is what will be the order of above flags/command in my Xcodebuild command.
thank you in advance.
Hi Nitesh
This is not to be added in your script. Sounds like the problem lies within your build command as you say, as you yourself state. I would then argue that this post is not a relevant place to ask the issue, since it’s mainly concerned with fixing one of the scripts Apple bundle with Xcode itself.
I would recommend StackOverflow as a possible site to ask your question(s) about the issues at hand.
Hi Jimmie,
I am not able to edit or save PackageApplication file. I want to automate Xcode build . I am using Xcode 8.1 and Mac OS 10.12.
I am getting the below error in Jenkins:
error: /usr/bin/codesign –force –preserve-metadata=identifier,entitlements,resource-rules –sign iPhone Distribution: Company Name (XXXXXXXXXX) –resource-rules=/var/folders/24/fw6633nj7l310dlqcd3r67600000gp/T/HPngq5Ljzg/Payload/AppName.app/ResourceRules.plist –entitlements /var/folders/24/fw6633nj7l310dlqcd3r67600000gp/T/HPngq5Ljzg/entitlements_plistUgkTGfaE /var/folders/24/fw6633nj7l310dlqcd3r67600000gp/T/HPngq5Ljzg/Payload/AppName.app failed with error 1. Output: Warning: usage of –preserve-metadata with option “resource-rules” (deprecated in Mac OS X >= 10.10)!
Warning: –resource-rules has been deprecated in Mac OS X >= 10.10!
/var/folders/24/fw6633nj7l310dlqcd3r67600000gp/T/HPngq5Ljzg/Payload/AppName.app/ResourceRules.plist: cannot read resources
Failed to build /Users/iosdeveloper/.jenkins/workspace/remit_ios_app/build-dir/${PROJECT_DIR_NAME}-11.ipa
Build step ‘Xcode’ marked build as failure
Finished: FAILURE
Hi Ganesh
This post was written back when macOS was still called OSX and in version 10.9, so things has probably changed. If applicable, I would suggest looking into fastlane tools or similar.
Otherwise, I would suggest you to look into ownership of the directory by using the terminal and adjust it by using either of the commands chown or chmod, whatever you think is right for you.
Once again setting up a new machine and using this guide to fix XCode…
Why Apple doesn’t address this I’ll never know, but a big thank you for writing such a clear and understandable article. While written for Yosemite and what, XCode 5? 6? the instructions are still clear and perfectly accurate for Sierra and Xcode 8.2.
I’m glad that the guide helped you once more Andy, and I agree completely – how is this still a problem? I would guess that Apple thinks we the developers rely on e.g fastlane or similar tools.
Hi Jimmie! Seems that in Xcode 8.3.1 the PackageApplication file is missed. Any clue why or where is located now?
Thanks in advance, cheers!
Carmelo
Hi Carmelo
Thank you for bringing this to my attention — it seems that the script PackageApplication is now removed for good.
It figured as deprecated in Xcode 8.2, so I guess now was the time for it to disappear according to Apple.
I suggest you look into the xcodebuild paramter “-exportArchive” as a replacement.
Best regards,
Jimmie