Apple Announces App Store Small Business Program

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.

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.

Apple can change it rules. eg: https://www.theverge.com/2019/4/27/18519888/apple-screen-tim...

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.

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.

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?

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.

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

OK fair enough perhaps it wasn't the most cut and dry example. But it was the most recent I could think of.

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.

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/).

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?

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.

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.

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.

he cannot withdraw the older version of the software from the app store? that is weird.

When Apple added Screen Time, they banned other competing apps.

I see how that does affect the competition. Fair point.

Didn't those apps get around lack of OS integration by essentially installing an always-on VPN ... something that could be a huge privacy issue?

>Surely this is true for all developers, at any size? And also just about any product, or service, in any industry?

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.

If I recall correctly, the apps they banned were doing things like abusing the VPN function to capture all traffic from the phone, and using that as their mechanism for blocking certain websites (or maybe it was MDM they were abusing...?).

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.

And, instead of providing APIs to help make those apps less sketchy... Apple decided it would be easier to just ban them.

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.

Because those APIs can be used for extremely sketchy activity.

Many APIs can be used for sketchy things. Supposedly, that’s one thing the App Store review process is meant to catch.

But it’s not possible to replicate Screen Time without using VPNs.

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. :-/

You can't detect everything in review.

iOS has always been designed as not to offer APIs that can be used for particularly harmful purposes.

I agree completely.

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.

Years ago, Apple banned Camera+ for allowing to take a photo with the volume switch (instead of using an onscreen button). It was "too confusing" and against their Human Interface Guidelines. Then they added that exact feature to the default iOS camera app.

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.

That particular case sees Apple setting the rules of the market, not acting anti-competitively.

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.