7 ms·

> Wait, that app had a fake keyboard inside a notification center widget? That's truly awful and roundly deserved to get rejected. While the tastefulness of th

• eridius 12y ago
  > Apple are themselves exempt from the restriction to ship sandboxed apps - this is hypocritical. What makes it hypocritical? Apple developed the OS that you're using, so there's hardly a trust issue when talking about running applications from Apple on top of the Apple-developed OS. Sandboxing doesn't exist because of some high-minded ideal, it exists to solve the trust and security problem. Apple should sandbox any apps they ship if at all possible, but only because it protects the app and the user from any security issues. If an app can be remotely exploited somehow, then being sandboxed prevents the exploit from having full access to the local filesystem. But beyond that one concern (which may not even be relevant for apps that don't really do anything with the network), there's no real reason to care whether Apple sandboxes a given app that they ship. > Moreover, it objectively leads to a worse experience for customers What does? You're being a bit unclear here so I don't know what you're referring to with "it" here. Apple being exempt from sandboxing restrictions leads to a worse experience for customers? Doubtful. > It's an example how the MAS effectively cripples 3rd party apps without leaving them a choice What do you mean, without leaving them a choice? The MAS is just one of many storefronts available to Mac users. 3rd-party apps that don't wish to sandbox always have the choice of not using the MAS. They can continue to work exactly as they have done for the past several decades. The MAS is relatively new and is not replacing any existing software delivery mechanism, nor is it imposing any restrictions on apps that choose to ship outside the MAS. It doesn't even prevent users from migrating to a non-MAS variant of the app later; it's been well-known for a long time now how to have an app that supports both MAS and non-MAS distribution channels and have the non-MAS app still validate the MAS license.
  • milen 12y ago
    > But beyond that one concern (which may not even be relevant for apps that don't really do anything with the network), there's no real reason to care whether Apple sandboxes a given app that they ship. The concern is that if you want to ship software on the MAS, like some of Apple's, that requires certain functionality which does not have a way to be accessed if you're sandboxed, then you cannot - while Apple can. As I mentioned multiple times, it's Apple's platform, they make the rules and can do whatever they want but this means that there are certain classes of software that cannot be distributed via the MAS by 3rd parties, only by Apple as they are not bound by the same rules. > What does? You're being a bit unclear here so I don't know what you're referring to with "it" here. 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. > Apple being exempt from sandboxing restrictions leads to a worse experience for customers? Doubtful. I don't know how you came up with that, it was never said nor implied in any way whatsoever. > What do you mean, without leaving them a choice? 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.
    • eridius 12y ago
      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.
• baddox 12y ago
  > The real question is: where do we draw the line? Indeed, and it's not so simple with your "users should be able to dice for themselves whether it's acceptable" belief either. What about malware? The user clearly gave permission for the app to be installed. Who are you to say they didn't want that software to run on their device?
• nemothekid 12y ago
  >While the tastefulness of that solution might be questionable, I believe users should be able to decide for themselves whether it's acceptable or not. The counterpoint to this is that users have a far, far lower standard for interfaces than Apple does which means developers spend less on the actual functionality of their app. While the examples you posted are unfortunate apps that got caught in cross hairs, I believe that the App Store on mobile is better due to Apple's insistence of UI control.