Permute Rejected From the App Store
The update got rejected because someone at Apple suddenly (this feature in this form has been around from the very beginning) decided that Permute does not correctly implement the option to detect external subtitles. This feature allows Permute to detect .srt or .ass files in the same folder as the video file and merge them together.
[…]
In order for Permute to be allowed to automatically scan the folder, it needs to show you an Open dialog where you select the root folder (i.e. your start-up drive, in technical terms the path “/”). This is so that it covers external drives as well.
Now, out of the blue, Apple has decided the the open dialog must not open with the root folder selected, but must be opened with the home folder selected.
[…]
In case you are fans of irony – the official rejection reason says “app does not achieve the core functionality” – yet it does and Apple is forcing me to break it.
See also: Jonathan Deutsch.
Previously:
7 Comments RSS · Twitter
Great program. Available on SetApp, which puts the App Store to complete shame.
Why in heaven's name is the blog post image (at Monroe's site) of an iPhone... if he's talking about a macOS appstore app? (Which he is.)
I recovered eventually. ????
I mean opening root is clearly working around sandboxing, so I’m not surprised this was eventually rejected.
But this exact problem has been well known and should have been fixed by Apple in a sandbox-friendly way a long time ago.
In a comment, they write:
All external drives are connected at /Volumes/ – which means that in order for Permute to access those, it needs to get permission for / (root folder). Of course, it’s not writable and the system will not allow any writes there (so there’s really not harm), but it grants access to /Volumes/ – and that’s important! If the permission is granted for ~/, then the app will not get access to the external drives.
This is not something the average user knows or even should know. This should be something easy for the app to do.
But that’s not how this is supposed to work, is it? The whole point of this mechanism is that an app doesn’t get blanket access to the entire file system including additional volumes. It’s a file converter, so none of this should be necessary. Have the user pick a folder that contains videos, and convert that.
Confusing remarks from App Review aside, I think Apple’s current reasoning is sound. Tricking the user into picking the entire file system is exactly the kind of thing a malicious app would do. And it just isn’t necessary here.
But this exact problem has been well known and should have been fixed by Apple in a sandbox-friendly way a long time ago.
But it has been, hasn’t it? Rather than letting an app access everything, the user is asked to interactively opt the app in.
@Sören It's not really fixed because getting a dialog for each different containing folder is a bad user experience. And there’s still the kernel bug where it stops working after a certain number. Apple doesn’t have any written guidance on selecting the root folder, but they let BBEdit do it.
Obviously, that bug should be fixed.
But the discussion seems to have shifted to "we don't believe the App Store should mandate sandboxing at all" (if an app gets access to the entire file system, what meaningful sandbox is there any more?), which is certainly a valid viewpoint.
(Personally, I would prefer if the App Store just showed a "This app may be unsafe to use." kind of warning.)
I don't think a video converter is a great example of requiring access to the entire file system. A text editor is trickier, because it will often access tooling from all over the place. And yes, UX and security are always a tradeoff. To me, it frankly sounds like Monroe added the thought process behind sandboxing after the fact, which I can sympathize with especially in the early era where Apple launched the MAS, then unilaterally decided after the fact to make sandboxing mandatory. But that was, what, a decade ago?
@Sören Sandboxing would ensure that the app has read-only access. And maybe the sandbox should support granting access only to files with certain extensions, but it doesn't. I think the App Review position is basically security theater.
