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
ResourceRules.plist
file (they’ll either tell you directly, or you’ll get notified regarding signature issues regarding your submitted archive)PackageApplication
bundled with Xcode to remove the usage of the deprecated --resource-rules
option for the codesign command (do this with great care and remember to backup the original script) 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:
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
The resulting path will mostly yield the following path
Now, find the lines including the following code in the script
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:
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.