The MAS is Apple's storefront. Of course their own software is going to be distributed via it, whether or not that software is sandboxed. The existence of non-sandboxed Apple software on the MAS does not impact 3rd-party MAS software in any way, shape, or form.
Basically, the goal of the MAS is to be able to sell software that users can implicitly trust to not be harmful. For Apple software, users can trust it because it's Apple. For 3rd-party software, the only way to ensure the trustworthiness is to require sandboxing. Apple software should be sandboxed when possible, because that minimizes the downside of certain classes of software bugs, but beyond that one scenario, there's no reason to care whether Apple software is sandboxed.
Yes, there are certain classes of 3rd-party software that cannot be shipped on the MAS because of sandboxing. But Apple allowing their own software to ship un-sandboxed has no bearing on this. The sandboxing requirement would prevent this 3rd-party software from shipping on the MAS regardless of whether Apple sandboxed their own apps.
The only real argument to be made here is claiming that 3rd-party apps should be able to ship on the MAS without being sandboxed, but that runs counter to the entire purpose of the MAS and will never happen.
The only really useful thing to actually try and get Apple to change is to expand the sandboxing capabilities to allow certain things that 3rd-party apps want to do and cannot do today. They've added more and more capabilities over time. The question is what functionality can be effectively exposed to sandboxed apps without opening up a security hole.
> The request to remove functionality due to (M)AS rules leads to an inferior experience for customers, as those customers can longer access that functionality.
That functionality should never have been in the MAS app to begin with. In the case of GaragePay I'm assuming they used a temporary sandbox exception, as Apple allowed those when sandboxing was new to give 3rd-party apps time to adapt, and to find out what exemptions were commonly requested in order to figure out in what ways the sandbox needed to be extended. If that's the case, then GaragePay's developer should have known from day 1 that they'd eventually have to remove this functionality (assuming the sandbox would eventually allow for invoking `hdiutil` should have been obviously unlikely from the start).
In most publicized cases, the app that gets the rejection that requires removing functionality was always in violation of the rule, and were just hoping to not get noticed. Sometimes that works, sometimes they get caught. And when caught obviously violating an existing rule, there really should be no surprise at all that Apple requires compliance with the rule. And there should be no outrage either, or claims that Apple should allow the app to continue violating the rule. The only really valid argument here is that Apple should be consistent in applying the rules, and I think everybody (including Apple) agrees on that point.
It's the cases where Apple rejects an app for what many believe is an improper application of a rule that deserves community outrage. In this case, I think the App Store reviewer is incorrectly applying rules meant for regular document storage as if it had anything to do with iCloud Drive. But please note that Panic is not asking for community outrage. They're just explaining to their users why the functionality is gone. I expect they're taking the right steps privately, talking to the Review Board and whatnot.
Also note that the claim "Apple shouldn't apply that rule, because it removes app functionality, and that's bad for users" is quite ridiculous. Apple not consistently applying certain rules is the #1 complaint people tend to have with the App Store review policies. And claiming that "user functionality" is so holy that it must be preserved even when it obviously violates the rules makes no sense. The fact that an app manages to sneak rule violations past the review board in the past does not in any way mean it should be able to do so in the future, and the fact that an app relies on rule violations in order to provide functionality does not mean it deserves to be able to violate the rules.
> It means that if you want to distribute via MAS, you have to cripple (or remove) part of your app's functionality in order to pass review. Again, nothing inherently wrong with that but the net effect is that your software might be inferior when distributed via the MAS vs outside.
If your app requires violating app store rules for certain functionality, then you shouldn't be using the MAS as your distribution channel. It's that simple.
> I don't know how you came up with that, it was never said nor implied in any way whatsoever.
That was the subject of the immediately prior sentence. It provided the context for the subsequent sentence, and was the natural choice for the meaning of the word "it", except in that it didn't make much sense. Which is why I asked for clarification.