macOS app idea "abstracted *nix environment without jailbreaking "

[ArtOfWarfare]

you mean the programming language smalltalk ?
well i am doing this cause i want a real shell even if emulated on ios without jailbreaking the devices .
and why would you say we should implement something else other than a *nix system ?
the dang idea doesn't make sense without it
however if you have studied any other OSs which you can implement here please feel free to help us in that direction

i have no objection in including it but i'd like some details about what you really want to implement with it cause from where we stand right now this seems like a really long shot and i am understating it

My understanding is that Smalltalk is more than just a language and that it is actually an entire OS that happens to be programmed in a language with the same name. I might be wrong - I have no experience with Smalltalk, I've just read a few papers on it and am intrigued. It's on my "sometime when I'm bored and have nothing else to do list" to try installing Smalltalk on my computer.

 

[chown33]

well i am doing this cause i want a real shell even if emulated on ios without jailbreaking the devices .

Apple's policies prohibit downloading code. As I recall, this prohibition applies to interpreted code in addition to native code. As an example, a BASIC or FORTH interpreter would be prohibited, even if neither one allowed native code.

I make this point because a "real shell" is an interpreter. In particular, bash is an interpreter. It has a fairly small set of builtin commands, and a much larger and extensible set of external commands. I don't see this distinction (builtin vs. external) as significant under Apple's policy. The point remains: one could download code (shell scripts) and interpret (run, execute) them on the iOS device. Unfortunately, this is prohibited.

I also think there are some exceptions to this general prohibition, such as games that are written using an interpreted engine. Nevertheless, this exception is only allowed as long as direct access to the interpreter is not supported. That is, game extensions must be bundled and distributed as game extensions only. There's can't be user-visible access to the interpreter, even if it were technically possible to provide such access.

So, as I understand the rules, it's impossible to get any kind of "real shell" approved for the app store, because any real shell is inherently an interpreter with direct access, and those are prohibited. It would make no difference how many levels of virtualization or emulation one was using. It's the fact of having an exposed code interface (i.e. an interpreter) that triggers the prohibition.

You could try, or you could ask Apple for clarification, but if you're not prepared for rejection, then I wouldn't bother.

Or if you think my explanation is wrong, please cite the actual text of the rule in question, or provide an existing example on the app store of what you intend to make.

 

[apmwnq]

Apple's policies prohibit downloading code. As I recall, this prohibition applies to interpreted code in addition to native code. As an example, a BASIC or FORTH interpreter would be prohibited, even if neither one allowed native code.

I make this point because a "real shell" is an interpreter. In particular, bash is an interpreter. It has a fairly small set of builtin commands, and a much larger and extensible set of external commands. I don't see this distinction (builtin vs. external) as significant under Apple's policy. The point remains: one could download code (shell scripts) and interpret (run, execute) them on the iOS device. Unfortunately, this is prohibited.

I also think there are some exceptions to this general prohibition, such as games that are written using an interpreted engine. Nevertheless, this exception is only allowed as long as direct access to the interpreter is not supported. That is, game extensions must be bundled and distributed as game extensions only. There's can't be user-visible access to the interpreter, even if it were technically possible to provide such access.

So, as I understand the rules, it's impossible to get any kind of "real shell" approved for the app store, because any real shell is inherently an interpreter with direct access, and those are prohibited. It would make no difference how many levels of virtualization or emulation one was using. It's the fact of having an exposed code interface (i.e. an interpreter) that triggers the prohibition.

You could try, or you could ask Apple for clarification, but if you're not prepared for rejection, then I wouldn't bother.

Or if you think my explanation is wrong, please cite the actual text of the rule in question, or provide an existing example on the app store of what you intend to make.

while i appreciate your concern and realize the point you are making but i think the rules need not be quoted here , first and foremost this is a fun project and we don't care for rejection at all , and i believe bash doesn't quite fall into that category , yes technically it does but not practically , i have a good feeling about this , that apple won't care because of the abstraction layer here , i'd give it a shot anyway .

 

[denniscote]

My understanding is that Smalltalk is more than just a language and that it is actually an entire OS that happens to be programmed in a language with the same name. I might be wrong - I have no experience with Smalltalk, I've just read a few papers on it and am intrigued. It's on my "sometime when I'm bored and have nothing else to do list" to try installing Smalltalk on my computer.

You are correct. You can try out smalltalk using the Squeak app for Mac OS X, an entire smalltalk environment in an app for OS X, much like the OP proposed an entire *nix environment in an app for iOS. Check out http://www.squeak.org for more info. Squeak could probably be ported to iOS since it is all open source code.

FYI, wikipedia describes objective C as: "Objective-C is a general-purpose, object-oriented programming language that adds Smalltalk-style messaging to the C programming language". So those familiar with objective C may be fairly comfortable with smalltalk right away.

 

[denniscote]

Apple's policies prohibit downloading code. As I recall, this prohibition applies to interpreted code in addition to native code. As an example, a BASIC or FORTH interpreter would be prohibited, even if neither one allowed native code.

...

There's can't be user-visible access to the interpreter, even if it were technically possible to provide such access.

I think there must be more to it than you have said since I have a complete Python interpreter installed on my iPad using the app Pythonista which I downloaded form the iOS app store. Details can be found at http://omz-software.com/pythonista/.

Clearly you can expose an interpreter to the user in an app that is distributed on the app store, at least under certain conditions.

 

[apmwnq]

I think there must be more to it than you have said since I have a complete Python interpreter installed on my iPad using the app Pythonista which I downloaded form the iOS app store. Details can be found at http://omz-software.com/pythonista/.

Clearly you can expose an interpreter to the user in an app that is distributed on the app store, at least under certain conditions.

basically what i understand from the rules is that anything that exposes or modifies the ios system components is not allowed but since the whole thing is merely a simulation as far as the apps specs go, i doubt there is any way our app is lessening apple's control over the device , apple's main regulation is that an app shouldn't affect the system itself in any way
and that the app just should run over it and do the limited amount of I/O that it needs like saving data to its own sandboxed directory or accesing the system's network and stuff .

----------

You are correct. You can try out smalltalk using the Squeak app for Mac OS X, an entire smalltalk environment in an app for OS X, much like the OP proposed an entire *nix environment in an app for iOS. Check out http://www.squeak.org for more info. Squeak could probably be ported to iOS since it is all open source code.

FYI, wikipedia describes objective C as: "Objective-C is a general-purpose, object-oriented programming language that adds Smalltalk-style messaging to the C programming language". So those familiar with objective C may be fairly comfortable with smalltalk right away.

aye , i like the idea but currently i am just gonna focus on the *nix environment , meanwhile
if anyone likes to fork and maintain a derivative of this upcoming app in the future( when it has materialized) for smalltalk please feel free to do so

 

[chown33]

I think there must be more to it than you have said since I have a complete Python interpreter installed on my iPad using the app Pythonista which I downloaded form the iOS app store. Details can be found at http://omz-software.com/pythonista/.

Clearly you can expose an interpreter to the user in an app that is distributed on the app store, at least under certain conditions.

Yes, you're clearly correct. I'm still unclear on exactly what conditions are needed for it to be accepted in the app store (Mac or iOS). And maybe there are several different conditions. I could easily see that downloadable native code modules may have different restrictions than interpreted ones.

In briefly browsing the Pythonista docs, I see this:
http://omz-software.com/pythonista/docs/ios/pythonista.html

The script library shows all the scripts you’ve written and those that are included as examples. ...
​

It then mentions creating from a blank slate, creating from a template, or deleting. I see nothing about importing any downloaded existing scripts, adding downloaded modules, etc. So it looks like there's a limited path for using code you haven't written yourself in Pythonista.

But then there's this:
http://omz-software.com/pythonista/forums/discussion/5/sharing-code-on-github
which talks about using the programmable editor in Pythonista to improve its code-sharing capability. And in that discussion is this post from user "omz":

And btw, it's not possible to include these features as part of the app, it wouldn't pass Apple's review (downloading code in any way is a no-no).
​

So the app on the app store can't download code directly, but it's possible to manually copy & paste some code into it that extends its abilities, and voila: a new feature.

I still don't see native-code modules, but it does seem like a nice environment for automating and tinkering on iOS.

And thanks for the Pythonista link. It's a very interesting tool.