AFAIK, even the iSH developers were never given a proper explanation. iSH was actually removed a few years back[0] and then reinstated with an apology but no policy changes or clarifications.
This was before the change to allow Delta on the App Store, too.
There's a lot of nuance here. Some of it is ours, some of it is on Apple's side. Before I get into it I will say that most of what I say about Apple's side is largely not a position they will clarify or take publicly, and some of it is our interpretation. When iSH was removed from the store we did push them to clarify this in the App Store Review Guidelines but they chose to not do so.
When you run an App Store that involves human review the big problem you have is apps that mask their behavior during review and then end up breaking the rules later. My understanding is that the "don't download code" policy is intended to prevent this, at least in spirit. I think, at least at the highest level of the company, the intent is to keep to somewhere near this at least for submissions made in good faith and not prone to opening them up to a slippery slope. There are distinctions here, though, and policy enforcement is also complicated.
My (and iSH's) position is that "code" should be interpreted very broadly, including native code (which the platform blocks from loading anyways) but also things like embedded webviews updated server-side or those "code-push"/"run JavaScript in an interpreter in your app" things. And going even beyond that, I feel that to provide a full experience for the review team when you ship a feature flag you really ought to list all the behaviors that the app can possibly have, and let the review team test that if they want.
From this perspective you will note that code isn't even really the interesting part here, it's the behavior changing that matters. So this leads naturally what we have described as "scripting apps", which download code but do not change their behavior. Their entire point is to download code. Like, App Store is an app store, regardless of whether you download TikTok or Google Maps from it. iSH is a a Linux environment. Nothing you will do in the app will change that. And notably we have zero ability to change that ourselves, short of submitting a new app. It's not like we can just add Windows emulation as a downloadable JavaScript package without going through review. From our discussions with leadership, I think they agree with us on it, but are not willing to commit to it publicly, because then people will take creative bad-faith interpretations of it to argue what a feature of the app versus something a user does in the app is, or something like that. Or they just want to hold all the cards and reserve the right to take this away. Either way I strongly disagree with them doing this, but for now iSH remains on the store.
You will note that the changes we make (see our blog post about repositories: https://ish.app/blog/default-repository-update) continue to support that position. Again, I cannot say for sure whether this is the interpretation Apple uses, or if they even have a consistent position. It's just an attempt on our side to show good faith. As a final note our experience has been that the higher you go the more consistent and reasonable review becomes, but the front-line reviewers often take stupid, unreasonable positions like you'd see in a Hacker News comment (it says code therefore your app for coding is bad). But again, this is just our experience; we have no idea if Phill will hit his head tomorrow and decide to pull iSH tomorrow because he thinks Linux is the child of the devil.
>As a final note our experience has been that the higher you go the more consistent and reasonable review becomes, but the front-line reviewers often take stupid, unreasonable positions like you'd see in a Hacker News comment
A sadly universal experience. Especially when the not-so-secret is that that frontline is often contracted or outsourced. They do not understand (by design) the subtleties of submission of creative content. They are simply cheap help to do the bare minimum to remove liability, and if a few false negatives happen during that time, oh well. thousands of other apps in the sea.
So like everything else, if you havev the money, clout, or simply sheer persistence (which shouldn't be necessary) then you can force yourself to someone who can actually help. But few will get there, even with persistance.
What you've said largely tracks with my interpretation of Apple's actions here.
> I feel that to provide a full experience for the review team when you ship a feature flag you really ought to list all the behaviors that the app can possibly have, and let the review team test that if they want.
After Epic added direct purchase gated behind a feature flag to Fortnite, I'm genuinely surprised Apple didn't start requiring full control over and documentation of all downloadable configuration files as part of App Review.
While being vaguely on the side of review being not very useful I would agree with Apple doing that if only to make their position more consistent, even though I am sure every developer would riot if this was the case. (Although I vaguely remember someone saying we provided feature flags to Apple when we submitted builds at Twitter. But do take it with a grain of salt, since I wasn't on the release team and my view of them is vaguely positive in that I think they generally didn't try to use tricks to get through review.)
Odds are their "front line" reviewers are not highly technical, so Apple wouldn't want to commit to that. They are more than large enough to afford a few inefficiencies and pick fights the few times something like iSH "slip in".
Lot of stuff can skirt by until it doesn't. That's how stuff like Beeper suddenly explodes into a kerfluffle in a matter of days over some dang blue bubbles.
