iSH and a-Shell vs. the App Store

iSH:

iSH is a project to get a Linux shell environment running locally on your iOS device, using a usermode x86 emulator.

I saw lots of people raving about this app over the last several days but assumed it would not be allowed to stay in the App Store. I don’t think it’s dangerous, or that it violates any specific rule, but it just seems like the kind of cool thing Apple wouldn’t like.

Theodore Dubois et al. (via Longhorn, Hacker News, Malcolm Owen):

On Monday, October 26th, just four days after we launched iSH on the App Store, we received a call from Apple informing us that they had found our app noncompliant with section 2.5.2 of the App Store Review Guidelines and that they would remove the app from sale if we did not submit a satisfactory update within two weeks.

[…]

Apple believes iSH is not compliant with section 2.5.2 of the App Store Review Guidelines, which governs applications which download and run executable code. Specifically, they believe that iSH “is not self-contained and has remote package updating functionality”, and suggest that we should “remove the remote network activity functionality which could allow for remote code importing into the app, such as wget or curl, or other remote network commands”. Additional communication with Apple has indicated that they believe that iSH is a security concern if we allow any sort of code importing by the user.

You would think there would be case notes or a way to contact the original reviewer to see why it was approved in the first place.

a-Shell (via Federico Viticci, Reddit, Hacker News):

FYI, Apple sent a-Shell a similar notice of termination a few days ago. Our appeal is still pending. The commands we would have to remove to stay in the AppStore are curl, pip and wasm.

Saagar Jha:

Scripting applications consist of two parts: a frontend that accepts code from the user, and a backend that runs it. As generating native code is generally disallowed for third-party apps distributed on the App Store, the backend is usually some sort of Turing-complete interpreter. Under the original “section 2.7” guideline, such apps would not be allowed on the store, as they would allow the addition of new code and thus violate the guidelines. However, it is important to note that these apps do not actually have the issue that the guideline was meant to solve: the app itself—neither the frontend nor the backend—changes, and scripts are user- and not developer-generated.

In recent years a number of factors have caused the guidelines to evolve into the 2.5.2 rules we have today—likely a combination of pent-up demand for being able to write scripts on iOS, Apple releasing their own scripting apps to the App Store, and the creation of a number of high-quality apps that ostensibly did not meet the guidelines but were “harmless” started getting accepted.

[…]

This situation is made worse when the “violation” is a misinterpretation of section 2.5.2 by the review team, especially because they are not equipped to handle such cases and create nonsensical rejections. For example, iSH was once rejected with the rationale that “During review, your app installed or launched executable code, which is not permitted on the App Store.” The template itself clearly outlines the case it is meant to apply—an app that is installing code by itself, to bypass review—but in the case of iSH the reviewer chose to install code and then complained that the app did what they told it to do. In a second case we removed the package manager from iSH, but the reviewer used the wget tool to redownload it and then rejected the app because they “found that [our] app is not self-contained and has remote package updating functionality”—functionality that the reviewer added themselves and then decided to enforce the rules on. Rejecting a drawing application for what the user can draw in it is absurd, but this is exactly how section 2.5.2 is used to reject legitimate scripting applications.

Theodore Dubois:

iOS developers know that the guidelines are merely suggestions, and you can only really find out the real rules by submitting an app for review, getting a rejection, and then asking for clarification. We had guessed Apple might flag the app under 2.5.2, but this confirmed that there’s an unwritten subrule of 2.5.2 covering package management functionality.

[…]

I asked whether removing apk would be enough, and he gave what I’ve learned is the default non-answer of App Review: “we can’t pre-approve your app, but submit it and see what happens.” So that’s what we did.

[…]

The call came from someone I’ll call Mike, who told us that “wget” is also a form of package management.

[…]

Since Mike kept talking about “remote code importing,” I asked if local code importing would be a different situation. The answer he got was interesting: any kind of code importing would not be appropriate because it would create an alternative App Store.

[…]

When asked specifically “are you saying copy/paste is OK while drag/drop is not,” he asked the tech folks who declined to answer (“we can’t pre-approve anything”). He also brought up a bizarre-sounding “core concern” that that a Linux terminal on iOS is a security risk.

[…]

With time running out, we tried submitting an App Review Board appeal, but heard nothing back—not even a message saying they were looking into it and would extend the deadline.

qwertyoruiop:

it’s pretty awful that in 2020 Apple still pretends things like this are done for security when the App Store reviews as a whole are basically a joke security-wise

Marco Arment:

iOS power users are so devoted, and so desperate for a proper terminal environment, that they made this incredible x86-emulator app with an entire Linux stack inside of it.

Instead of celebrating the skill and dedication of their most enthusiastic customers, Apple is killing it.

iOS apps are so rigidly and securely kept inside of their own containers that this literally can’t do any harm.

It’s an open-source tool for power users and enthusiasts that harms nobody and gives people a feature that Apple will never offer.

Adam Demasi:

iSH threw a revolution at the iOS platform at no cost to users or Apple, but instead of embracing this amazing work, Apple wants it gone.

Insanely useful apps like iSH get the run around with App Review, get forced to water down features to comply, and often still get removed.

Meanwhile, Apple’s Playgrounds app can execute code from the internet in a secure XPC process (private API).

Remember this when you hear Tim Cook say Apple apps don’t get special privileges.

Riley Testut:

There’s a reason @iSH_app is one of the most popular apps on @altstoreio — it really pushes the boundaries of the platform but in an entirely safe way. A big loss for the App Store

Kyle Howells:

Apple fights so hard to prevent iPads from ever reaching parity with real computers.

Adam Bell:

This is so saddening how hard their rules clamp down on dev tools.

iSH isn’t trying to be an AppStore competitor and banning its ability to import code is just so arbitrary… where does the line get drawn? What happens to all scripting apps?

What if I’m learning to code on an iPad and want to learn crypto? Am I expected to retype OpenSSL?

[…]

I really miss the days where people could push these devices past what Apple deems “enough”. The complexity and craft that went into iSH is worth celebrating IMO

Khaos Tian:

What’s worse is that with Apple keep pushing into education market with iPad, the younger generation will no longer have a device that they can go in depth and explore behind the scene stuff… The hacking culture that makes computer fun is fading away quickly.

Jason Snell:

This ruling is inconsistent with the policy for a bunch of scripting apps. The developer is doing it the right way. They should be allowed to continue. (Also iOS should just have a shell, provided by Apple.)

iSH:

We got a call this evening from someone who runs App Review. They apologized for the experience we had, then told us they’ve accepted our appeal and won’t be removing iSH from the store tomorrow.

Peter N Lewis:

Apple should just change the App Store guidelines to directly reference your Twitter follower count. If you or someone you know has a follower count > 10,000 then you can request an App Review (and they will take it seriously), otherwise, tough shit, no review for you.

Previously:

• DoNotPay IAP Shakedown
• Stadium Removed From the App Store
• Allowing Bug Fixes and Challenging the Guidelines
• Potential
• Section 3.3.1

Update (2020-11-10): Russell Ivanovic:

rUnNInG tO ThE MeDIa NeVEr WoRkS.

Glad to see Apple reverse course but getting a bit sick of this escalation and de-escalation only when they get caught. Can’t even imagine how many developers must just go quietly into the good night…

mikemee:

Or who don’t try anything interesting or innovative, for fear of wasting effort and time, or worse.

E.g. if an app update can be rejected for detailed release notes, why spend time coding something interesting. (Dropped sync between Google, Amazon & Apple for that reason)

Update (2020-11-17): a-Shell:

Appeal granted! 🎉🎉🍾🍾

We’re staying in the AppStore too.

a-Shell App Store App Store Rejection Emulator iOS iOS 14 iOS App iSH Linux Open Source WebAssembly

4 Comments RSS · Twitter

Leave a Comment

Name

E-mail (will not be published)

Web site

Δ