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.
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.
I don't think I'm competing with Apple at all today, but who knows what they're planning for their next features?
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.
It wasn't a simple matter of "Apple releases product that does X, then bans all products that do X from the App Store;" the products they banned had to use some seriously sketchy tactics to monitor and restrict other apps on the iPhone without system-level access.
Apple clearly thought they were valuable enough to customers to keep around before the release of Screen Time, even with the sketchy method they had to use.
iOS has always been designed as not to offer APIs that can be used for particularly harmful purposes.
I'm still not a fan of Apple sherlocking popular apps and then proceeding to ban those apps that carved out the market for them... that's a very anticompetitive move.
No, this is very unique to Apple, and only on iOS. Its the reason why iPhone web browsers have to use Safari under the hood.
All the browser-makers successfully compete on features, as proved by the continued existence of multiple browsers on the App Store. Hell, Firefox can even afford to cannibalise its own market with two versions of Firefox (FF, and FF Focus).
Furthermore all the big name browser makers sell their offering at "free". In my view, this makes browsers an outlier in any discussion of Apple's anti-competitive behaviour. It doesn't shut down the conversation, just takes browsers out of it.
Edit: as others have pointed out iSH isn't the best example of this.
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.
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/).
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. :-/
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.
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.