I have many helper apps included in a project. When I have to deep sign the app with App Wrapper it takes a REALLY long time to do so since I had to turn off the use Apples temporary signing engine thing, but App Wrapper does do a good deep code sign which I THINK is necessary for notarizing?
Most of the helper apps do not change very often. Is it possible to pre-sign the helper apps and have that copied into the app during the same copy phase of compilation that copies the executables? And if I were to do that would App Wrapper be smart enough to know that they were already signed and not just re-sign them anyway? Im not sure how to even test that as Ive never delved into the depth of code signing and notarization. It would be nice to cut down the time it takes to wrap it though.
@James Sentman App Wrapper is certainly useful to submit apps on the Mac App Store but are you sure you need it every time you build your app? Maybe a simple script to sign your app would be enough and could take much less time
Definitely dont need it every time I run the app. When I build it though its generally for moving to a testing server. Since the app needs to send apple events and the new cruelness of the OS Security level shuts those down completely unless its signed. So testing on my development machine is fine, but testing on the server with actual data is not possible without wrapping first.
If I may capture your thread and add a very similar question:
I have an application where AppWrapper fails because of a helper app using an unsigned third party library. (@Sam Rowlands knows about it and is working on a fix.)
Is it possible to pre-sign this framework manually so that code signing does not fail?
@James Sentman Well you may need only a simple script to sign your application. This is what I use:
[code]//# Sign app
dim appPath as String
appPath = CurrentBuildLocationNative + “/” + CurrentBuildAppName + “.app”
// First, clear xattr (finderInfo) which are not supported by codesign
dim command as String
command = “/usr/bin/xattr -cr “”” + appPath + “”""
dim result as string = DoShellCommand( command )
if result<>"" then
Print( "[xattr]: " + result )
return
end if
// Find entitlements
dim entitlementsPath as string
entitlementsPath = “<PATH_TO_ENTITLEMENTS_FILE>”
// Then codesign
command = “codesign -f --deep --entitlements “”” + entitlementsPath + “”" -s “”"" “”" + appPath + “”""
result = DoShellCommand( command )
if result<>"" then
Print( "[codesign]: " + result )
end if[/code]
and I prefer to use my email address as my Apple ID
If you turn off the Use Apples Temporary Engine setting. Which if you havent played with it yet is an option youll find if you click the gear icon to the right of where you select which identity to use for signing in AppWrapper. Then it will do a deep sign, so will sign everything inside the package and not just the top level executable. I would imagine that this would also sign any libraries or anything else executable or linkable inside the app, but I am not sure about that and have no way to test it at the moment.
I will experiment with that as well, thank you!
The answer is it can be done; but App Wrapper doesn’t check each executable before it signs (that would slow it down even more), on the “Other” pane in the App Wrapper editor, there is a “Fine Grain” (I forget what it’s called) list. Click on the “+” icon at the bottom and then navigate through the package to the the executable to ignore. Once it’s in the list, you have the option to tell App Wrapper to ignore this executable.
Edit: There is a help topic in App Wrapper called “Fine grained control over files” and this will also explain how to use this function.
Thank you Sam, Ive never used that fine grained control as I wasnt sure exactly what capabilities it gave me. Ill experiment 
Without App Wrapper Id have a lot more grey hair 
Fantastic app I would not want to live without! Doubly so now with Notarization adding yet more steps.
You’re welcome James. Instead I’m collecting the gray hair and beard for y’all 
Yes, if you follow the steps that I shared with James, it should work.
However… I am hoping towards the end of this week or early next week to start beta testing App Wrapper 3.10 with my new blackBird engine. It should be very similar in terms of performance to using the temporary Apple engine, however its more thorough on collecting the correct files, and is very strict on the order of signing. In my tests with the prototype on an application with a 130 files that needed signing, blackBird performed it within 45 seconds, 2.8x faster than my previous engine (in theory it should be able to go much faster for debug builds as secure time stamping isn’t required) and it included the files that Apple’s temp engine missed. My challenge now is to get this into App Wrapper…