The problem with all that is that Apple keeps changing their minds and then it becomes “what works on what version of macOS?”
For instance, this --deep thing was deprecated on macOS 13 which means it’ll work on everything up to macOS 12 without a warning and on macOS 13+ with a warning until it suddenly doesn’t. Whether that’s just with macOS 15 or if they decide with a reciprocal patch, no one knows.
All this means that Xojo’s docs would continually be in flux, they’d need to have “an expert” on staff to know all the nuances, and the docs would have to have a long list of exceptions for different versions of macOS and Xcode that would have to be tested and possibly updated every time Apple changed something.
Personally I think it’s better for this to be a community project or a 3rd party app (like AppWrapper), but as of late (since I’m upgrading our systems in prep of these changes) I completely understand why Sam is so frustrated with Apple on this and other topics. They provide mountains of documentation on codesigning and notarization and none of it is actually complete. You inevitably end up having to search, read and collate the information from multiple sources to even get close to a solution. Apple could/should provide example bash scripts that show the right way to do these things with lots of comments. It’d make the process less of a barrier to early devs.
History? If Xojo would be writing proper guides for years they would have all those documented.
For macOS ddd to eee: Instructions.
For macOs fff to ggg: Instructions
For macOs hhh and up: Instructions.
Apple don’t care about companies creating alternative languages, those companies need to provide their way. XCode can solve much of the trouble with few clicks not needing to use CLI, that’s what Apple does, and writing scripts or other tooling is a problem for others, not Apple. They use it as an advantage, and they probably won’t change this behavior.
That’s a nice sentiment, but it doesn’t work that way. Every time Apple makes a change or releases a new version of macOS or Xcode, they’d need to go back and verify that the instructions for each and every version of macOS/Xcode version also hasn’t changed.
I’d rather Xojo be focusing on other things like making sure their frameworks are stable.
Anyone that uses a build system like GitHub Actions or Jenkins needs a way to do this with a script, even if they use Xcode to develop their stuff, because the assembly of apps isn’t always as straightforward as Build, Sign and Notarize. Often there are other libraries, frameworks and resources that need to be added to the bundle before the sign and notarize steps are done and that means there needs to be a script. All I was saying was that with their comparably infinite resources, Apple could provide scripts themselves.
A big thank you to Xojo.
In 2024R4 it is finally possible to notarize and make a real finished app for the Mac and the AppStore.
It worked right away. The integration of the new function is well done and very simple.
I even managed to notarize an app that contains a 2nd app in the Resources folder. You just have to notarize this 2nd app first.
This is a great feature and a big step for Xojo.
