10 ms·

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.

jamil7 6y ago
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.
- spijdar 6y ago
  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.
  - jamil7 6y ago
    OK fair enough perhaps it wasn't the most cut and dry example. But it was the most recent I could think of.
    - saagarjha 6y ago
      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.
  - saagarjha 6y ago
    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/ https://saagarjha.com/blog/2020/11/08/fixing-section-2-5-2/).
    - spijdar 6y ago
      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. :-/
- Closi 6y ago
  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.
  - saagarjha 6y ago
    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.
nguyenkien 6y ago
Apple can change it rules. eg: https://www.theverge.com/2019/4/27/18519888/apple-screen-time-app-tracking-parental-controls-report https://www.theverge.com/2019/4/27/18519888/apple-screen-tim...
gtsteve 6y ago
Unless you're competing with something Apple is planning to bring out (parental control apps before screen time stats, etc). I don't think I'm competing with Apple at all today, but who knows what they're planning for their next features?
- varispeed 6y ago
  Exactly, nothing stops them to pull "Amazon", that is once they see your app is successful, they could request all data they need and either buy it off the company that developed it for you or commission their own app based on the documentation you had to provide and then block you. There is currently nothing you could do about it.
- the_other 6y ago
  Surely this is true for all developers, at any size? And also just about any product, or service, in any industry? As counterexamples: Apple sell Logic, yet it has numerous competitors, also all fairly successful: ProTools, Live, Cubase, Reaper, Ardour, FruityLoops. Apple give their customers Notes, Reminders and Mail for free, on all their devices (i.e. you don't even need to get hold of apps for these functions), and yet we also have Evernote, Notion, Airmail, Spark etc etc. Does the App Store monopoly significantly change the nature of app competition? I'm not convinced, but I'm open to learning about it.
  - afandian 6y ago
    Surely the fundamental difference here is whether "the market" decides, giving you a fighting chance, or whether the Deity decides, with no recourse but supplication?
  - dannyw 6y ago
    When Apple added Screen Time, they banned other competing apps.
    - the_other 6y ago
      I see how that does affect the competition. Fair point.
richardARPANET 6y ago
Except it is https://en.wikipedia.org/wiki/Censorship_by_Apple#App_Store https://en.wikipedia.org/wiki/Censorship_by_Apple#App_Store
adanto6840 6y ago
I recently was in contact with someone who has written a menu-bar app to monitor Tesla Powerwall status. It's in the Mac App Store already -- but NOT the latest version, because Apple suddenly decided that they wanted written proof that accessing the Powerwall APIs was allowed (from whom?! It's MY hardware!). Apple will not allow the dev to update his Mac App in the MAS; yet they approved & continue to leave the original older version [with known bugs] up, available for purchase. So now the developer is stuck -- he can't update his app on the Mac App Store, and what recourse does he have as a 1-man-shop vs Apple?! =| As a developer I find it absurd, as a consumer [who bought the app on MAS and wondered why I had the non-latest version], I find it absolutely baffling & anti-consumer.
- sunshinerag 6y ago
  he cannot withdraw the older version of the software from the app store? that is weird.
  - deleted 6y ago
    [deleted]
gnicholas 6y ago
Absolutely untrue. Many well-meaning devs who paint entirely within the lines end up in review purgatory due to capricious interpretations of Apple's broad/vague rules.

jamil7 6y ago

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.

spijdar 6y ago
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.
- jamil7 6y ago
  OK fair enough perhaps it wasn't the most cut and dry example. But it was the most recent I could think of.
  - saagarjha 6y ago
    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.
- saagarjha 6y ago
  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/ https://saagarjha.com/blog/2020/11/08/fixing-section-2-5-2/).
  - spijdar 6y ago
    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. :-/
Closi 6y ago
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.
- saagarjha 6y ago
  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.

nguyenkien 6y ago

Apple can change it rules. eg: https://www.theverge.com/2019/4/27/18519888/apple-screen-time-app-tracking-parental-controls-report https://www.theverge.com/2019/4/27/18519888/apple-screen-tim...

gtsteve 6y ago

Unless you're competing with something Apple is planning to bring out (parental control apps before screen time stats, etc). I don't think I'm competing with Apple at all today, but who knows what they're planning for their next features?

varispeed 6y ago
Exactly, nothing stops them to pull "Amazon", that is once they see your app is successful, they could request all data they need and either buy it off the company that developed it for you or commission their own app based on the documentation you had to provide and then block you. There is currently nothing you could do about it.
the_other 6y ago
Surely this is true for all developers, at any size? And also just about any product, or service, in any industry? As counterexamples: Apple sell Logic, yet it has numerous competitors, also all fairly successful: ProTools, Live, Cubase, Reaper, Ardour, FruityLoops. Apple give their customers Notes, Reminders and Mail for free, on all their devices (i.e. you don't even need to get hold of apps for these functions), and yet we also have Evernote, Notion, Airmail, Spark etc etc. Does the App Store monopoly significantly change the nature of app competition? I'm not convinced, but I'm open to learning about it.
- afandian 6y ago
  Surely the fundamental difference here is whether "the market" decides, giving you a fighting chance, or whether the Deity decides, with no recourse but supplication?
- dannyw 6y ago
  When Apple added Screen Time, they banned other competing apps.
  - the_other 6y ago
    I see how that does affect the competition. Fair point.

richardARPANET 6y ago

Except it is https://en.wikipedia.org/wiki/Censorship_by_Apple#App_Store https://en.wikipedia.org/wiki/Censorship_by_Apple#App_Store

adanto6840 6y ago

I recently was in contact with someone who has written a menu-bar app to monitor Tesla Powerwall status. It's in the Mac App Store already -- but NOT the latest version, because Apple suddenly decided that they wanted written proof that accessing the Powerwall APIs was allowed (from whom?! It's MY hardware!). Apple will not allow the dev to update his Mac App in the MAS; yet they approved & continue to leave the original older version [with known bugs] up, available for purchase. So now the developer is stuck -- he can't update his app on the Mac App Store, and what recourse does he have as a 1-man-shop vs Apple?! =| As a developer I find it absurd, as a consumer [who bought the app on MAS and wondered why I had the non-latest version], I find it absolutely baffling & anti-consumer.

sunshinerag 6y ago
he cannot withdraw the older version of the software from the app store? that is weird.
- deleted 6y ago
  [deleted]

gnicholas 6y ago

Absolutely untrue. Many well-meaning devs who paint entirely within the lines end up in review purgatory due to capricious interpretations of Apple's broad/vague rules.