codesign

In which folder should the provisioning profile be located?The entitlements are baked into the code signature. You can dump them using:$ codesign -d --entitlements :- /path/to/your.appIf the app has embedded code (like a helper tool, a framework, or an extension), you should check the entitlements of those separately.Keep in mind that the provisioning profile is just one input into the code signing machinery, and the output of that machinery includes these entitlements. IMO it’s best to start by looking at the output and working back from there. I recently posted about this in a different context, but there’s also formal documentation on the subject in the form of Technote 2415 Entitlements Troubleshooting.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Hi Quinn,Thanks for your help. Using codesign --d --entitlements gives the following output:<?xml version=1.0 encoding=UTF-8?> <!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd> <plist version=1.0> <dict> <key>com.apple.application-identifier</key> <string>[ID].org.[COMPANY].[GAMENAME]</string> <key>com.apple.developer.game-center</key> <true/> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.network.client</key> <true/> </dict> </plist>Which, as far as I can tell, is exactly what it should be. I've checked all the other frameworks, etc. inside the bundle and they are all giving the same output.Thank you for posting links to the documentation. I've had a read through, but they mostly concern dealing with problems if the above output isn't correct. As far as I can tell, it is. Am I missing anything? Can you think of a

I’m having this same problem! I don’t understand it – like you, the output from codesign and spctl both looks good and says it’s valid and accepted.Did you ever solve this?

I solved create Developer ID problem, cause only team agent can create Developer ID.My acount is admin permission, so that will always not display the option in website. So I asking my colleague who has agent to create kext-enable Developer ID. But it build fails with kext-enable Developer ID. Error message:timestamps differ by 808 seconds - check your system clock Command /usr/bin/codesign failed with exit code 1Somebody help, please.

It sounds like you're not signing your framework (and possibly app) correctly. You should inspect the output of 'codesign -vvv /path/to/Company.framework' and 'codesign -vvv /path/to/My.app'

You can codesign from the command line if you like. man codesign for details

Please provide the output of running codesign as suggested.

Hi Jeremy,My apologies for the delayed response.Here are the codesign outcomes (with associated commands):App:$ codesign -vvv /Users/indigo/Library/Developer/Xcode/DerivedData/LibraryTesting-azmocmdalqwlfochyihtxugfcdhs/Build/Products/Debug-iphoneos/LibraryTesting.app /Users/indigo/Library/Developer/Xcode/DerivedData/LibraryTesting-azmocmdalqwlfochyihtxugfcdhs/Build/Products/Debug-iphoneos/LibraryTesting.app: valid on disk /Users/indigo/Library/Developer/Xcode/DerivedData/LibraryTesting-azmocmdalqwlfochyihtxugfcdhs/Build/Products/Debug-iphoneos/LibraryTesting.app: satisfies its Designated RequirementFramework in app:$ codesign -vvv /Users/indigo/Library/Developer/Xcode/DerivedData/LibraryTesting-azmocmdalqwlfochyihtxugfcdhs/Build/Products/Debug-iphoneos/LibraryTesting.app/Frameworks/Company.framework/ /Users/indigo/Library/Developer/Xcode/DerivedData/LibraryTesting-azmocmdalqwlfochyihtxugfcdhs/Build/Products/Debug-iphoneos/LibraryTesting.app/Frameworks/Company.framework/: valid on d

Same here. iPhone 6, iOS 9.2 (13C75), using Alamofire and AlamofireImage. I’m working in Swift, with a Keychain struct I created myself.After three or four retrievals (it’s pretty consistent), SecItemCopyMatching returns -34018. (See Keychain.password(), below; the error hits at the call to SecItemCopyMatching().) Resetting the password during the run of the app does not help; killing and restarting it clears the error for another three or four cycles, which I don’t have to say is unacceptable. The stored password is still there; Keychain.password() returns it as expected. The bug manifests even if no other SecItem* call is made.(I see I don’t release returnPointer in that func; I’ll correct that in my own copy. I don’t think it should affect the bug, it’s just an 8-byte leak. I’m leaving the fix out of this listing to preserve my example.)I use the password by embedding a hash in the body of my transactions. (I use POSTs or PUTs, even in cases that would ordinarily use GETs.) I don’t claim this is what an ex