Opinions about Mac App Store and UCI user interface App?

[trojanfoe]

What are your opinions about the likelihood of seeing a UCI User Interface released via the Mac App Store, given the following condition (from here; Apple Developer account required):

2.15 Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations

Given a UCI user interface must fork/exec the UCI engine(s) processes, surely it will be rejected by Apple based on this condition?

I know nobody ever knows what will and will not be rejected by Apple until the App has been submitted, but I thought I would ask in case anyone has experience with this.

-A

[hgm]

I had understood that iOS does not support fork/exec at all. Apps could still be made self-contained if it did; you could simply bundle a GUI with the UCI engines you want it to run, and it would satisfy the App-store rules. (And bundling is allowed by GPL, so any author of a closed-source GUI could include all GPL'ed engines, as long as they were run as separate processes.)

The legal situation is a bit murky when I would try to circumvent the no-fork problem by writing my GUI as a multi-tasking operating system, loading the core image of an engine binary into its own memory, in a big array, and start a thread to run it, or implement its own threads through time-slicing the CPU with timer interrupts.

[stevenaaus]

I had understood that iOS does not support fork/exec at all. Apps could still be made self-contained if it did; you could simply bundle a GUI with the UCI engines you want it to run, and it would satisfy the App-store rules. (And bundling is allowed by GPL, so any author of a closed-source GUI could include all GPL'ed engines, as long as they were run as separate processes.)

I think he means the OSX App store, not the iOS store. But i'm not too clued in or interested in all this really.
The link in OP needs an Apple ID to access.

The legal situation is a bit murky when I would try to circumvent the no-fork problem by writing my GUI as a multi-tasking operating system, loading the core image of an engine binary into its own memory, in a big array, and start a thread to run it, or implement its own threads through time-slicing the CPU with timer interrupts.

Do you really think you could do this !? With Xboard OSXboard, or some other project ?
One issue i can think of is X11. iOS apps can be cocoa only afaik. I don't know about OSX App store apps, but wouldn't be surpised if this was the same.

[trojanfoe]

I had understood that iOS does not support fork/exec at all. Apps could still be made self-contained if it did; you could simply bundle a GUI with the UCI engines you want it to run, and it would satisfy the App-store rules. (And bundling is allowed by GPL, so any author of a closed-source GUI could include all GPL'ed engines, as long as they were run as separate processes.)

The legal situation is a bit murky when I would try to circumvent the no-fork problem by writing my GUI as a multi-tasking operating system, loading the core image of an engine binary into its own memory, in a big array, and start a thread to run it, or implement its own threads through time-slicing the CPU with timer interrupts.

It's the Mac App Store I'm talking about, so fork/exec is supported just fine. I could bundle my own engines, but that would quickly lose its appeal as I would want to allow users to obtain and update their favourite engines for use with the interface.

There is always the possibility of releasing independently of the Mac App Store, of course.

What is the author of OSXBoard planning to do about this?

-A

[hgm]

OK, my mistake. On OSX fork/exec definitely works

What is the author of OSXBoard planning to do about this?

.

Actually I haven't heard from him for some time. I hope he hasn't given up. The obvious solution would be to distribute through other channels than the App store, which currently does not seem to be a major problem.

[trojanfoe]

OK, my mistake. On OSX fork/exec definitely works

What is the author of OSXBoard planning to do about this?

.

Actually I haven't heard from him for some time. I hope he hasn't given up. The obvious solution would be to distribute through other channels than the App store, which currently does not seem to be a major problem.

Yeah alternative distribution would be OK, it's just I think the 30% Apple Tax is probably worth it just for the passing trade you will get on the App Store - it's kinda like having a shop on Rodeo Drive or something; expensive but ultimately worth it.

[micron]

What are your opinions about the likelihood of seeing a UCI User Interface released via the Mac App Store, given the following condition (from here; Apple Developer account required):

2.15 Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations

I believe that there is free access to non-shared locations such as:
~/Library/Application Support/MyGreatApp/

I recently verified that a sandboxed app can download a document to the directory above. [In a sandbox the path is in fact swizzled to something rather different.]

I expect that engines could be downloaded similarly, unless the Mac App Store restrictions go beyond sandboxing.

[trojanfoe]

What are your opinions about the likelihood of seeing a UCI User Interface released via the Mac App Store, given the following condition (from here; Apple Developer account required):

2.15 Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations

I believe that there is free access to non-shared locations such as:
~/Library/Application Support/MyGreatApp/

I recently verified that a sandboxed app can download a document to the directory above. [In a sandbox the path is in fact swizzled to something rather different.]

I expect that engines could be downloaded similarly, unless the Mac App Store restrictions go beyond sandboxing.

Sandboxing it yet another issue (or will it be Gatekeeper?).

I have discussed the issue of starting UCI engines on the Apple Developer Forums and the opinion seems to be that it will be OK as my App won't be doing the downloading and someone commented that their App also starts other processes without issue. Looks like there is no need to worry.

My App would allow UCI engines to exist anywhere in the filesystem and the user can just configure the path to the engine along with the other engine-related settings. ~/Library is hidden by default, so I wouldn't expect a user to have to copy engines into that directory.