Apple cracks down on iOS terminal apps because they can download code
iSH spared for now, but what will happen to a-Shell?
Two iOS terminal applications popular with developers – a-Shell and iSH – have run into problems with Apple, which has said they breach its App Store Review Guidelines, though iSH has been spared deletion after an appeal.
The iSH application is an open-source Linux shell for iOS using a x86 emulator, and at the time of writing is at number 2 in the App Store Developer Tools chart. Tutorials on the wiki include instructions for installing PHP, running an SSL server and Ruby programs, installing the R statistics project, installing a Python web server, and more. The wiki also warns that "much of the emulation is still not finished, and many programs will fail."
These are powerful tools for developers as well as being handy for something as simple as performing a ping to check network connectivity. They are also running into problems with Apple thanks to clause 2.5.2 in its App Store Review Guidelines, which states: "Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps." Apple does make an exception for "educational apps designed to teach, develop, or allow students to test executable code."
iSH developer Theodore Dubois has long been aware that his application may breach Apple's guidelines. He first submitted iSH in May this year, but it was rejected on the grounds that it "allows the user to install Linux executable code." He discussed the matter with someone at Apple during the company's WWDC developer event, and learned that removing a package manager called apk (Alpine Package Manager) might or might not get it through. Apk was removed and success! "We submitted this on October 20, it was approved the next day, and we launched on the 22nd," said Dubois.
Not so fast. A few days later, Apple called to say it had found wget in the application, which downloads files from the internet, and that this was in effect also a package manager (perhaps because users had worked out how to use wget to restore apk).
Duboi said: "The nature of iSH meant that this problem was fundamental, as users can always add back functionality that we remove." The app was set to be removed from the App Store, but some social media fuss ensued, and Apple relented. "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. We'll stay in contact with them to work out details," said the iSH team.
In the meantime, the a-Shell developers popped up to say: "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." Curl is another command that is able to download files.
When will a-Shell be removed if the appeal is unsuccessful? "Our 2 weeks delay started later, and is suspended while the app is undergoing an extensive review," said the team.
Why has Apple done this?
There are several reasons for the 2.5.2 restriction. Apple cannot review an application for security or conformance with other guidelines if it is in effect a runtime that might download and run any arbitrary code. The company is also keen to prevent alternatives to its own official App Store, and to protect its 30 per cent fee for transactions made through in-app purchases – this is the subject of a long-running dispute with Epic Games.
In practice, there seems to be some leeway. The question of what is and is not an "educational app" is somewhat subjective, and a question now is why iSH might be considered OK but a-Shell not. "Why are lli, Python, Lua and TeX good, but not wasm?" asked a Twitter commenter, the reply from a-Shell being: "I have no idea. I don't think they noticed the others."
Despite the apparent power of these shell environments, they are sandboxed just like any other iOS application. Saagar Jha from the iSH team argued that "scripting applications" should be allowed. "We can distinguish a scripting application from a normal app that is trying to update its app logic by downloading code quite easily: a scripting application keeps a clear boundary between its native runtime and the scripts that run on top of it, and it also allows users to freely edit scripts."
The key thing is not so much Apple's Review Guidelines but whether Apple chooses to allow or block a specific application. The appeal process is not transparent and Dubois complained: "I and the other iSH contributors have had an incredibly stressful fourteen days as we tried to bend over backwards to meet Apple's arbitrary scheduling while also juggling our full-time jobs."
These applications target developers and administrators, for whom they make iOS a more useful environment, so Apple will be aware not only of bad publicity from blocking highly valued utilities, but also that it risks making its iGadgets less attractive to an influential section of the market. ®