It's clear that any change to the equilibrium would have winners and losers.

We can scope out who those are likely to be: free applications which provide some useful educational service would lose; currently they provide no revenue (beyond the token developer fee). Banking, rewards, credit, etc. applications (applications which interface consumers with their pre-existing accounts for CRUD-style management purposes) would lose. They provide no revenue. Subscription products with very low conversion rates would lose if their free:pay user ratio exceeds, say, 10:1 -- or some other breakeven point with respect to money saved by ditching Apple's payment stuff.

It would also hurt applications like Facebook, Twitter, and Instagram where the product is completely free and monetized by advertising Apple currently doesn't take a cut of.

It's clear the winners are mostly extremely popular multi-billion dollar applications where the app portion is a pretty thin layer and they charge all or most users to subscribe on an ongoing basis. Fortnite doesn't exactly have a subscription, but it relies on fairly frequent impulse purchases and monetization of free users.

I don't think it's straightforward to imagine the world would be better or worse if the basis for billing changed to something like cost basis.

My overwhelming reaction to this trial is that it seems like both sides have fairly good reasons to prefer things the way they prefer things, but it's not clear to me why a court should essentially vacate a particular business model or contract. When courts intervene to strike broad classes of contract provisions (for example, to allow or disallow mandatory arbitration provisions), typically it's because there's an obvious public interest. Here the interests seem private on both sides, and it doesn't seem obvious to me that end consumers will either be harmed or helped by what's being asked for. Which seems like the kind of territory courts traditionally run away from.

> It's clear that any change to the equilibrium would have winners and losers.

Thank god our object isn't to design rules that would pick the winners and losers we want, but to design rules that prevent Apple from using their platform leverage in an anti-competitive way. It's fine if Facebook, Twitter, and Instagram lose, and "extremely popular multi-billion dollar" applications win. Being extremely popular and successful while using few Apple resources should give you some degree of control over your own application.

> It's clear that any change to the equilibrium would have winners and losers.

What equilibrium?

Equilibrium implies multiple forces balancing each other out. This doesn't seem to be the case here, because Apple are effectively dictating terms.

A better term would be "status quo".

(Nash) equilibrium is a game theory term meaning the outcome that occurs when each player plays their optimal strategy; it's not a term that refers to any particular presence or absence of equity in light of that. You can think of it as similar to a "status quo" if you prefer.

I can understand that colloquially it could mean the latter, so I apologize for using a technical term.

I understand what an equilibrium is. The question is: who are the players who are in equilibrium? Apple dictates the terms of the iOS app store. It's clear that Apple has a set of moves it can choose from. What moves do other players have, really, even if they were suboptimal?

It doesn't seem there really are any, other than to leave the app store entirely, which most would consider pretty extreme to the point where it's really hypotehtical. That's why I questioned whether the language of equilibria is appropriate in the first place: it just doesn't seem to be a pretty misleading framing of the situation.

Players: Apple, developers, user; playing a finite iterated game of uncertain time horizon.

Game order: Apple chooses a policy burden \omega ~ [0, 1] which stands in for the restrictions they place on developers or the cut of purchases they take. Apple takes \omega \beta in profit and incurs no costs.

Let's take you at your word that a developer's only choice is to leave or stay -- Developers choose whether to develop exclusively on Apple [reward (1 - \omega) \beta], on all platforms (1 - \omega) \beta + \theta, or not on Apple [reward \theta]. \beta and \theta are both constrained to be non-negative. Developers pay a cost of development -c where c is constrained to be non-negative. Developers all decide simultaneously.

You could model this as one developer choosing a fraction of effort. You could make costs variable. You could make developers decide sequentially. You could model Google, who is not an actor in this scenario. etc. etc.

Users observe the fraction of developers who opted in ||d||. Each user has a type [0, 1] which determines the threshold amount of developer support it will require for them to choose Apple over another platform. \beta and \theta both update to be higher or lower depending on user choices according to some update function you prefer.

Let each player have either an individual or shared discount parameter \delta.

This is clearly a well-specified game. I am not going to solve it for the equilibriums; it may well be the case for any practice \beta, \theta, c, etc. that Apple's incentive is to choose a very high \omega and developers best response is to choose "develop for Apple anyway". That would still be an equilibrium. Most games have degenerate equilibria.

It seems to me that if you adjust developers to be sequential rather than simultaneous this is very nearly the Chain Store Game; if you make it a single developer this probably gets close to something like divide the dollar; if you want to model the lawsuit, it's a costly signalling game (Epic burning cash to establish type)

All of this is very traditional game theory. I get that your point is that Apple is mean and the government should do something about it, but there's nothing wrong with me describing the current arrangement of winners and losers as an equilibrium, or to describe the shock a lawsuit could induce via policy change as something that will establish a new equilibrium by exogenously changing or constraining parameters. I left all this out because I didn't think anyone would require this effort to accept the use of a very uncontroversial term.

S3 is actually quite pricey. Not as much on the monthly storage (tho it can be depending on size), but network egress is really where they get you. On the scale of the App Store where the app might be 100mb but it gets downloaded potentially millions of times it gets expensive fast.

Now imagine your app is free. Yet you have to pay for all these downloads. There wouldn’t be any free apps anymore.

At $0.05 per gb transfer, it would be half a penny per 100mb app download. Someone has to pay for that - at the moment Apple subsidises the free apps, presumably because they think they are good for the ecosystem.

Although lets be honest here, free apps could easily continue to be subsidised by Apple in any future model. We are talking about far less than a dollar per iPhone in terms of hosting/bandwidth costs for all the apps, so this really is something that Apple could easily just swallow.

Let's not forget that the availability, quality and abundance of apps, made by developers, is a key driver of success of the iPhone, and Apple makes plenty money from hardware sales. I won't lose sleep over the thought that they might have to pay for some hosting.

> $0.05 per gb transfer

That's including AWS's insane profit margin, though. I have my cloud deployments with Hetzner, where extra traffic costs € 1.19 per TiB, so that 100 MiB app download would not be half cent, it would be 1/100th of a cent. (And that's before we consider that Hetzner gives 20 TiB per month free traffic with every VM.)

Very true!

> Their point is that Apple could charge based on bandwidth used, and that this could be more fair for some developers.

That is what the 30% cut is meant to cover (amongst other things too). Like with a high street retail store, the mark up is intended to cover the running costs of the store. Which brings us full circle to why Apple deduct it from transactions.

Sure you "could" have an App Store that calculates the operational costs and then charges it to the developer, but you then potentially destroy the free app market (and contrary to what people often say about the App Store, there are a lot of decent free apps on there).

Having a split payment and billing system also adds complexity to invoicing. Did you know that AWS and other cloud providers don't provide credits and refunds as payments into the customers bank accounts? No, what they do is they offset your costs against your credits and invoice the difference if owed to AWS. If Apple were to adopt that then we'd basically be back at deducting $n from transactions again. And once again we've come full circle.

There is so many arguments about what Apple "could" do but when you start to distil the requirements down to a workable operation you almost always end up right back at the status quo.

Now I'm not saying that Apple aren't taking advantage of developers either. The cost of development on a Apples ecosystem is ridiculously high and Apple are notoriously hostile towards their developers too. But charging a percentage of transactions is a reasonable approach to the problems outlined above and limiting transactions outside of Apple's payment channel does at least solve the problem of developers cheating by funnelling funds in via a side channel (as exampled in an earlier comment which discussed people selling items on eBay for $1 but with a $49 shipping fee before eBay clamped down on exaggerated shipping fees).