[saagarjha]

All the scripts, code, and interpreters are packaged in the app bundle, since it's emulating x86 binaries. The "additional functionality" guideline is a bit loose because companies download patches (for A/B testing, bug fixes) all the time, which doesn't go through App Store review.

[saurik]

"All the scripts, code, and interpreters" are not, in fact, packaged with the app as you are able to download arbitrary binaries using curl/wget or apk. That clause is very clear in both wording and intention, and this application does not follow it.

As for the A/B testing that some companies do via sketchy runtime hooking, that has been a boundary case for a while that sometimes does cause you problems with Apple, but was vaguely OK if and only if the downloaded functionality was run through JavaScriptCore: the old version of this restriction essentially used to say "only if run in WebKit" (and I got manual clarification once that they were OK with JavaScriptCore, though I think they also made that explicit in the rules at some point).

[saagarjha]

> "All the scripts, code, and interpreters" are not, in fact, packaged with the app as you are able to download arbitrary binaries using curl/wget or apk.

I'm making a distinction between the code that's downloaded and interpreted and the actual app's code, which is important because I can download a FRACTRAN (or your favorite Turing-complete language) interpreter written in Python and run it in Pythonista and run afoul of this rule unless you take the interpretation of "scripts, code, and interpreters" being the ARM code that is running natively on the device that implements the emulation system. So if you look at the "arbitrary binaries" (which just so happen to less readable, non ASCII "source code" for iSH) being equivalent to Python scripts, there really is no issue here. No native code is being downloaded, generated, or executed in either case.

[saurik]

You are making a distinction that this clause went far out of its way to keep you from making :/. When Apple says "scripts" and "code" they are absolutely and clearly talking about the code that is being interpeted, not the interpreter itself (which they call "interpreters").

Pythonista, which is "borderline", might actually be possible to claim is an educational app: the person who wrote it seems to discuss it like that, and that is often how it is used. Apple seems to want to allow apps that are able to be used for teaching people to program. That is not the stated purpose of iSH nor is it how most people seem to want to use iSH.

You just really really seem to want to believe that this is OK based on this clause, but you are past the point of "stretching" and are now just seemingly purposefully refusing to understand Apple's restriction and also seem to not understand that this isn't some black and white "letter of the law" sort of thing but a massive grey area of "what is Apple's intention here" (which includes wanting to avoid creating a little app ecosystem inside of another app, which the binary package manager here clearly does).

[saagarjha]

> When Apple says "scripts" and "code" they are absolutely and clearly talking about the code that is being interpeted, not the interpreter itself (which they call "interpreters").

They can't be, because all of these are lumped together in the category of "must be bundled with the app".

> Apple seems to want to allow apps that are able to be used for teaching people to program. That is not the stated purpose of iSH nor is it how most people seem to want to use iSH.

I mean, you could repackage this as "learn the Almquist shell".

> You just really really seem to want to believe that this is OK based on this clause

Because that lets it be on the App Store!

> you are past the point of "stretching" and are now just seemingly purposefully refusing to understand Apple's restriction and also seem to not understand that this isn't some black and white "letter of the law" sort of thing but a massive grey area of "what is Apple's intention here" (which includes wanting to avoid creating a little app ecosystem inside of another app, which the binary package manager here clearly does).

I think we both understand Apple's restriction on alternative App Store environments, and I agree with you that the software as it currently stands will likely never pass actual App Store review with apk bundled with it. But I still think it's possible for it to be approved provided it shipped without it, even if getting a package manager onto it would be possible because it it exposes the filesystem through iTunes file sharing, as well as allows for downloading one. As you've mentioned, this is really about perception: if Apple thinks you're trying to make an "App Store" inside your app, they'll quickly shut it down, but if you make it annoying but possible to do something like this in-app they might buy the argument that it wasn't your primary intention.

[saurik]

> They can't be, because all of these are lumped together in the category of "must be bundled with the app".

...that's the point: they are explicitly saying that both the interpreter and the code being interpreted must be shipped with the app, as that clause is directly saying you can only have an interpreter if there is no scripts or code being downloaded to later run on said interpreter.

> I mean, you could repackage this as "learn the Almquist shell".

...but they didn't. This same argument is the argument "in some theoretical alternative reality my BitTorrent client is mostly used to download files that can be legally redistributed, so the fact that even I am not using it in this way should not be counted against it"... but it isn't.

> > You just really really seem to want to believe that this is OK based on this clause...

> Because that lets it be on the App Store!

Whether this is to be allowed in the App Store has very little to do with what Saagar has chosen to believe, particularly if that choice has been made out of convenience.