jamplus/jamplus — pull request #20 by Scraft (2014-03-08 11:56:33+00:00)
Title: If Xcode is configured to not require code signing/provisioning then set...

With Xcode 5, by default it insists on code signing/provisioning builds. The problem with this is JamPlus handles the provisioning/code signing, and outputs a ready to deploy .app file, Xcode then goes ahead and resigns and provisions the build, this means next time JamPlus goes to build, it seems the build has been modified and resigns and provisions the build. The output you get is along the lines of:

1. First build; finished with C._CodeSign followed by Xcode's provision/package/sign.

> Project Game | Configuration iphone - debug | Destination Steven’s iPod touch | SDK OS X 10.9
> Run custom shell script ‘Run Script’
[…]
@ C._CodeSign CodeResources
*** updated 2 target(s)…
*** finished in 3.72 sec
> ProcessProductPackaging /path/to/provision
> ProcessProductPackaging /path/to/Entitlements
CodeSign Game.app …in /path/to/game

2. Start another build immediate after, JamPlus has to sign build again.

> Project Game | Configuration iphone - debug | Destination Steven’s iPod touch | SDK OS X 10.9
> Run custom shell script ‘Run Script’
[…]
@ C._CodeSign CodeResources
*** updated 2 target(s)…
*** finished in 3.72 sec

This annoying behaviour of Xcode can thankfully be disabled, this is done by modifying /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/SDKSettings.plist and changing the DefaultProperties:CODE_SIGNING_REQUIRED and DefaultProperties:ENTITLEMENTS_REQUIRED to NO.

This pull request will detect if the above plist change has been made (I'd recommend everyone makes this modification, as it makes the workflow better), if the change is detected the Xcode workspace is generated with no entitlements and signing identify set. In this scenario when you build JamPlus generates a ready to deploy .app, Xcode doesn't alter this app, and subsequent build/deploys do not require JamPlus to sign the build again. If the plist change isn't detected, then existing behaviour will be preserved.