(no title)
4eleven7 | 3 years ago
EDIT: To clarify 'very much an edge case', I mean, you can see how a non-technical reviewer at Apple may view iSH as a program that executes remote code. While you or I may know better, and it is unfortunate that you had to go through that process in the first instance, you can see why it happened compared to a standard todo list, or a typical web-client based app.
saagarjha|3 years ago
The specific issue is that iSH did end up getting reviewed by non-technical reviewers. We went through at least four levels of appeals, and about half a dozen interactions with people doing review. Several of these people gave the obvious impression that they understood what our app did, and might even be personal familiar with Linux/the command line. The core issue was not a technical one, but a policy one: our app does execute remote code. The reviewers read this as being "any remote code". Our (correct) interpretation was that this rule was designed to prevent remote updates by the developer. A user downloading code in our app and executing it is fully within the guidelines, which we ended up confirming with the highest levels of the review team once the app had been re-approved.
The core problem is that the actual guidelines (which includes both the written guidelines, and a bunch of "case law" that supplements it) is only really known within Apple to a handful of very senior reviewers, and getting to them is very difficult and requires an exceptional appeals process. For iSH, you can see how the written guidelines were misinterpreted by technical people; for apps like these it is very possible that they get flagged by some sort of "game includes IP that's not yours" or "app is unplayable on Apple Watch" and the person who would review this Quake game could get flagged even while complying with the guidelines.