I don't actually feel too bad about iSH being flagged by a non-technical reviewer. It's a specialized app that has characteristics similar to apps that are genuinely against the App Store Review Guidelines. That it gets scrutiny is a sign that the process is working as it says it should, rather than just receiving rubber-stamp approval as is also all too common.
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.
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.