Archive for November 9, 2020

Monday, November 9, 2020

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:

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.

Updating to Catalina, Finally

Yesterday, I finally updated to Catalina, straight to 10.15.7 with the supplemental update. It still has issues, but they no longer outweigh not being able to run Xcode 12 directly from 10.14.

The best part so far is being able to run NetNewsWire 5.1, which has some great new options for only showing unread feeds and articles.

The worst part so far is the backup situation. It’s no longer possible to directly make an encrypted clone with Carbon Copy Cloner or SuperDuper. Even if you have an existing clone from a previous version of macOS, you can’t Smart Update it. You have to first clone to an unencrypted container, then boot from the backup and enable FileVault. This sounds simple, but I cannot overstate how frustrating and time consuming it is. (And, of course, your data remains unencrypted during this time.)

Booting from an APFS volume on a spinning hard drive takes forever. Don’t forget to hold down the Shift key after logging in or it will beachball for an additional 20 minutes while relaunching your apps. Even so, some of them (launch agents?) still relaunch, and that can take a while. I was greeted by a dozen or so dialogs complaining about the Bonjour name, Little Snitch’s rules, my Apple ID needing to be logged in again, iMessages from long ago that failed to send, etc.

The first time I did this, I made the mistake of trying to enable FileVault via System Preferences. That takes multiple minutes between each click, and twice the Security pane failed with a “Preferences Error” and bumped me back to the main System Preferences window.

The faster way is to open Terminal and type:

sudo fdesetup enable -keychain

This command takes about 5 minutes to start the encryption process, but at least it’s reliable and unattended.

After rebooting from your regular drive, you can connect the backup, enter the password, and let it finish encrypting in the background. You can check the progress using:

diskutil apfs list

At first, I thought it was stuck because it stayed at 5% for 2.5 hours. 6 hours later, it is still only at 16%. This is for a 1 TB drive that’s only slightly more than half full. At this rate, it will take days to finish this one drive, the first of many. Prior to macOS 10.15.7, it would simply encrypt while cloning, taking virtually no extra time.

Previously:

Update (2020-11-20): Another issue is that enabling FileVault on a backup drive sets the passphrase to the relatively short login password. I like to use a longer passphrase for drives that will be stored off-site. APFS passphrases cannot be changed in Disk Utility. You can do it with System Preferences, but that requires booting from the drive again, which is very slow. The faster way is to use Terminal. First, use:

sudo diskutil apfs list

to find the “APFS Volume Disk” for your “Data” partition, disk4s2 in my case. Then use:

sudo diskutil apfs listUsers disk4s2

to find the UUID of the “Local Open Directory User.” In my case, that’s 414C4BC7-B641-44E8-A681-911B2030F7AE. Then tell it you want to change the passphrase for that user:

sudo diskutil apfs changePassphrase disk4s2 -user 414C4BC7-B641-44E8-A681-911B2030F7AE

MagSafe Duo Charger

Matthew Panzarino:

It’s a folding dual travel charger that will hold both an iPhone using MagSafe and an Apple Watch using its more traditional magnetic charger.

[…]

For context, you have to understand that this thing is $129 but feels like it should be $70. When you realize that it is a charger that doesn’t come with a power adapter, I would not be shocked if you mentally downgraded it to $40.

[…]

I’m sorry to say that I find the whole thing a bit underwhelming after the hype of AirPower and its eventual demise.

Nick Heer:

I still think — perhaps irrationally — that it is totally fine to remove the power adapter and headphones from iPhone boxes this year […] But I do not understand why this product, regardless of price, does not include an adapter. Someone buying this is almost certainly going to either throw it in their maybe I can travel again bag or set it up on their night stand. Either way, they are going to need a thing to get electricity out of the wall and into the wire. And, sure, you can use any old Lightning cable and adapter you have kicking around, but it’s going to charge slowly, which rather spoils the point.

Previously:

Fragile Spotlight Comments

Howard Oakley:

Finder Comments, also known as Spotlight Comments, are such a good idea.

[…]

The worst possible place you can store metadata is in a separate file, such as a hidden file of proprietary format located in the same folder. But that’s exactly where Finder Comments are saved. Worse still, as if recognising the error of its ways, Apple duplicated them in an extended attribute (xattr), only that isn’t kept in sync with the other copy. The end result is that Finder Comments are as reliable as loose scraps of paper, and just as easily lost.

This dichotomy is one of the reasons I wrote EagleFiler. I like the idea of comments so much that I wanted to remove the limitations (length, plain text, restrictive editor) and store them in a more secure and open way.

Fortnite to Return via Streaming

Hartley Charlton:

Plans are in place to allow users to play Epic Games’ “Fortnite” on iOS and iPadOS again using Nvidia’s GeForce Now cloud gaming service in Safari, the BBC has discovered.

[…]

Using an online streaming service will allow Epic Games to circumvent Apple’s ban on the game as an app. iPhone and iPad owners will be able to play Fortnite without charge through GeForce Now’s free basic tier, though Nvidia limits these sessions to a duration of one hour.

[…]

The service is already available for Mac.

Sweet.

Previously:

Update (2022-01-19): John Gruber:

If this works and Fortnite inside iOS Safari — as a web app! — works as well, or is even in the same ballpark, as the native Fortnite app did, this will be a landmark achievement and a technical marvel. If it’s not even in the same ballpark as native Fortnite, I don’t understand why Epic would put the Fortnite name on it.

Copyright © 2000–2024 Michael Tsai.