[quote=117705:@Christoph De Vocht]@Joe:
It would be nice if you could add a new Destination for copying files after the build. MacOS folder is not available in the dropdownmenu.[/quote]
File a feature request in Feedback if you’d like to see this added.
I just ran my oldest app in the App Store, that was signed under 10.8.5 with App Wrapper Mini. It seems to execute fine and did not trigger any warning from GateKeeper. But I have a doubt, now. If it is anything like unsigned apps, the system I upgraded from “knew” the app. Is it possible that now even if the app was not signed at all it would recognized by 10.9.5 ?
Is there a way to make Mac OS X forget apps that where once run, in order to test ?
Now, a question for Sam Rowlands : can I use App Wrapper to sign the executables that where produced by App Wrapper Mini and 10.8.5 ? Hope the answer is yes – That would save me the recompile step.
Just code signed an app with Appwrapper and looked at the log. It seems it is not using --deep
Sam? Can you take a look at this? And if needed, add this option?
If you want, I can download your app and see if it works here with DP5. A download link would be fine.
[quote=117708:@Michel Bujardet]Now, a question for Sam Rowlands : can I use App Wrapper to sign the executables that where produced by App Wrapper Mini and 10.8.5 ? Hope the answer is yes – That would save me the recompile step.
[/quote]
Got my answer. Just tried and AW says “already code signed”, so it is not possible 
I just got the answer from App Wrapper. It says :
Gatekeeper validation
Rejected
Which means I have to sign again with 10.9.5. Thank you for the offer, though.
For anyone interested, Apple updated their command line tools yesterday. “Command Line Tools (OS X 10.9) for Xcode - August 2014” is now available.
[quote=117705:@Christoph De Vocht]@Joe:
It would be nice if you could add a new Destination for copying files after the build. MacOS folder is not available in the dropdownmenu.[/quote]
There is “App Parent Folder” which is different than “Bundle Parent Folder” on OS X
The name just isn’t “MacOS” as it applies equally x-platform
See User Guide - Framework page 206
Just indicate MacOS as a subfolder in Content 
App Wrapper has it’s own engine which was designed and built before Apple added the -deep option. They both do the similar task of scanning the application bundle and code signing contained executable code. Although they both operate to different rules. The App Wrapper one works sometimes where -deep doesn’t and vice versa. A forthcoming update to App Wrapper has the third generation engine, which so far in my tests; is doing a better job than AW 2 or -deep.
In the App Wrapper preferences, you can change the engine from App Wrapper to “Mavericks” which will make App Wrapper use the -deep option instead of it’s own engine.
Hold down the option key as you drag the signed application into App Wrapper.
The Apple document posted yesterday has caused a great deal of confusion over Code Signing, which is why I started this thread. To help clear it up.
Use App Parent folder as that already IS Contents / MacOS for an app bundle
Really
See the post right above your where I already said this
Thanks for linking to this Technote. It highlights several things that I’d like to re-iterate.
‘Nested Code’ or ‘Contained Executables’
Contents Top content directory of the bundle
Contents/MacOS Helper apps and tools
Contents/Frameworks Frameworks, dylibs
Contents/PlugIns Plug-ins, both loadable and Extensions
Contents/XPCServices XPC services
Contents/Helpers Helper apps and tools
Contents/Library/Automator Automator actions
Contents/Library/Spotlight Spotlight importers
Contents/Library/LoginItems Installable login items
So it would seem that unix executables (and other apps) can be placed within ‘MacOS’ or ‘Helpers’ folder.
When -deep first appeared, an Apple engineer told me that it was only a temporary solution until another solution was put in place (presumably in Xcode). In the Technote Apple do advise against using -deep to code sign applications.
Sam, I am just in the process of submitting a new app. I am confused. Is it OK to use the Maverick codesign which employs --deep, or is it preferable to use App Wrapper Codesign engine 2.00 ?
Which is better ?
I’ll be waiting for your advice before proceeding, for fear of a rejection.
They both have different rules as to what constitutes an executable. The only major difference is that I control the code for the App Wrapper engine and Apple control the --deep function. Ideally if it fails with one, it should work with t’other
Don’t be scared of rejection, it happens to all of us Who knows it could be like my last app, where the reviewer could produce an error, but his steps never produced for us. I kept trying and trying, and after about a month he finally let it through.
[quote=118198:@Sam Rowlands]They both have different rules as to what constitutes an executable. The only major difference is that I control the code for the App Wrapper engine and Apple control the --deep function. Ideally if it fails with one, it should work with t’other 
Don’t be scared of rejection, it happens to all of us Who knows it could be like my last app, where the reviewer could produce an error, but his steps never produced for us. I kept trying and trying, and after about a month he finally let it through.[/quote]
Allright. I will submit and if it does not work, I will use the other method.
Actually, I now tend to consider Apple reviewers as yet another beta test. But if I try to prevent avoidable rejections.
As for the finicky ones, I had one last year who did everything he could to ruin the chances of one of my apps to get to market in time for Halloween sales. I will just have lost one year for that seasonal item 
Ha ha me too I’ve often contemplated just using Apple for beta testing.
Erm yes, there are some real counts (auto corrected from the vulgar word I entered), out there, especially when it comes to time sensitive stuff.
One year, our greetings card app was in review for 6 weeks, and finally the reviewer rejected it because I was using a SSB in the card files to link to to artwork files, which happened to be within the Resources folder! Within 24 hours, I’d adapted a system so it doesn’t use a SSB if the artwork is in the Resources folder and resubmitted. He rejected it again for the same reason, gotchya! I then mailed Tim Cook and lodged a formal complaint. I submitted technical documentation to show that I had done what the reviewer had asked and could prove it. I also complained about the extra-ordinary lengthy time frame of the review.
The following morning it was on sale, the Reviewer had written me 3 messages, but in the morning they were not visible on iTunes Connect, I sometimes wonder what he said.
Dear Developer,
Beginning November 1, 2014, apps submitted to the Mac App Store must be signed with signatures created with OS X Mavericks 10.9 or later (v2 signatures). Apps without v2 signatures will be automatically rejected on upload.
If you build code with an older version of OS X, use OS X Mavericks 10.9 or later to sign your app and create v2 signatures using the codesign tool. Structure your bundle according to the signature evaluation requirements for OS X Mavericks 10.9 or later. Considerations include:
Signed code should only be placed in directories where the system expects to find signed code.
Resources should not be located in directories where the system expects to find signed code.
The --resource-rules flag and ResourceRules.plist are not supported.
Make sure your current and upcoming releases work properly by testing on OS X Mavericks 10.9.5 and OS X Yosemite 10.10 Developer Preview 5 or later. Apps signed with v2 signatures will work on older versions of OS X.
For more details, read Code Signing changes in OS X Mavericks and Changes in ? OS X 10.9.5 and Yosemite Developer Preview 5 in OS X Code Signing In Depth: https://developer.apple.com/library/mac/technotes/tn2206/_index.html
Don’t worry about it, all you need to do is to make sure you code sign on 10.9 when submitting to the App Store.
Great. Thank you.
Just to check that I got it well:
-Should one generate a new signature on Apple’s web site (topo create a V2 signature) then download these new signature to sign the application in a 10.10 compliant way ?
Thanks !