[mikeocool]

> Apple knows their rules are so unpopular

Are they? I know developers don’t like the rules, but I don’t know a lot of iPhone owners who feel particularly stifled by them. If they did, presumably they’d just buy an Android phone?

[staplers]

  I don’t know a lot of iPhone owners who feel particularly stifled by them

Thank you for your deeply anecdotal brush off. Surely it makes those millions nearly imprisoned (try living without a phone) in the modern world by the corporate duopoly feel at ease. Just switch to the other side and solve all the problems.

[ipaddr]

The other side gives you the possibility of getting a phone with different variations and people also root their phone and sideload apps. I support going the PinePhone route but not sure that's right for the average person.

[2muchcoffeeman]

At first the Apps store rules provided an advantage to the Apple ecosystem though. And there are still some advantages that keep people in the ecosystem for now. But Apple needs to evolve their offering.

The more you tighten your grip, Tarkin, the more star systems will slip through your fingers.

[walterbell]

> I don’t know a lot of iPhone owners who feel particularly stifled

The existence of iOS Unix shell emulators (iSH, aShell) suggests otherwise, at least on iPads.

Perhaps that will change with forthcoming iPad Pro + macOS-subset VMs.

[kbf]

Apple fearing or assuming their rules are unpopular would be even worse. My point is I don’t see why this limitation exists beyond Apple desperately trying to keep non EU users from using EU app stores.

[fingerlocks]

> I know developers don’t like the rules

Who exactly are these developers? Because I'm a developer and I find the idea of supporting multiple app stores absolutely dreadful.

Consider the impact. If we're lucky there will be only one necessary re-implementation something major. At minimum we can expect to rewrite all code paths involving IAP. This will require a thick layer of abstraction caked on top to maintain feature parity between the separate builds, further slowing down compile times and making debugging more cumbersome. Yes, there will be separate builds because we rely on Apple to manage our DWARF symbols. That will need a homegrown solution, all new tooling, which of course will be crappy and half baked for many years. Best keep the builds separate.

Separate builds will likely mean new build/deploy pipelines to manage, possibly each having their own separate staging environments, which eats away at productive development time. Of course this will be all tied together with additional layers of abstraction. All tooling involving the AppStore API will be re-created.

Oh and I pity the poor souls that use react-native and it's convoluted, fragile, build environment. It's going to really suck for them. Cross your fingers and hope for the best when you npm install react-native-alternative-store and it's 500 dependencies written by CoPilot in Objective-C by one unresponsive developer on a GitHub page whose only activity is an increasing number of unresolved issues.

And that's not all! We use AppStore analytics, financial data management, beta test tooling, and internal device management. What will be fate of these services without the App Store? More crappy work and less time spent actually making the product better.

So no, this developer is just fine paying 15 to 30%. It's really a bargain for smaller dev shops.

[ffsm8]

I was with you up until your last statement.

The only reason why it's probably not going to be worth supporting the other stores is that the userbase is going to be too small, which makes the potential extra revenue you can get in the other store likely too low to justify the support

But 30% is never going to be a bargain, even if you're a solo developer. It's 30% of the company revenue if they're only on the app store. That's likely more then your wage in it's entirely.