Hacker News Reader

> 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 that solution might be questionable, I believe users should be able to decide for themselves whether it's acceptable or not. Of course, this is Apple's turf and they can make any decisions they like. Note that lots of users quite liked Neato - should we be making decisions for them?

The real question is: where do we draw the line? Different people will have different opinions but I think most people would agree that the Panic situation, Drafts getting asked to remove their widget while others had the exact same functionality is not acceptable.

The examples I listed demonstrate a problem that's endemic on the App Store - while we might disagree on particular rejections, it's quite obvious there are issues.

With regards to the sandboxing issue on the MAS, it's relevant because Apple are themselves exempt from the restriction to ship sandboxed apps - this is hypocritical. Moreover, it objectively leads to a worse experience for customers, which I feel is against both Apple's and developers objectives. It's an example how the MAS effectively cripples 3rd party apps without leaving them a choice, while 1st party apps enjoy special privileges. Again, there's nothing inherently wrong in Apple making the rules - it's their platform after all but developers need to be aware what they sign up for when they decide to distribute their software on the MAS.

---

Responding to your updated post:

> ... But there are also plenty of valid rejections too (many orders of magnitude more). And it's a mistake to think that every publicized rejection is invalid.

Of course, I totally agree with you. I don't think anyone is arguing that every publicised rejection is invalid - I was trying to make the point that we're seeing increasingly questionable rejections that a lot of people would agree are hurting the platform itself.

> 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.

> 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.

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.

> 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 argument that I've been making for years is that proper entitlements should have existed for all the functionality necessary before the requirement for all apps to be sandboxed was introduced.

> 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.

Exactly, that's what should have been happening and has been to some extent but not aggressively enough. Part of the problem is that a lot of things pose no security threats but there are still no way to access that functionality in a sandboxed app - that's the crux of the problem.

In the case of GaragePay, it used an external utility to deal with encrypted disk images. The app has already been given access to the file via the powerbox [1], there is no additional security threat. Unfortunately, there are no APIs to operate on such disk images except the external hdiutil utility. The correct way to have resolved this was to expose APIs to access that functionality or else allow a temporary exception until such APIs exist.

> That functionality should never have been in the MAS app to begin with.

Why shouldn't it be? In almost all cases, the functionality can be sandboxed if Apple provided an API to access it securely but there just isn't a entitlement for those cases - not because it's not possible but because it's just not implemented.

> 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.

I never claimed that. I only claimed that removing functionality objectively leads to an inferior experience due to the lack of said features. In an ideal world, the correct way to have gone about it would be to provide the necessary security mechanisms to make that possible. While Apple did add additional entitlements over the years, there are still many operations that reasonable and do not pose a security threat that are still not supported.

> If your app requires violating app store rules for certain functionality, then you shouldn't be using the MAS as your distribution channel.

While that's true a statement, that's not the crux of the problem. The root issue is that if the required entitlements were available, then the app wouldn't be violating any rules at all and we wouldn't even be having this conversation.

[1] http://en.wikipedia.org/wiki/File_dialog#Powerbox

> The argument that I've been making for years is that proper entitlements should have existed for all the functionality necessary before the requirement for all apps to be sandboxed was introduced

In that case, sandboxing could never be introduced. It is quite literally impossible to provide entitlements for any and all functionality under the sun, unless you include the entitlement "allow anything" in the mix. Sandboxing is by its very nature restrictive, requiring bits of functionality to be whitelisted. That's the only way in which it can possibly ever be even remotely secure.

However, Mac apps are not required to be sandboxed. Only apps distributed on the MAS are. If you cannot ship your app with the sandbox, then you can continue to be distributed the way all apps were for the past few decades.

> Part of the problem is that a lot of things pose no security threats but there are still no way to access that functionality in a sandboxed app - that's the crux of the problem.

Can you give examples? I do not blindly accept that GaragePay's use of `hdiutil` is harmless, like you are claiming. `hdiutil` is not sandboxed, and I have no idea what kind of security audit, if any, has been done on it to see if there's any security vulnerabilities that would be exposed by allowing it to be run from a sandboxed application.

> The correct way to have resolved this was to expose APIs to access that functionality

Yes, APIs that allow for manipulation of disk images would be nice. But that's not even remotely a trivial task.

> In almost all cases, the functionality can be sandboxed if Apple provided an API to access it securely

That's practically tautological. "The functionality can be sandboxed if Apple allowed it to be sandboxed". Some missing entitlements would be trivial to add. Others would require massive work. I suspect that exposing proper APIs to manipulate the Disk Images infrastructure would require a massive security audit, and probably significant work modifying the APIs as well as I expect they probably don't meet the usability standard expected of public API.

> removing functionality objectively leads to an inferior experience due to the lack of said features

And implied that this means Apple should allow third-party apps to continue violating rules because the existing experience of using that 3rd-party application somehow trumps everything else.

Beyond that, I don't necessarily agree that this does objectively lead to an inferior experience as well. Removing insecure functionality, or functionality that relies on non-public APIs, can lead to a superior experience, because the application is now more trustworthy, much less vulnerable to exploitation, and perhaps more stable or future-proof (in the case of non-public API). So it really can be quite subjective, and quite dependent upon the particular merits of the functionality in question.

> The root issue is that if the required entitlements were available, then the app wouldn't be violating any rules at all and we wouldn't even be having this conversation.

Again, tautological. "If the app wasn't violating any rules, it wouldn't be violating any rules".

> In that case, sandboxing could never be introduced. It is quite literally impossible to provide entitlements for any and all functionality under the sun, unless you include the entitlement "allow anything" in the mix.

That doesn't follow. Sandboxing privileges present a wide spectrum ranging from providing no entitlements on one end to providing an "allow anything" entitlement on the other. Obviously, as developers, we want as much functionality exposed in a secure way but the unfortunate reality is that Apple either do not have the resources or willingness to do so.

> However, Mac apps are not required to be sandboxed. Only apps distributed on the MAS are.

While that's technically true, an argument can be made that due to the inclusion of the MAS as part of OS X, it's practically required for an app to be on the MAS as that's where a lot of the users are and it's how they get their software.

> Can you give examples?

Yes, Coda 2.5 [1] was not released on the MAS due to sandboxing issues. There are some radars on openradar [2] referring to other sandboxing issues, too - some of them are reasonable. Obviously, I do not have access to Radar itself otherwise I would have provided more examples.

> But that's not even remotely a trivial task.

I don't see that as a valid excuse for not providing an API while at the same time rejecting the usage of a temporary entitlement due to lack of said API. It's a given that providing functionality in a sandbox compatible way would not be trivial - the work needs to be done if we want everything to be nice and secure. I'm perfectly aware that the effort required to implement such an API would be considerable and it might not be worth it but that doesn't make it the right approach. And that's why I accept the current situation - it's a compromise between what could be and what Apple have decided to implement at present.

> Others would require massive work.

Yes and in an ideal world, if we're fully committed to sandboxing, that work would be done. You said:

> 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 is not just about trust, it's also about security. Apple's own software not being sandboxed means its vulnerable to exploits, exactly what sandboxing is trying to prevent. If you check Activity Monitor, you will see plenty of Apple and others' apps being non-sandboxed - all of these are potential targets. A system is only as secure as it's weakest link, so if we want a more secure system, we should working towards having more sandbox entitlements.

As a side note, the trust side of things is taken care of by code signing.

> And implied that this means Apple should allow third-party apps to continue violating rules because the existing experience of using that 3rd-party application somehow trumps everything else.

No, the implication is that Apple should be working towards exposing more functionality in a secure, sandbox compatible way.

[1] http://www.panic.com/blog/coda-2-5-and-the-mac-app-store/

[2] http://www.openradar.me/search?query=sandbox

Wait, slow down. As far as I can tell from a quick Google, GaragePay was only using encrypted disk images as a way to store its private app data in encrypted form. But obviously there are many other ways to implement encrypted storage, within the app process rather than calling out to the OS. This would avoid the need for any holes in the sandbox; it would require some work to implement, but temporary sandbox exceptions were known to be temporary for years.

Even if the developer wanted to be able to access disk images from older versions of the program, they'd be dealing with an undocumented file format, but AFAIK there is a lot of code out there for dealing with dmgs, so it should be possible.

"I expect they're taking the right steps privately, talking to the Review Board and whatnot"

If I read this sentence in isolation, this could pass as a sentence from a wonderfully subtle Russian novel from the previous century.

> The MAS is relatively new and is not replacing any existing software delivery mechanism

Really now? I feel like I need to preface this by saying I love all my Macs, my iPhones (all 5 that I've owned), iPads, etc. I also love the convenience and simplicity of using the MAS compared to any other way of getting free and paid software.

But even I think there is a nearly 100% chance that by, say, 3-5 years from now, Apple will prevent installing software from sources other than MAS. You can tell by the trajectory of MAS. It started out as just an equally-supported option. Now installing software not from the MAS is a warning, and installing software from a developer entirely unblessed by Apple entirely is disabled without already knowing the "right click workaround" (try successfully explaining to a casual user how to install that kind of app). It's only logical to extrapolate that to the next steps. maybe in 2015 all non-MAS will require the right-click open. In 2016 or 2017 non-MAS will probably mean not runnable without obtaining a limited-use developer or enterprise certificate from Apple for a fee. Given that iOS doesn't have any supported way to sideload arbitrary third-party apps the way, we should expect this to be the case for the Mac as well. You will be able to run apps you've signed with your own developer or enterprise distribution certificate, but I doubt you'll be able to download & just run an app from Panic or anyone else without jumping through hoops or "jailbreaking."

> Now installing software not from the MAS is a warning

No it's not. Where did you get that idea? The only issue is installing software that isn't codesigned with an Apple-signed certificate. Any developer enrolled in Apple's Mac Developer program can get an Apple-signed certificate and self-sign their 3rd-party non-MAS software and users will have the same experience as using MAS software. The only dialog they'll get is the standard "Are you sure you want to run this program you just downloaded?" dialog that we've had for a while now. Which, admittedly, I don't think MAS apps have, but that's because MAS apps aren't downloaded with a web browser; if you install a 3rd-party app via some mechanism other than downloading with a web browser it should similarly bypass that dialog.

> installing software from a developer entirely unblessed by Apple entirely is disabled without already knowing the "right click workaround" (try successfully explaining to a casual user how to install that kind of app)

Well, the simple answer is to change the Gatekeeper setting, but the more relevant question is why are you even providing support for such an app? Any app that isn't properly code-signed is likely to not have had an update in several years. The only excuse beyond old unsupported apps for not properly being code-signed is the rare open-source cross-platform app that provides an OS X download without codesigning, which is not something most casual users are generally expected to be using anyway.

All of this is beside the point anyway. Gatekeper and the Mac App Store are two completely separate technologies. And whether or not your application is distributed on the MAS is not relevant to Gatekeeper, except in that you cannot distribute on the MAS if your app is not properly codesigned.

> It's only logical to extrapolate that to the next steps. maybe in 2015 all non-MAS will require the right-click open. In 2016 or 2017 non-MAS will probably mean not runnable without obtaining a limited-use developer or enterprise certificate from Apple for a fee.

That's pure 100% FUD. It is not at all logical to assume that Apple will pull such an insanely stupid move. iOS being locked down does not at all say that OS X will be locked down in the same fashion; it would be virtually impossible to lock down OS X like that, and any attempt to do so would be so incredibly user-hostile that it's laughable to think Apple would do that, and would probably destroy OS X.

I have to wonder if you have some vested interest in sowing distrust in Apple and OS X. Why else would you make such an absurd claim with a straight face?

> 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?

>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.

Personally, I think all of them are bogus decisions. Apple might be well within their rights to make bogus decisions but that does not automatically make them not bogus.

Note taking app should not have custom keyboard. Bogus. Apps are not allowed to have UX gesture similar to Apple because they become confusingly similar to Apple product. Bogus. It was a stopwatch for crying out load.

No matter how you try to spin it, these decisions is just Apple screwing over their app developers.

> Note taking app should not have custom keyboard. Bogus.

That wasn't the rejection.

> Apps are not allowed to have UX gesture similar to Apple because they become confusingly similar to Apple product. Bogus.

That wasn't the rejection either. It wasn't rejecting the concept of a horizontal swipe causing an action. In fact, Apple intentionally makes it extremely easy for horizontal swipes to cause actions.

> No matter how you try to spin it, these decisions is just Apple screwing over their app developers.

Yes, Apple is well known for hating their developers and intentionally trying to screw them over, and every 3rd-party developer that gets rejected is an innocent victim. Makes perfect sense.

Edit: If you didn't get it, that last paragraph was sarcasm.

Uh, fine. Sure, some of the rejections may be appropriate. But the situation with Drafts and PCalc are still very valid examples of problems with Apple's policies.

I updated my post with a note at the bottom already. And two examples, one of which is actually not clear-cut at all (I don't agree that the Drafts case is actually necessarily an invalid rejection) and the other of which got reversed almost immediately, doesn't necessarily mean a whole lot. Do you know how many apps get reviewed every single day? And how many of those get validly rejected, for reasons that nobody here would possibly disagree with? I think the answer is probably higher than you expect.

I would love it if cases like PCalc never even happened. But I'm willing to accept that sometimes bad decisions happen, and we have to do our best to see that it gets fixed.

Edit: To clarify on Drafts, I definitely think that they need to be consistent with their policies, though that can be very hard when you have lots of different reviewers reviewing apps, as they may interpret policies differently, or simply be more or less diligent about enforcing them. But Apple has always said that the notification center is intended for information display, and it follows that having a bunch of apps use widgets that provide buttons to launch the app is in violation of the intention of the notification center. Apple should be consistent here, but I would not fault them for choosing to tell all apps (such as Evernote) that they need to remove similar buttons, rather than allowing Drafts to keep its button.

The fact that any rejection is 'valid' or that there is a process for rejections to begin with, is absurd. iOS is NOT developer friendly.

I wish iOS didn't have the market share it has, it is so depressing: you either are under Apple's boot or have to abstain from a large segment of the Mobile Market.