codesign

Possibly, but if Gatekeeper was unhappy with your app it should say so, not just cause the app to hang at launch.You can check what code signing and Gatekeeper think of your app with the following commands.$ codesign -vvv --deep /Applications/iTunes.app $ spctl --assess --raw /Applications/iTunes.appNote On 10.11 and later, also pass --strict to codesign. Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

OK, I understand standpoint of Apple.But it sounds bit strange and delicate.If Apple can recompile our binary, it means Apple can inject some unknown code into it. *We* cannot guarantee our executable as it is. This is why I said siging will be contract between users and developer. If Apple's codesigning dose not guarantees it, there must be some other way to do it, I think.

Error -34018 is not publicly documented but it translates to errSecMissingEntitlement. There are two causes of this error: build-time entitlement problemsa hard-to-reproduce runtime bugThe second problem is covered by a long-running thread elsewhere on DevForums. However, it sounds like you're hitting this problem every time, in which case you have a build-time problem. Run the following command over the app binary to confirm that it's built with the entitlements you're expecting.$ codesign -d --entitlements :- /path/to/your.appShare and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Duplicate of this question on StackOverflow: http://stackoverflow.com/questions/30963294/creating-ios-osx-frameworks-is-it-necessary-to-codesign-them-before-distributin

This is definitely new in beta 5; I had no problems linking in beta 4.I don’t think this is related to the framework binary being universal, as I thinned it with lipo and am still getting the same message:% lipo -info /Library/Frameworks/Growl.framework/Growl Non-fat file: /Library/Frameworks/Growl.framework/Growl is architecture: i386Ld /Users/nicholas/Library/Developer/Xcode/DerivedData/Pester-dmqwzzanlsudtshkfhcnikgvqgcr/Build/Products/Debug/Pester.app/Contents/MacOS/Pester normal i386 [...] ld: building for OSX, but linking in object file built for (unknown), file '/Library/Frameworks/Growl.framework/Growl' for architecture i386It looks like somehow the linker is expecting the OS information, not architecture, to be embedded in the binary and not finding it?I also saw some suggestions that this may be related to code signing, so I re-signed the framework but this did not appear to affect anything:% codesign -fvs '[...]' Growl.framework Growl.framework: replacing existing signature Growl.framework

You mention a test user. I wonder whether the same issue occurs with a new test user account. The addPayment call should only result in a single presentation of the StoreKit user authentication dialog. The only other StoreKit functions to trigger the presentation of the dialog isrestoreCompletedTransactions andSKReceiptRefreshRequest.I wonder if you can make the same issue happen by using the StoreKitSuite iOSInAppPurchase sample code<https://developer.apple.com/library/ios/samplecode/sc1991/Introduction/Intro.html#//apple_ref/doc/uid/DTS40014726>You can download the sample, set the application bundle ID to that of your app, and insert the in-app purchase identifiers in the productIDs.plist, and set the codesigning to your certificate, then run the sample.rich kubota - rkubota@apple.comdeveloper technical support CoreOS/Hardware/MFI