←back to thread

830 points todsacerdoti | 5 comments | | HN request time: 0.688s | 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. 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 #
2. 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 #
3. saagarjha ◴[] No.25135853[source]
I worked on the iSH appeal, and have of course watched this space for years, so I've gotten very familiar with the "spirit of the law" to the point that the conversation with Apple ended up really being a confirmation that our interpretation of the law was correct and that iSH was fine under the rules that Apple enforces. Your characterization isn't quite right. Apple doesn't want to not have apps that allow users to execute code, in fact they themselves write apps that let the user execute code they write and demo them at WWDC (Swift Playgrounds? Shortcuts?). Some of the best apps on the App Store let you write code and run it. Saying iSH is in violation of those rules would require pulling down those apps too.

What Apple is really trying to do is prevent apps from changing their behavior after they review them in a silent way to bypass the usual process. The real issue here is that their guidelines don't reflect this and this confuses the reviewers (and evidently commenters here on Hacker News). What needs to happen here is Apple clarifies their guidelines so that we don't have rules that can be inconsistently enforced.

(If you need more to convince you, I'll point you at the stuff I wrote when that was going on: https://saagarjha.com/blog/2020/11/08/fixing-section-2-5-2/).

replies(1): >>25138067 #
4. 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.
5. spijdar ◴[] No.25138067[source]
Hmm, that's fair. I don't use iOS much myself, so I'm not very familiar with what's available on the App Store. It does appear that at least Swift Playgrounds allows for projects (including code, which is interpreted) to be downloaded off the Internet, extending the runtime beyond what is available "at time of review".

That said, briefly looking over some scripting/IDE environments not from Apple, it looks like most of them ship "batteries included" and don't allow for content to be pulled from online.

It seems to me the equivalent of iSH shouldn't be, say, a Python interpreter/IDE, but a Python runtime including pip and the ability to pull modules from pypi.org.

OTOH, Python itself is so reflective, I imagine there's probably some way to self-inject modules within a script, if you have any sort of web access. And since you can tunnel TCP over DNS, even a hostname lookup is enough. So I'll conceded the point, since most scripting runtimes probably have some kind of EVAL routine to invoke the interpreter, or a porthole into the interpreter's bytecode.

That said, my own original point was about developers/businesses feeling uncertainty about Apple's rules, and worrying if an app would even be accepted. I feel like almost any developer would instinctively thing iSH's premise of being a program interpreter for the Linux ABI would be rejected by Apple.

Whether or not the underlying rule is fairly applied aside, it's clearly something Apple wants to prohibit. Albeit, I'm kind of baffled myself at why, especially in iSH's case where the emulated runtime is completely separate from the "real program text", with no escape hatches out IIRC. Seems utterly ridiculous to me, especially when you can accomplish something similar in WebKit/JSC I'm sure, just not offline. :-/