Hmm… So apparently App Wrapper shouldn’t be automatically checking to see if the package has been Notarized. Instead the developer is meant to wait by their e-mail client and once they get the e-mail from Apple, that’s when you perform the staple operation.
I don’t know that I believe this, I think it’s a problem at their end (I bet their team doesn’t work weekends), I’ll guess we’ll just have to wait and see.
Currently with App Wrapper, if it errors out like this, once you get the e-mail receipt from Apple, you can right click the item in the Notarize window and “Try Again”. If it still fails, take a look in the log, if the requestUUID doesn’t match (which what I was getting) then you remove the item from App Wrapper, and manually add it, entering in the requestUUID from the receipt e-mail.
And yes as Tim says, this process doesn’t quite work for Zip, because Zip requires extra steps to Notarize, that I haven’t yet trained App Wrapper to do.
I am sure Apple is on a go slow.
It’s morning here in the UK now.
After trying most of yesterday, 7 emails from Apple arrived here 4 hours ago… nearly 12 hours after submission.
Some errored because the app had been submitted more than once, some said ‘all ok’
I was getting the same message this morning. Went through all the steps. Just clicking ignore was enough to get the signing to work, I havent tried to notarize it yet. My earlier total failure was in trying to include some things that had a dylib link that was inside a folder starting with a . which made it hidden. App Wrapper claimed to be deleting the folder which it did, but then everything else exploded all around that. No signing no notarizing, no nothing, just boom. I had to use install_name_tool to alter all the link paths on the libraries so that they didnt need to be in a hidden folder and then it all worked again. I wont even bother telling you all how long it took me to figure all that out and then to figure out how to alter the internal link paths embedded in the libraries… I got a LOT done this morning which almost got me back to where I was yesterday, but not quite. These sorts of days are frustrating…
HI James,
Am working on fixing the first error; I managed to get it to show for me on Saturday. I managed to be able to prevent it on Sunday, but I couldn’t release a test version because it’s one of the Notariations that failed. I will try again today.
In regards to the hidden folder; this was/is one of the causes of the deitris error when signing. It took absolutely ages to figure out there is no resource fork, no acl, no xattr for a hidden folder and the code sign error message doesn’t give you any clue as to which file might be causing it.
If I were you; please share with us or write for xDev, or the Xojo blog, but please share the steps you had to endure to resolve this ridiculous problem. At the very least you’ll save others a wasted weekend.
@Sam Rowlands: because we want to eat. We also don’t want to work for a big company where 80% of the time is spent on either a work-creation program or a meeting.
[quote=461741:@Sam Rowlands]If I were you; please share with us or write for xDev, or the Xojo blog, but please share the steps you had to endure to resolve this ridiculous problem. At the very least you’ll save others a wasted weekend.
I’m beginning to wonder why are we doing this?[/quote]
For the record none of my obvious ire was pointed at you Im not sure I would still be doing this without App Wrapper honestly. It has saved me from so much frustration that I just expect it to always be able to do so
I will writeup some info on changing the dylib paths that are embedded into them. I spent a huge amount of time figuring out how to do that some years ago when I needed to embed the VLC libraries into a project but the way they are built hard codes the path into them so they wont be able to find each other if you put them anywhere else or even if you try to link to them inside the VLC app itself. I never knew that info was even embedded in them until then. That was another remarkably frustrating weekend as it had all worked great before the latest update to VLC
All at once I’m getting the detritus error when wrapping 19r1.1 apps; but no detritus error when wrapping the same apps built with 19r2.
Even apps I had wrapped just a couple of weeks ago without having the detritus error, now they show the detritus.
Using last AppWrapper, for the MAS (so, no notarization etc. involved).
Last Friday, I’ve successfully notarized my app (Xojo 2019.1.1) with App Wrapper 3.10 (macOS 10.14.6). It tooks about 4 minutes for the full process.
I’ve also signed the same app for Mac App Store without any problem (and it tooks less than 4 hours to be verified and ready for sale by Apple)
That’s because Apple has fixed most of them, and Sam has addressed some others.
Its been 10 days. Things move on.
Happy its working for you. Its also working for me.
I’ll tag Sam’s response as ‘the answer’ so that people dont think it is currently an issue.