Mac App Store review folly

April 19 2021 by Jeff Johnson

On April 13 I submitted Link Unshortener 7.0 to App Store Connect for review. It was approved with no issues, and I released the update in the Mac App Store the next morning. This was the sixteenth release of Link Unshortener. By pure coincidence that I'm just realizing now, Link Unshortener 7.0 shipped exactly one year after Link Unshortener 1.0. The update added a great feature worthy of the anniversary, but it became clear that the new feature needed refinements, so I submitted another version to App Store Connect three days later. While I was asleep that night, my submission went into review and was rejected. In the morning I read the unpleasant news:

Apr 17, 2021 at 1:00 AM
From Apple
Guideline 2.4.5(i) - Performance


In order to continue reviewing your app, we require additional information.

Your app uses one or more entitlements which do not appear to have matching functionality within the app. Please describe how and where the app uses the following entitlements by adding your comments to Resolution Center. You will not need to upload a new binary to provide this information.

Apps should have only the minimum set of entitlements necessary for the app to function properly. If there are entitlements that are not needed, please remove them and submit an updated binary. You will need to Developer Reject the app to upload an updated version.

---
• com.apple.security.files.user-selected.read-only
---

What is the "com.apple.security.files.user-selected.read-only" entitlement? Apple's documentation is quite brief, but the entitlement seems pretty harmless. Moreover, the entitlement is ubiquitous. Create a new Mac app project in Xcode and look at the app target's Signing & Capabilities. Then add a share extension to the project and look at its Signing & Capabilities. Finally add a Safari extension to the project and look at its Signing & Capabilities. They're all the same under App Sandbox: File Access Type "User Selected File", Permission & Access "Read Only":

In other words, the "com.apple.security.files.user-selected.read-only" entitlement is the default, pushed on all Mac developers by Apple's own developer tools every time they create a Mac app or a Mac app extension. Thus it should come as no surprise that almost every app in the Mac App Store has this entitlement. Link Unshortener 7.0 had the entitlement, as did all fifteen previous releases of Link Unshortener, and indeed every app I've ever released in the Mac App Store. Yet for some strange reason, after all these years, app review suddenly decided to reject me for it, a mere three days after approving it without question for the umpteenth time.

Was this a change in the "unwritten rules" of the App Store? I don't know. Who does know the unwritten rules, besides Apple? It's frustrating for App Store developers that some rules are unwritten, and applied inconsistently. (The written rules are applied inconsistently too, but at least we can read them, cite them, and try to follow them.)

Let me skip now to the end of the story: I released Link Unshortener 8.0 yesterday in the Mac App Store. If you have the update installed, enter the following command in Terminal:

In the output you'll see this:

<key>com.apple.security.files.user-selected.read-only</key>
<true/>

That's right, the app still has the entitlement it was rejected for. I simply argued with app review, using more or less the same words as in this blog post, and they ultimately approved the submission unchanged. You may ask, why didn't I "simply" remove the entitlement and submit a new build? Two reasons:

1. The testing. Link Unshortener supports four macOS versions — Big Sur, Catalina, Mojave, High Sierra — and two architectures — ARM, Intel. I already tested the update before I submitted it, but I wouldn't feel comfortable removing an entitlement and submitting a new build without testing. Would something break? I don't know! I've never tried it without the entitlement. I would have to test every part of the app in every configuration just to make sure that something didn't somehow break. This would be a significant investment of time and would also significantly delay the release, because even after testing I'd have to reject the previous binary and go to the back of the review queue again.
2. The principle. It's fair for Apple to change policies, but it's not fair for Apple to suddenly change them without notice, or to fail to publish the policies in the first place. Xcode has been pushing the "com.apple.security.files.user-selected.read-only" entitlement on us for ten years, and this seemed fine with the App Store too all these years… until a couple days ago. If it turns out that "com.apple.security.files.user-selected.read-only" is unnecessary for my app, and Apple wants it to be removed, then I am happy to remove it… in a reasonable amount of time. But I won't tolerate a metaphorical gun put to my head, forcing me to remove the longstanding entitlement immediately on threat of not being able to release an app update that's important to me and my customers. So I'm going to fight that. I did fight it, and I "won". At least I won this battle, if not the war. In any case, there's a kind of insanity in rejecting an update for an entitlement already possessed by the version of the app currently available in the App Store. If the entitlement were somehow "dangerous", then I could keep the dangerous entitlement simply by not updating my app, and Apple would apparently be fine with that.

What are the lessons here? For Mac App Store developers, be warned that app review may flag you for the "com.apple.security.files.user-selected.read-only" entitlement at any time, so you may want to investigate removing it preemptively if you don't need it. However, if app review does flag you for it unexpectedly, don't reflexively cave in to their demands. You can argue with them and still get approved.

For App Store customers, the lesson is that you ought to be very skeptical about App Store review. After all, if I can argue an app reviewer into accepting my submission despite their reservations, then so could a scammer! Note that I never actually explained to app review why I needed the entitlement. I don't know whether I do need the entitlement. Perhaps I don't. ¯\_(ツ)_/¯ Any experienced App Store developer ought to know that app review is a joke, mainly security theater that all too often impedes honest developers while inexplicably overlooking obvious scams. Some of us have been trying to explain this to the public for years, and I think people are finally getting a clearer picture of the situation. You can trust me as a developer because I've proven myself trustworthy over 15 years of shipping Mac software. But don't uncritically place your trust in the App Store itself to protect you. Caveat emptor!