I’ve got that inherited desktop project which starts an internal web app (as a web shop, so users – merchant trainees – can play being their own customers).
No problem on Windows, but a big one with macOS once I try to codesign/notarize it.
The web app is still built in Xojo 2019r3.2 because of lacking web API 2 features I need.
The main app is recent Xojo 2020r2.1.
After realizing the app was still in resources instead of Helpers, I moved it and removed localizable strings which happen to be the cause of internal console apps not being code signed.
But, after installing App Wrapper‘s scripts, Xojo warns me about codesign problems each time, AppWrapper shows some errors (pointing towards the web app’s icons) and notarisation fails because the main app cannot be code signed.
Before I start to redesign everything and move the web app outside of the main package: Has anyone succeeded in notarising a structure like above?
Or no chance at all?
What errors do you get when you do the code-sign? Do you only use AppWrapper? Have you tried manual code-signing?
The executable being in a helpers or macOS folder is going to be fine, but you won’t be able to have any resources in there as they won’t sign properly (Or at least, I couldn’t get it to work). We have a Xojo built webapp included in one of our apps and it was signed and launches ok. After a build of the web app we copy the web app executable and the web app Libs folder inside the MacOs folder before signing. The Resources files generated when compiling the web app, which include some images and logos are not copied. We don’t need them because the web app is for publishing a HandleURL system for receiving data.
Thank you, Lee. I was hoping such a setup would be possible and will try it. I could imagine it should even be possible to move resources to the helper place by code if necessary. Do you codesign the web app separately?
@Beatrix_Willius: It starts with Xojo complaining right after the build if I insert App Wrapper’s scripts, but the message is rather unclear to me:
and AppWrapper telling me
failed Failed, options:449
failed INTWASYS.app: code object is not signed at all
failed In subcomponent: INTWASYS.app/Contents/Helpers/IWSServer/Resources/appicon128.png PNG image
failed “INTWASYS.app” is not code signed.
Knowing about the resources problem, I did not try to codesign manually.
Yes, That’s exactly the problem I had. Any .png files are not allowed in an executable position. You should be able to get the helper app to look along the correct path to the main resources folder so long as it doesn’t look outside the bundle.
1 Like
Pretty much what Lee says, Apple doesn’t like executable code in the resources folder, they also don’t like non-executables in an executable location.
I may be able to provide you with a temporary solution, it would be temporary as in it may help you out now, until Apple add stricter checks in the future (which they do without warning).
Ultimately, Apple want you to put Resources in the Resources folder. Another potential solution is to re-structure your web app as an executable bundle (.app, .framework, .plugin), although I have not personally tried this.
Thanks a lot, you all!
For those to follow: The solution is, like Lee and Sam said, to move a helper’s resource folder into the main app’s resource folder and create a symlink to that folder instead. Should make it possible to have localized resources in helpers too.
3 Likes
I am glad to know that symlinks work. A note for those finding this in the future is to make sure to use relative symlinks and not absolute, so they work on different machines and different locations.
1 Like
Now I wonder what kind of symlink PathFinder creates 
