←back to thread

830 points todsacerdoti | 2 comments | | HN request time: 0.534s | 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 #
1. Closi ◴[] No.25135620[source]
iSH is definitely in the “pushing the boundaries of the rules” area of apps (x86 emulation) and probably shouldn’t have been allowed if you took a strict interpretation of the rules.

OP is just saying 99% of apps being developed are clearly within the rules, rather than really pushing against the boundaries of what is allowed.

replies(1): >>25135894 #
2. saagarjha ◴[] No.25135894[source]
Well, that is the crux of the matter: the rules are not written correctly because they allow iSH to be inconsistently judged if you take "a strict interpretation"; there should not be a strict interpretation; it should just be "this app is reasonable" and "this app is not" and not "hey this looks like it's running code…does that make it a security risk?" which reviewers are not equipped to answer.

When we made the appeal for iSH we correctly surmised that the point of the rule that was cited was to prevent apps from bypassing App Store review, which iSH does not do in the slightest. Taken from the real perspective from which the app should have been judged, iSH is not at the boundary at all; instead it's the apps that do things like undisclosed A/B testing and feature flags to hide things from review. So what happens is developers like us who are actually clearly within the rules as they are meant to be applied get caught in limbo at the whim of reviewers who misunderstand the guidelines because they aren't written as they are supposed to be enforced.