←back to thread

830 points todsacerdoti | 1 comments | | HN request time: 0.206s | source
Show context
gtsteve ◴[] No.25135526[source]
Looks nice but it doesn't solve my fundamental problem:

1. I invest loads of time and effort developing an app

2. Apple rejects it

-or-

2. Apple approves it

3. I ship a new update

4. Apple rejects the update and now decides my app should have been rejected retroactively.

I'm especially concerned about what happened to Hey and others but my customers are demanding smartphone apps and there are still limits to what can be done with a mobile web browser.

replies(11): >>25135538 #>>25135628 #>>25135644 #>>25135672 #>>25135968 #>>25135975 #>>25136030 #>>25136106 #>>25136507 #>>25137973 #>>25139367 #
user-the-name ◴[] No.25135538[source]
This really isn't a problem in practice, unless you are going out of your way to try to bend the rules set in place, especially about sales.
replies(6): >>25135567 #>>25135586 #>>25135624 #>>25135693 #>>25135898 #>>25141783 #
jamil7 ◴[] No.25135567[source]
It can be a problem in practise since the rules aren't fairly or consistently enforced. Look to recent issues with iSH being approved and rejected.

Edit: as others have pointed out iSH isn't the best example of this.

replies(2): >>25135616 #>>25135620 #
spijdar ◴[] No.25135616[source]
While I agree the rules are often inconsistently enforced, and I'm a fan of iSH, I think the real surprise is it was ever approved in the first place, as it seems to clearly be violating the "spirit of the law" regarding Apple being pretty clear they don't want apps that allow arbitrary binary execution.

iSH tried to circumvent this with a technicality, and it seems to have initially "worked", but I think it's a poor example of an app unfairly/inconsistently targeted.

replies(2): >>25135727 #>>25135853 #
jamil7 ◴[] No.25135727[source]
OK fair enough perhaps it wasn't the most cut and dry example. But it was the most recent I could think of.
replies(1): >>25135918 #
1. saagarjha ◴[] No.25135918[source]
I think the fact that the guidelines are written as such to make people think it wasn't a cut and dry example is really what makes it better example than you might have even though it was at the beginning. The rule Apple would like to enforce is very clear, and we know what it was and the review team didn't, because the guidelines didn't reflect the rule that Apple wanted to enforce (and thus ended up enforcing it inconsistently). A situation where developers have to tell the review team how the guidelines work because they're not written down explicitly is a very untenable position and one that needs to change.