Thursday, April 15, 2021

Discussion of Apple's alleged need to redesign iPhone to support third-party app stores continued--and expanded into why web apps don't help

This is a follow-up to yesterday's posts on Epic Games v. Apple, especially the third one (Apple expert incorrectly claims Apple would need to "redesign" iPhone hardware and software to allow alternative app stores ), which Apple Insider picked up.

That article drew additional attention to the discussion. A New Zealand-based developer, @hishnash, gave his explanation of what Apple's witness meant by a need to redesign even the iPhone's hardware. Epic Games founder and CEO Tim Sweeney then pointed to the fact that Apple's Enterprise program works on current iPhones:

We then discussed the technical aspects of installing and running apps on iPhones that are not installed via the App Store (but via the Enterprise Program, TestFlight, or Microsoft App Center). @hishnash noted that there are certain feature sets, such as CarPlay, that require special permission. My understanding of everything said up to that point was that it was "all just about Apple lifting lifting restrictions (some contractual, some technical) as opposed to really having to take its architecture to a higher level."

This here hinges on how one would reasonably understand the verb "to redesign" in connection with "software and hardware." There is another key term in this dispute--commission--that Apple clearly redefines in ways that no dictionary supports. In the case of to redesign, they also mislabel something, but one needs to consider the context:

"The duty upon Apple is more than the usual duty to deal; it would include a duty to redesign its hardware and software [...]" (emphases added)

The duty-to-deal case in U.S. antitrust law is Aspen Skiing, which must nowadays be understood in light of the warning in Trinko not to go too far, but Trinko didn't affect the part that is relevant in this redesign context. The Aspen outcome was that a larger ski resort had to (again) offer multi-area tickets together with its smaller competitor, which might otherwise have been forced out of the market.

So when Apple's expert says Epic wants more than the Aspen plaintiff and points to a "redesign" of hardware and software protected by intellectual property rights, the question is: is Epic really asking for (fundamentally) more? If yes, then "redesign" would mean Apple would have to make a huge architectural effort, and that wouldn't be fatal to Epic's case, but certainly involve a higher hurdle. Unlike Apple's witness, I don't see a structural difference. Here's why:

Epic's case, just like Aspen Skiing, is at the core about lifting restrictions, not about creating something new. The ski resorts didn't have to create a new skiing area. They just had to provide a ticket that gave customers access to both companies' existing areas. Apple doesn't have to invent something new: all those arguments about APIs, certificates, credentials etc. don't change the simple fact that Apple artificially put up barriers with a Gods may do what cattle may not attitude.

Apple's expert makes it sound like the Aspen Skiing defendant didn't have any obligation under antitrust law beyond signing a contract. But it definitely took more to implement the court-mandated cooperation. Even if you had a duty to sell someone potatoes, you'd have to do something to make it happen. Aspen Skiing was about issuing (in that case, printing) tickets, and about validating them (manually or electronically). Interestingly, the security architecture that ensures only authorized apps can access, for example, the CarPlay APIs is also about issuing "tickets" (in that case, digital certificates) and about validating them (@hishnash mentioned "root certificate chain validation" in connection with "the Entitlement system"). Also, even those ski resort tickets involved intellectual property (copyrights, trademarks)--plus real property.

It's a different jurisdiction, but when the European Commission obligated Microsoft to give developers of competing network servers (like the Samba open source project) fair access, Microsoft not only argued that it shouldn't have to grant a license but additionally complained about having to provide technical documentation. Then-competition commissioner Neelie Kroes "[found] it difficult to imagine that a company like Microsoft does not understand the principles of how to document protocols in order to achieve interoperability" and fined Microsoft for its (temporary) refusal.

Unlike the question of whether a "commission" is a "rebate" (it's a clear Boolean "false"), this here is one of degree. I stand by my criticism of the verb "to redesign" in this context because lifting unreasonable restrictions just means to fix a problem, not to take some technology to a higher level as "redesign" implies.

In particular, I'm unaware of Epic Games demanding access to Car Play at this stage. The types of apps one finds on the Epic Games Store don't need APIs that are subject to specific restrictions. In light of that, I summarized my understanding as follows:

Of course, even the second part (access to those other systems) could involve duties to deal. But it would be a first step to at least allow games like Fortnite to be installed via third-party app stores.

@hishnash acknowledged that "apps that could be replaced with PWAs (aka apps that do not use any key system apis could be installed through a third party apps store." (PWAs = HTML5-based Progressive Web Apps). In other words, the Epic Games Store could install Fortnite because--performance and other issues apart--Fortnite doesn't need to access APIs like CarPlay and could therefore be a web app (it wouldn't be playable, but again, no API access issue). Thereafter, the discussion was more about whether third-party app stores would be an effective remedy as developers would still need to use some of Apple's SDKs etc., and whether PWAs would be a workable or potentially even superior alternative.

Epic's proposed findings of fact and conclusions of law list a number of shortcomings that PWAs have. Mr. Sweeney described Apple's pointing to PWAs as "disingenuous" because Apple limits those APIs and doesn't allow third parties to fix the issues though they technically could. In addition, what I know from one of my own projects is that major ad networks don't even support in-app advertising in WebGL apps. So there are usability issues including but not limited to performance, and monetization issues. Mr. Sweeney noted that Apple itself tells developers to build native apps:

And in my favorite @TimSweeneyEpic tweet to date, he explained iOS is "an intermediation trap":

@hishnash thought Epic wanted exposure on the App Store and would therefore not even accept a workable PWA solution. He inferred this from Epic's decision to offer Fortnite via the Google Play Store despite sideloading being possible. Let's focus on Apple here, so I'll just note that sideloading on Android doesn't really work for consumer software in its current form: my own company even experienced problems because beta testers didn't manage to install our stuff via Microsoft App Center. As for Apple, I pointed @hishnash (whom I commend for his thoughtfulness and constructive attitude) to the fact that Epic Games v. Apple is not just a Fortnite case but the central issue is third-party app stores like the Epic Games Store (even though the early stage of the dispute was very much about #FreeFortnite).

The remainder of the remedies discussion basically was about weighing the pros and cons of two remedies--PWAs and third-party app stores. @hishnash thought that if Apple--in what I consider an alternative universe--sincerely made an effort to provide a great user experience for PWAs, developers would then at least be independent, while apps distributed via alternative app stores would still depend on some kind of IP license from Apple:

In other words, we were then talking about two different dependencies:

  • With PWAs, @hishnash assumed there was no licensing issue (and for simplicity's sake, I don't want to digress into the related IP questions here), and if usability issues came up, the solution would be to hold Apple to a hypothetical commitment to comply with a certain technical standard.

  • For apps distributed via third-party app stores, @hishnash assumed there was a need to take a license from Apple (which I again won't discuss from an IP perspective, though I'd be tempted to talk about the recent Android-Java API Supreme Court decision), and the terms might be unreasonable (as he suggested in the above tweet).

It's not that @hishnash would necessarily oppose both better PWAs and competing stores. At least on videogame consoles (which are an important topic, but can't talk about them or this post will never come to an end), he might even like the idea of going down both avenues. And he clarified he didn't mean to say that PWAs "worked well right now."

To make a long story short, the reason I don't believe PWAs could lead to a practicable and reasonably enforceable remedy is because user experience happens in users' minds. What's pretty doable (not trivial, but manageable) is to ensure compliance with a standardized protocol like 5G. What's already a lot harder is to measure purely technical performance: there are different benchmark programs for CPUs, for example. But what's absolutely impossible--except perhaps with 26th-century artificial intelligence--is to objectively quantify the user experience, especially of entertainment products like games. So even if Apple theoretically promised to do a better job on PWAs, or just made an announcement to that effect without a formal legal obligation, developers wouldn't have a reliable--i.e., justiciable--assurance of being able to compete outside Apple's App Store.

By contrast, if Apple clearly had to allow the distribution of apps via third-party stores that use the same APIs as those distributed via the App Store, the remaining area of potential dispute would come down to license fees for SDKs, for developer tools, for documentation etc.--which can be worked out. The EU solved that problem in the Microsoft network server protocol case. I follow standard-essential patent royalty disputes all the time (this blog has written more about them than about any other topic so far). Even if something went wrong, we could all develop, innovate, compete--and seek a refund later. Right now, Apple just says "no" and that's the end of the story (and of this post).

Share with other professionals via LinkedIn:

Share|

um