If I want to check files in a directory where I need full disk access with workers is FDA inherited from the main app? Is this possible at all?
My app can archive emails from Mail. I want to speed this up - if possible - with workers. But the Mail directory at user/username/Library/Mail needs FDA.
Reading through this post:
https://developer.apple.com/forums/thread/107546
It looks like inheritance requires embedded info.plist data and the use of a sub identifier, neither of which Xojo currently does not do IIRC.
Does a double negative make a positive? 
@Sam_Rowlands could answer if App Wrapper does this for you.
@Greg_O : thanks for the link. I don’t think that console apps support info.plists at all. Reading such threads is depressing because the forum replaces the documentation at Apple.
@Douglas_Handy : I don’t think that @Sam_Rowlands can add the missing info. I need to look for a different way to speed up my code.
I think that helpers can be listed in the app plist and gain some inherited properties. The proper “how to”, if any, I have no idea, just recall something like that.
Console apps have embedded Info.plist data as Greg had noted. Here’s where Christian asked for the ability nine years ago #33424 - Allow embedding of info.plist for console apps
@Sam_Rowlands has been trying to get Xojo to improve Console apps for quite some time. I’d wager he has more details.
Personally, I recommend writing your own console helper app and bundling that in. I can’t say anything nice about the design of Workers. You’ll find writing your own console app to be much more relaible – even if it takes a little more work to set up.
It currently doesn’t. I did spend considerable time investigating and experimenting, and I hit a dead end.
I did file a feature request for it.
Correct, my attempts to inject a plist into a Xojo made console application failed.
IIRC the problem was lack of free space between the header and the data, which was only compounded when UB came out. I not only had to shift data around, I then had to update all the internal ptrs as the data had moved, which I was either missing something or doing it incorrectly, because it resulted in many a dead executable.
Which is why I asked Xojo to do it…
Norman from the other forum has forwarded me this article, which might help with console apps (and therefore workers).
Maybe that can help?
Alternatively depending on what it is you’re trying to do, now might be a good time to experiment with another tool and create a Xojo plugin that can use GCD. yes it’s daunting, but it’s how my old HDR application could use multi-core processing.
I would agree with this. I’ve even heard of people having difficulty getting an app with Workers into the Mac App Store, so rolling your own will allow more customization if things don’t go as planned.
Oh, I didn’t know that. I thought that the plist is next to the console app. Workers seem like a nice idea but the implementation is lacking.
Console apps have the most unattractive pricing at all. I don’t need web or iOS.
@Sam_Rowlands : thanks for the explanation. A GCD plugin does sound daunting. Another question: can I give a helper app full disk access with AppWrapper? If I scan the Mail folder once with the main app and then observe the changes with FSEvents I should get a good enough speed boost.
This is a complaint I’ve had with them since they first debuted in beta.
You don’t need anything other than the lite version. With some declares and jiggery pokery, you can coax a regular Xojo desktop app to operate as a command line app and thus be used as a helper. It even has the advantage that it can share the same Xojo libraries as your main application, cutting megabytes out of your package size.
Oh, there is no denying it is daunting, but with very minimal coding expepience in another language, I was able to get a working solution in a morning. I did cheat, I didn’t create a Xojo plugin, I just made a CIFilter (for core image processing) and loaded it at run time. I coulda made a dylib or some other thing, but I have more experience with CIFilters.
Sadly not as far as I know.
There is a trick to massively improving directory scanning speed, by using nothing more than one loop and an array. I’d have to dig out the code for it.
Apple has a single commoand for scanning a directory fast and returning meta data, but this sadly gets more and more broken every year, to the point that I won’t recommend it at all.
To be fair, if you do this, you should be able to get this inherited thing to work just fine. From what I’ve read, bundles work just fine. You just need to make sure your helper app has an identifier that’s a subset of the parent app:
com.example.app
com.example.app.worker
Just made a feature request for getting the app id fixed
@Sam_Rowlands : I’ll give it a try with normal apps. I don’t much care about app size.
@Greg_O : “should be able” with codesigning and notarisation usually means fun of the root canal variety. But I’ll try it.
I don’t think you’ll have to do anything differently. If you’re placing the file in the helpers folder, just make sure those items get signed and the notarization of the outer package should include the helpers as well.