4 ms·

Apple's process is correct here, in my opinion. They (rightfully) require that an app declare why it needs access to resources/data, and they verify (rightfully

Apple's process is correct here, in my opinion. They (rightfully) require that an app declare why it needs access to resources/data, and they verify (rightfully) that it is meaningful and does not use circular logic ("The camera will be used to take photographs"). Remember, this is not only for users, it is also for reviewers - to keep out apps that unnecessarily access things (that many users don't have the energy to think about, and will just tap "allow" in the permissions spam they will come to expect from every app if this policy was not enforced). Given the enormous volume of app submissions and the large number of points each app must be reviewed on, it might be unrealistic to require that reviewers always use the full context of the app when reviewing each individual component - the person reviewing the message might not even know what the app is! And they shouldn't have to! The message should be self-explanatory. The app needs access to the camera because it is a photography app, not because it takes photos. I applaud Apple's thoroughness on this topic. It's much better than the opposite problem, which is what plagues virtually 100% of other software platforms historically, and I'm disheartened for software as a whole that some people (especially HN users, who should be more thoughtful) can't see beyond the petty "it must be mindless Apple defenders" catch-all, or the "rejection reasons are sometimes non-specific" problem, (the latter of which I am assuming on good faith is a real problem, though I've never personally encountered it).

tempfile 2y ago
> the person reviewing the message might not even know what the app is! Sorry, you have gone too far here. If the reviewer doesn't know what the app is, they aren't reviewing the app at all. Knowing that a photography app takes photographs is the absolute bare minimum of context that is required to even begin to meaningfully review it.
- happytoexplain 2y ago
  You're right, they're not reviewing the app, they're reviewing the rationale for access! Separation was the point of my suggestion. It is probably not even true in the first place - it was only a conjecture. But if they did do that, it would have ups and downs. I could see a rationale that intentionally separating certain review duties from the context of the app could actually help to enforce objectivity. I tend to agree that it would probably be more bad than good, though.
  - quesera 2y ago
    I'm totally on board with the idea that permission requests should include complete context, separated from any product description written in the App Store. For example, there's the case where you download an app today, and don't get around to trying it for hours or days or longer. Curt "duh-style" permissions requests are user-hostile. Apple insists that developers "try harder". In almost all cases, this is the right choice for the user. Sometimes it's hilariously wrong, of course! There are humans in the review loop, and I've been on the wrong side of some epic ridiculousness. But on the whole, they're usually more frequently right than wrong. I'll take it.
saagarjha 2y ago
[flagged]
- happytoexplain 2y ago
  After two decades, this is the only place left I engage with on the internet. Please, please don't do this.
  - saagarjha 2y ago
    Look, I am no happytoexplain but I think your position comes from deep ignorance of how the App Review process works and how it is advertised. You've written a lot of words about how you think someone just gets given the prompt in a vacuum and is supposed to judge that, and then explain why that is actually a good thing. Let me tell you, that is absolutely now how Apple describes the review process. I gave you a short answer because quite frankly this is an easy thing to look up yourself, and I feel like you should have done so before posting your rationale.
wibbily 2y ago
Maybe if they were consistent... they had an update rejected, which implies that they've passed review before. Doesn't sound "thorough" to me. Plus, reviewers must be able to see the App Store page, right? Halide's has "camera app" and "photography" in the first paragraph of the description. (It literally has "camera" in the title. The icon is an aperture.) I mean hell that's the root of the problem. It doesn't matter what context you provide or how obvious you make things, you're feeding your app to a black box that gives results seemingly at random. I haven't met a developer that hasn't failed review for arbitrary reasons, including me. Either give me clear guidelines and procedures to follow - and then follow them - or don't lock me out of doing my job.
- happytoexplain 2y ago
  First, to preface: Believe it or not, I am far from an Apple fanboy. I have never owned an iPhone, Apple Watch, Mac, or MacBook for personal use. I have owned one iPad, which I bought a few years ago. I also like the AirPods. I like (and dislike) a lot of things about Apple's DX, and I dislike (and like) a lot of things about their UX. That said, I agree, lack of consistency is frustrating. But there is a big caveat to that opinion. When I experience inconsistent rejection, it has always been due to things that are reasonable to not catch as a reviewer 100% of the time. But personally, I would rather they catch 75% of instances of a problem than give up and let them all through because the inconsistency is frustrating. Of course, I would really like them to get that number to 100%, but I acknowledge that a lot of this stuff is not easily captured at a 100% rate using a tester script, or automatic processing. The key here is of course that you agree with or understand the rule they are enforcing. This is probably where most of the disagreement actually lies, and not so much in the inconsistency. I happen to be the kind of "purist" who would rather things be stricter for developers. I want the UX to be as good as possible, and I want the APIs to continue to improve and to not burden/complicate the platform with a lot of backwards compatibility. This is the opposite of a lot of developers, and I totally understand the other side of that argument. This is not to say that Apple review is not shitty sometimes. I just happen to think that the one or two biggest things developers complain about seem to not be as clear-cut as developers describe.
YawningAngel 2y ago
I think for 30% of my revenue I'd expect reviewers to find the time to use the full context of the app. That may not be realistic for every app on the app store, but it is reasonable for apps with tens of thousands of reviews and hundreds of thousands (at least) in revenue.

tempfile 2y ago

> the person reviewing the message might not even know what the app is! Sorry, you have gone too far here. If the reviewer doesn't know what the app is, they aren't reviewing the app at all. Knowing that a photography app takes photographs is the absolute bare minimum of context that is required to even begin to meaningfully review it.

happytoexplain 2y ago
You're right, they're not reviewing the app, they're reviewing the rationale for access! Separation was the point of my suggestion. It is probably not even true in the first place - it was only a conjecture. But if they did do that, it would have ups and downs. I could see a rationale that intentionally separating certain review duties from the context of the app could actually help to enforce objectivity. I tend to agree that it would probably be more bad than good, though.
- quesera 2y ago
  I'm totally on board with the idea that permission requests should include complete context, separated from any product description written in the App Store. For example, there's the case where you download an app today, and don't get around to trying it for hours or days or longer. Curt "duh-style" permissions requests are user-hostile. Apple insists that developers "try harder". In almost all cases, this is the right choice for the user. Sometimes it's hilariously wrong, of course! There are humans in the review loop, and I've been on the wrong side of some epic ridiculousness. But on the whole, they're usually more frequently right than wrong. I'll take it.

saagarjha 2y ago

[flagged]

happytoexplain 2y ago
After two decades, this is the only place left I engage with on the internet. Please, please don't do this.
- saagarjha 2y ago
  Look, I am no happytoexplain but I think your position comes from deep ignorance of how the App Review process works and how it is advertised. You've written a lot of words about how you think someone just gets given the prompt in a vacuum and is supposed to judge that, and then explain why that is actually a good thing. Let me tell you, that is absolutely now how Apple describes the review process. I gave you a short answer because quite frankly this is an easy thing to look up yourself, and I feel like you should have done so before posting your rationale.

wibbily 2y ago

Maybe if they were consistent... they had an update rejected, which implies that they've passed review before. Doesn't sound "thorough" to me. Plus, reviewers must be able to see the App Store page, right? Halide's has "camera app" and "photography" in the first paragraph of the description. (It literally has "camera" in the title. The icon is an aperture.) I mean hell that's the root of the problem. It doesn't matter what context you provide or how obvious you make things, you're feeding your app to a black box that gives results seemingly at random. I haven't met a developer that hasn't failed review for arbitrary reasons, including me. Either give me clear guidelines and procedures to follow - and then follow them - or don't lock me out of doing my job.

happytoexplain 2y ago
First, to preface: Believe it or not, I am far from an Apple fanboy. I have never owned an iPhone, Apple Watch, Mac, or MacBook for personal use. I have owned one iPad, which I bought a few years ago. I also like the AirPods. I like (and dislike) a lot of things about Apple's DX, and I dislike (and like) a lot of things about their UX. That said, I agree, lack of consistency is frustrating. But there is a big caveat to that opinion. When I experience inconsistent rejection, it has always been due to things that are reasonable to not catch as a reviewer 100% of the time. But personally, I would rather they catch 75% of instances of a problem than give up and let them all through because the inconsistency is frustrating. Of course, I would really like them to get that number to 100%, but I acknowledge that a lot of this stuff is not easily captured at a 100% rate using a tester script, or automatic processing. The key here is of course that you agree with or understand the rule they are enforcing. This is probably where most of the disagreement actually lies, and not so much in the inconsistency. I happen to be the kind of "purist" who would rather things be stricter for developers. I want the UX to be as good as possible, and I want the APIs to continue to improve and to not burden/complicate the platform with a lot of backwards compatibility. This is the opposite of a lot of developers, and I totally understand the other side of that argument. This is not to say that Apple review is not shitty sometimes. I just happen to think that the one or two biggest things developers complain about seem to not be as clear-cut as developers describe.

YawningAngel 2y ago

I think for 30% of my revenue I'd expect reviewers to find the time to use the full context of the app. That may not be realistic for every app on the app store, but it is reasonable for apps with tens of thousands of reviews and hundreds of thousands (at least) in revenue.