They are not, unfortunately.
#68271 - a Console helper app cannot communicate with a Desktop app when placed in the Helpers folder because Xojo is failing to sign Helpers correctly. The issue can be worked around by adding your own “Resign” step immediately after the Xojo step, and performing your own codesign.
I am not very impressed, as I’ve said elsewhere, I had hoped that Xojo would invest in improving their product, rather than take away business from it’s already small 3rd party vendor group.
Xojo isnt doing 1/4 of what Appwrapper is doing.
And as far as I can see (could be wrong but…) it doesn’t integrate with the DMG and packaging aspect. These need signing and notarising too, don’t they? No plans to stop using AW
The app the I am writing, does code-sign, notarization, and packages as Zip, DMG or PKG
but in no way was designed to compete with AW… mine is a simple no frills, and I doubt it does 1/2 what AW does…
I don’t know, but does AW work with non-Xojo compiled projects too??
It should
No reason it couldn’t that I’m aware of
Well, I think they were between a rock and a hard place. Hey, we have this Mac and iOS development tool for $x. Oh, and by the way, you’ll have to spend another $y on this 3rd party tool to properly sign and notarize your apps. I’d have preferred them creating a detailed example of how to do it manually (and maybe mention 3rd party options in the same documentation).
They are behind in so many things that this feels like a weird add. There must have been some pressure by a big sale or something. Or maybe Geoff just got a bug up his *ss and decided now was the time to add the feature.
https://tracker.xojo.com/xojoinc/xojo/-/issues/59520
part way through that thread Geoff replies with
And his own criteria for what to fix/add appear to NOT apply as there are options
AppWrapper and Jurg Otters free scripts that can do signing packaging etc
Yes, I use it for my non-Xojo compiled projects.
It does, it is used by Objective-C developers, Swift devs, FileMaker devs and Cycling '74 devs (Now I’ve added the fixes to Cycling '74 packages). It is even used by an internal Apple team for codesigning their apps.
Works great with Tauri and <zalgo>Electron</zalgo> too!
Did they tell you or you had to find out?
Thats super cool tho
Now THATS cool !
Cool, thanks for letting me know.
They submitted a feature request to help with their workflow.
I just wish it translated to mega bucks 
Code signing and notarization is only a fraction of what App Wrapper can do. It does App Store submission, as well as the features listed below it has a bunch of checking functionality and UB splitting, which can create architecture specific archives.
⭐️ Knows which certificates to use for each channel.
⭐️ Helps identify code signing certificate issues.
⭐️ Automatically removes files that code sign chokes on.
⭐️ Remove unwanted architectures from the bundle.
⭐️ Set system requirements, SDK compatibility.
⭐️ Modify version number & configure the About Box.
⭐️ Auto fixes nested files permissions problems.
⭐️ Built-in property list editor for manual control.
⭐️ Built-in Icon editor to generate high resolution icons.
⭐️ Add, remove of modify nested files within the bundle.
⭐️ Manual control over supported language packs.
⭐️ Automatic removal of unsupported language packs.
⭐️ Creates & installs a Apple Help Book from HTML.
⭐️ SF Symbol rasterizer, creates multi-resolution TIFF files, and embeds them into your Mac app for you.
⭐️ Scripting capability to integrate with other dev tools.
⭐️ GUI features for full color icons or to disable window tinting.
More information can be found on the website App Wrapper - Easily publish Mac apps on the Mac App Store or websites
That’s pretty much my thoughts on this, I can’t help but wonder if this move is retaliatory as I made a stink last year about the quality of their Mac builds (which hasn’t improved).
The trouble is Xojo doesn’t appear to care about retaining customers, they keep focusing on adding new users, while letting the more experienced users walk out the door in frustration, them adding Notarization is only going to cause more frustration when someone’s app doesn’t work with their system.
Last year I even wanted to work on the Xojo Mac framework to improve a number of things, but Geoff said Xojo doesn’t need my help and everything is the way it should be.
I wish the work I did for them way back when had as well but … oh well
still waiting for them to fix signing iOS builds never mind new stuff for macOS
If it weren’t for greg me & client would be hosed
That’d be a chore since they let pretty basic things out to the wild more so now than I ever recall
They broke XML in 2024r4
Regressions test suites would have caught that
It’s a matter of time. You either move away from Xojo now or later.
Well, I think it really depends on your use case. For many developers Xojo is fine for what they do. But I do think that the serious developers move away from it when they start to learn how much work it is to workaround limitations. Or, they need something (say reporting) and see that the built-in stuff is crap and there aren’t a lot of 3rd party options.
That may be true, though I wonder whether Sequoia rather forced them into throwing something together.
Perhaps a bit of both.
Most CEO’s i know do reserve a space for people in their heart that they feel slighted by in the most miniscule manner.
So if you ever told one they are wrong about anything, rest assured, you live rent free in their head, even if it’s on a part time basis lol.
Like, oh no we are forced to do this. What are our options?
There is no interest in help from outside while that costs money which they don’t waanna spend. Looking on their policy the behavior shows what they want: a good looking system which can help people to decide: oh I will buy it. They even have no testing period for people which want to test the compilation and so on. Only thing they have is: their small range of Ideas. Nothing else. They have one plus. Android is complex looking on Xojo. Working with Xojo you have access to a small range of functionality of the Android API. That makes it less complex to work with it.
I can not see that professional Devs will work with it for IOS or Android. I can say from my side: if the App is not too complex ore has to be native: CodenameOne for both platforms. If then I will write native for both. Nothing else. Swift and Swift UI for IOS and Java fopr Android. That’s it. Works withiout problems on both sides and is definitely native on both sides. Du I have to do this? In my eyes yes. While complex Aps often need an access to the System API and nobody really knows how the language vendor was implementing the API of the operating system. Asking me I would say that this is something I do not need for exmple to implement Bluetooth LE ion a complex situation where I need to have all control about the behaviuor. This I don’t have in any other way than writing native. Coming to the notariziung: that becomes more simple writing native. Okay with Codenameone the Assistant of the Buildserver is doing that Job but you will also need to do this with all languages. The chance that a native app will get through without limitations iss higher than with any other language than the native one.
Another word to Xojo and Sam: when I was reading this I got a bit shocked. Sam was working hard on his solution and presented much to Xojo how things can go and work. So Xojo implemented a half baken solution to make same AppWrapper obviously superfluous. They are not and were never interested in partnership. Even the solutions of MBS they try to bring into their own software. They kill the ecosystem around if they not stop that. And they will not.
As a result you have many edges where nothing will work. Also that everybody knows. And that is the situation with the App Signing alpha rerlease they have presented