It’s required for Sandboxed applications.
Standard OS functions work fine in the shell, it’s embedded ‘Helper’ applications that must use NSTask (with the correct entitlements).
MBS has this, as does the Sandbox Kit (which is currently available with the OmegaBundle).
Of course. I remember trying to launch a helper with a shell and it never worked. Thank you.
NSTask is also part of MacOSLib.
You’re welcome and sorry that I didn’t explain it so well before.
I have a feedback link, requesting support for NSTask. <https://xojo.com/issue/26605>
Here’s how I got it working:
I placed my standalone web app unchanged into the Resources folder of a plain Mac desktop app via a CopyFile. I copied in the ‘AsyncShell’ object from the Xojo ‘AsyncShellExample’ example (Example Projects> Advanced> Shell> AsyncShellExample.xojo_binary_project) and set it to AsyncShell.Close then quit the Mac desktop app when the Completed event was True. You can comment out the DataAvailable code.
I then had a button on the Mac desktop app’s window that launched the standalone web app as an Asynchronous Shell app via the AsyncShell.Execute( ) command. I was then able to log into this ‘Mac desktop app’ via a web browser!
I also added a Quit button for manual quitting, which does a AsyncShell.Close before quitting the Mac desktop app. I may also add a field on the window to choose the port number and a TextArea to show any feedback.
I am not sure if this technique would get rejected from the MAS!
You are right, David. Asynchronous shell in a sandboxed application does launch a helper fine.
I see no reason why it should be rejected for the MAS. No error in console.
I’m going to be the boring lecturer here. From experience if Apple ‘suggest’ you do something a particular, it’s less likely to be broken by an update.
What I mean is that the AsyncShell class may work (it may actually be NSTask underneath), but if it’s not, you may find that all of a sudden you need to switch to the NSTask class in a system update (or even worse an app store requirement update).
NSTask also passes on the entitlements of the parent application to the helper application, this way if a parent application can open a certain file, then so can the helper. If the AsyncShell class is not based on NSTask, this may not work.
As for executables in the Resources folder, code signing will most likely fail because of this. ‘Nested’ executable code should be in the correct folder. I’ve seen a lot of Xojo competitors get bitten by this when they dev tools do not follow Apple’s guidelines.
In the last few years, Apple have really cracked down on things that are not 100% correct, making it harder for us, especially when we don’t follow their guidelines (I’m as guilty as everyone else).
[quote=168915:@Sam Rowlands]I’m going to be the boring lecturer here. From experience if Apple ‘suggest’ you do something a particular, it’s less likely to be broken by an update.
What I mean is that the AsyncShell class may work (it may actually be NSTask underneath), but if it’s not, you may find that all of a sudden you need to switch to the NSTask class in a system update (or even worse an app store requirement update).
NSTask also passes on the entitlements of the parent application to the helper application, this way if a parent application can open a certain file, then so can the helper. If the AsyncShell class is not based on NSTask, this may not work.
As for executables in the Resources folder, code signing will most likely fail because of this. ‘Nested’ executable code should be in the correct folder. I’ve seen a lot of Xojo competitors get bitten by this when they dev tools do not follow Apple’s guidelines.
In the last few years, Apple have really cracked down on things that are not 100% correct, making it harder for us, especially when we don’t follow their guidelines (I’m as guilty as everyone else).[/quote]
I know you have posted that somewhere but can’t find it at the moment. Where should a helper app be placed ? Not a startup one. One that you call after the main app has been launched ?
Technically any of the following.