Updated AppWrapper: Cant Notarise today

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.

Now I’m going to go get some breakfast.

We appreciate your work Sam.

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’

Word is that it’s back up and running now; we’ll see in a bit when I try it!

Its not. But maybe it will take a while to clear the backlog.

I got my app notarized in a record time of 9 minutes.

I got 3 out 5 Notarized today, the second one gave me the same UUiD error and took ages; the last two… I’ll try again tomorrow.

Record short or record long? My quickest is 5 mins; my longest is 24 hours.

Record short. It usually takes 17 minutes.

My record short was 1 minute.
I got one done today, 5 hours

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 haven’t 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 didn’t need to be in a hidden folder and then it all worked again. I won’t 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.

I’m beginning to wonder why are we doing this?

@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 :slight_smile: I’m 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 :wink:

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 won’t 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 :wink:

Tim Parnell recently did this as well for his EXEWrapper
I thought he had posted steps as well

FYI, in Finder since a few versions ago, you can hit Command-Shift-Period to toggle the visibility of hidden items. It can be a debugging lifesaver.

Mac user since… forever, and I did not know this one. Thanks.

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).

Today, I released an update to solve this error! Use check for updates from App Wrapper menu.

Not sure what are the problems you encountered.

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. :slight_smile:
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.