AppWrapper: the signature is invalid


One of my apps behaves strangely in regard to notarisation.
Up to now, I could only run it un-notarised. As soon as I notarised it and launched it (a copy put in /Applications), I got a Xojo failed assertion and the app wouldn’t run; even tried rebuilding it led to the same behaviour. Couldn’t explain.

Now, some weeks after having that initial problem, I decided to try again and re-built it.
The app is a GUI one with a console app embedded into it, acting as a helper (a worker is too limited in my case).

Currently, AppWrapper gets errors on wrapping.
For the sake of making a “short” post, here are lines I found to be relevant in the logs:

   93	Executables:        	"Contents/Resources/HIIFH/HIIFH" x86_64 appears to have an invalid rPath "@executable_path/HIIFH Libs/".; rPaths with  "/" at the end may work for the moment, but it is not needed and may cause problems down the road.

  832	codesign:            Removed Handle items in

  857	Verify:              Checking application against GateKeeper
  928	Verify:              Failed: rejected

1'212	in folder 1.11.dmg: 	⚠️ Error:   1 "/Users/me/Documents/Wrapped applications/Handle items in folder - Website (x86_64)/Handle items in folder 1.11.dmg: code object is not signed at all".

69’639 in folder 1.11.dmg: The signature of the binary is invalid. in Handle_items_in_folder_1.11.dmg/Handle items in

(I recognise I should perhaps put the entire log, but I’ll do it if requested)

I wasn’t able to find helpful posts in this forum regarding this issue.
Help welcome, please.

Are you packing your helper in /Resources or /Helpers? AFAIK you can’t pack executables into /Resources

1 Like

I was indeed using /Resources, thanks for pointing this out.
But with using /Helpers, I get similar troubles:

   68	Executables:        	"Contents/Helpers/HIIFH" x86_64 appears to have an invalid rPath "@executable_path/HIIFH Libs/".; rPaths with  "/" at the end may work for the moment, but it is not needed and may cause problems down the road.
  834	bb.codesign:         1 : Failed, options:449 : 00:00:13,7
  835	tems in 	{"code":1,"message":"Handle items in bundle format unrecognized, invalid, or unsuitable","type":"codeSigningIssues"}

Does your helper have a “Resources” folder? If so you need to remove it as Code sign doesn’t like it.

App Wrapper currently doesn’t tell you about this because I don’t have any other solution than to delete that “Resources” folder, there is a Xojo Feedback case for this, but it has been closed as “Won’t implement”.

if the helper doesn’t have a “Resources” folder, please select “Contact Ohanaware” from the Help menu as this will prepare an e-mail for me with the log and your settings, so I can take a look.

I must make clear that my first feedback case was closed, my second one is <> which is currently open, but private. I’ve asked for the private information to be removed and the case made public.

1 Like

That was it, thanks!

I have no problem in removing that folder manually, but for that, I must first know about the issue :wink:
Since App Wrapper doesn’t tell me, I’m not aware of the reason of the problem, but the notarisation still won’t complete.
IMO, I think you should report it anyway. Don’t necessarily remove the folder from App Wrapper (as I get your point of not removing the folder from the app), but tell the user this isn’t supported so (s)he can do something other than asking :wink:

So Xojo inc. know this “Resources” folder is garbage (as it prevents notarising) but won’t implement a fix? Disappointed…

Of course, apps in the helper folder can contain the Resources folder. Apps just can’t be IN the Resources folder anymore.

My installer now has the to-be-installed app in Contents/Helpers. The main app - naturally - has a Resources folder. Notarisation is fine.

Not in my case; it was the issue I had.

That was my first setup, yes. But, after @Tim_Parnell told me about that, I moved to the Helpers folder and still had the same issue (the helper still had its Resources folder).

Yes, the main app was not the problem.

It looks like you’ve not encountered the problem I saw; wondering why I did…

For the installer the main app IS the helper app. Yes, I’m wondering, too, what the §$%& notarisation is doing.

1 Like

Ah, right, I overlooked the fact you mentioned an installer; I don’t use them.

Not the most transparent process in the world, indeed.

Just to make sure that we’re all on the same page here. I was talking about console / command line applications that are produced by Xojo. They include a “Resources” folder next to the executable file, and it is this “Resources” folder that code sign doesn’t like.

You are quite correct, at the time I wrote the code to detect a non-associated Resources folder, my mind was too concerned with what the user should do next.

I have reported it twice in Feedback, and unfortunately had a rather heated public debate with a Xojo engineer about it. I assume too few people encounter this issue, so it is of a low priority.

As I’ve mentioned before, I am open to discussion on this, I am willing to share what I know and do further research if needs be.


Is this issue not widespread because it’s 100% reproducible but only few people make console apps as helpers or because it’s not 100% reproducible in the first place (i.e. the “Resources” folder isn’t always created)?

I believe it to be both. AFAIK “Resources” is mainly created when using localized constants, but there could be other things that cause it’s creation.

1 Like

I don’t remember having added localised constants myself to this project, so probably something else, indeed.

I think that inspecting its contents, inside the built app, you will have a hint.

Good point. I haven’t even bothered looking at it; will do next time.

Yes, this bit me when I had a localized constant in one of the classes I was using in a Worker. Yes, it ran in the debugger, and it would build alright, but it gagged when AppWrapping. However, the AppWrapper dialog gave enough information to figure it out.

1 Like

I recognise the path was inside the report, but I didn’t expected that folder to be removable.

The issue, in my case, was simply a localized string that I could do without. By removing the string, all I had to do was rebuild. No more folder. :slight_smile: