Apple Announces App Store Small Business Program

It can be a problem in practise since the rules aren't fairly or consistently enforced. Look to recent issues with iSH being approved and rejected.

Edit: as others have pointed out iSH isn't the best example of this.

While I agree the rules are often inconsistently enforced, and I'm a fan of iSH, I think the real surprise is it was ever approved in the first place, as it seems to clearly be violating the "spirit of the law" regarding Apple being pretty clear they don't want apps that allow arbitrary binary execution.

iSH tried to circumvent this with a technicality, and it seems to have initially "worked", but I think it's a poor example of an app unfairly/inconsistently targeted.

iSH is definitely in the “pushing the boundaries of the rules” area of apps (x86 emulation) and probably shouldn’t have been allowed if you took a strict interpretation of the rules.

OP is just saying 99% of apps being developed are clearly within the rules, rather than really pushing against the boundaries of what is allowed.

OK fair enough perhaps it wasn't the most cut and dry example. But it was the most recent I could think of.

I worked on the iSH appeal, and have of course watched this space for years, so I've gotten very familiar with the "spirit of the law" to the point that the conversation with Apple ended up really being a confirmation that our interpretation of the law was correct and that iSH was fine under the rules that Apple enforces. Your characterization isn't quite right. Apple doesn't want to not have apps that allow users to execute code, in fact they themselves write apps that let the user execute code they write and demo them at WWDC (Swift Playgrounds? Shortcuts?). Some of the best apps on the App Store let you write code and run it. Saying iSH is in violation of those rules would require pulling down those apps too.

What Apple is really trying to do is prevent apps from changing their behavior after they review them in a silent way to bypass the usual process. The real issue here is that their guidelines don't reflect this and this confuses the reviewers (and evidently commenters here on Hacker News). What needs to happen here is Apple clarifies their guidelines so that we don't have rules that can be inconsistently enforced.

(If you need more to convince you, I'll point you at the stuff I wrote when that was going on: https://saagarjha.com/blog/2020/11/08/fixing-section-2-5-2/).

Well, that is the crux of the matter: the rules are not written correctly because they allow iSH to be inconsistently judged if you take "a strict interpretation"; there should not be a strict interpretation; it should just be "this app is reasonable" and "this app is not" and not "hey this looks like it's running code…does that make it a security risk?" which reviewers are not equipped to answer.

When we made the appeal for iSH we correctly surmised that the point of the rule that was cited was to prevent apps from bypassing App Store review, which iSH does not do in the slightest. Taken from the real perspective from which the app should have been judged, iSH is not at the boundary at all; instead it's the apps that do things like undisclosed A/B testing and feature flags to hide things from review. So what happens is developers like us who are actually clearly within the rules as they are meant to be applied get caught in limbo at the whim of reviewers who misunderstand the guidelines because they aren't written as they are supposed to be enforced.

I think the fact that the guidelines are written as such to make people think it wasn't a cut and dry example is really what makes it better example than you might have even though it was at the beginning. The rule Apple would like to enforce is very clear, and we know what it was and the review team didn't, because the guidelines didn't reflect the rule that Apple wanted to enforce (and thus ended up enforcing it inconsistently). A situation where developers have to tell the review team how the guidelines work because they're not written down explicitly is a very untenable position and one that needs to change.

Hmm, that's fair. I don't use iOS much myself, so I'm not very familiar with what's available on the App Store. It does appear that at least Swift Playgrounds allows for projects (including code, which is interpreted) to be downloaded off the Internet, extending the runtime beyond what is available "at time of review".

That said, briefly looking over some scripting/IDE environments not from Apple, it looks like most of them ship "batteries included" and don't allow for content to be pulled from online.

It seems to me the equivalent of iSH shouldn't be, say, a Python interpreter/IDE, but a Python runtime including pip and the ability to pull modules from pypi.org.

OTOH, Python itself is so reflective, I imagine there's probably some way to self-inject modules within a script, if you have any sort of web access. And since you can tunnel TCP over DNS, even a hostname lookup is enough. So I'll conceded the point, since most scripting runtimes probably have some kind of EVAL routine to invoke the interpreter, or a porthole into the interpreter's bytecode.

That said, my own original point was about developers/businesses feeling uncertainty about Apple's rules, and worrying if an app would even be accepted. I feel like almost any developer would instinctively thing iSH's premise of being a program interpreter for the Linux ABI would be rejected by Apple.

Whether or not the underlying rule is fairly applied aside, it's clearly something Apple wants to prohibit. Albeit, I'm kind of baffled myself at why, especially in iSH's case where the emulated runtime is completely separate from the "real program text", with no escape hatches out IIRC. Seems utterly ridiculous to me, especially when you can accomplish something similar in WebKit/JSC I'm sure, just not offline. :-/