Epic versus Apple: What's at stake if Apple loses

Apple and Epic Games are in the middle of a courtroom battle for Apple's control of the App Store and the iOS and iPadOS ecosystem. It's a high-stakes fight that could lead to major changes in the way apps can be bought and used on the iPhone and iPad, as well as Apple's revenue.

It's a lawsuit that could potentially cost Apple billions of dollars if everything went Epic Games' way — and not from damages. If Epic prevails in court, Apple could be forced into altering policies about what apps can or cannot do, which could impact Apple's potential revenue in the future.

While it is up to the U.S. legal system to determine if anything needs to be done, and how far to take things if changes are needed, the changes could be profound to the user experience.

This legal fight will continue for years. Regardless who wins, there will be fierce appeals of the decision with it likely to hit the supreme court.

But, it's entirely possible when everything is said and done, Apple may lose, and be forced to make changes to the App Store.

What does Epic want Apple to change?

Epic's fight with Apple is complex enough to warrant three dedicated weeks of a court's time. However, it can be boiled down to a number of key objectives that Epic and other developers could benefit from, if the court sides against Apple.

First, Epic wants the ability to have alternative payment systems available for app-related purchases. It wants to be able to give users the option to pay for their in-app purchases via a different payment provider than the one Apple offers, such as its own system.

Epic also wants to be able to tell consumers that there are alternate ways of paying for goods, and not necessarily through their device. Current policies forbid apps from such activity, like telling consumers they can get a cheaper deal from the company's website.

Also at stake is Apple's transaction fee for in-app purchases. At present, developers who make less than $1 million a year pay 15%, and if they exceed that figure, the rate is 30%. Subscription fees vary, but start at 30%, with the rate decreasing to 15% if a user stays with a service for a consecutive year.

Lastly, Epic wants the ability for apps to be side-loaded by users without needing to go through Apple's App Store. It wants users to be able to access a third-party app marketplace that could be used to buy apps and other items, completely independent of the App Store and Apple's digital storefronts.

On each point, Epic stands to benefit in some way from being granted such concessions, and these scale from relatively minor to major changes to the fundamental nature of iOS. Some could simply be implemented as policy changes, but others could require considerable amounts of work to undertake.

The cost of doing business

For these and any other changes that could be made, Apple stands to lose revenue. While it can see a reduction in some revenue, the remaining income still has to cover the costs of the App Store, and any extra elements that may be needed to implement changes permanently.

While altering the commission level is direct and can give Apple more control over how low it goes, developers pointing users to ignore Apple's payment mechanism in favor of a website or its own in-app purchase system is worse for Apple, as there's no commission in play at all.

The App Store costs Apple money to run, as it has to keep the store online, host apps and updates that will be downloaded to user devices, pay for the bandwidth it uses, as well as maintain the quality of the App Store with its review process.

If Apple loses out on commissions and the App Store becomes a cost to the company instead of a profit center, it may have to move to recoup the shortfall in other ways.

It is unlikely that Apple would pass on the cost of running the App Store onto consumers directly, but if it is forced to recover its costs somehow, this could be in the form of other fees to developers.

We ultimately don't know how Apple could earn more money from transactions if the commission is forcibly reduced or is avoidable, but Apple has many levers it can pull to balance its books at the end of the day.

Letting developers tell users that they can make purchases outside the App Store

Probability: Most likely to change

If Apple is forced to make changes to how app transactions are conducted, it would try and go down the path of least resistance. The simplest changes Apple could implement are policy ones, in that they affect what a developer can or cannot say or do within an app.

Probably the easiest that apply to Epic's complaints is altering Apple's anti-steering provisions.

Under the App Store Review Guidelines, section 3.1.1, developers "must use in-app purchase" for unlocking app features, buying in-game currencies, and other items. Apps are also banned from using their own mechanisms to do the same job within the app.

More importantly, apps and metadata "may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase." In short, while it is entirely feasibly possible for a developer to alert customers to other places they can pay for the same content, they are forbidden by Apple from saying as such within the app itself.

Arguably the easiest way to implement the change is by simply doing away with policies that prevent developers from advertising off-platform stores and payment mechanisms. Such a change can be accomplished quickly, and largely involves changes to Apple's developer agreements and some training for App Store reviewers.

The odd thing is that developers were previously allowed to say about off-platform purchasing mechanisms. In 2011, Apple updated its review guidelines, allowing subscriptions and access to content sold outside of the app and the App Store elsewhere, but rejected apps that linked to external mechanisms for purchasing content.

To Apple, this could result in a direct loss of revenue, as it would obviously enable developers to encourage users to pay them for in-app purchases elsewhere. This avoids Apple's in-app purchase (IAP) system entirely, and so Apple misses out on the commission.

The impact of this isn't going to be massive to Apple, as most customers will probably prefer the immediacy of a transaction through the App Store than the extra steps required to perform a purchase elsewhere.

Pros

• Very easy for Apple to implement in a short space of time
• Least potential harm to Apple out of all changes

Cons

• Some loss of sales and revenue
• Increased steps for consumers to make purchases than at present

Changing the commission fee structure

Probability: Likely

The other policy-related change would directly target that commission. Apple has already made some changes to adjust its historic 30% cut of IAP and App Store purchases, such as its App Store Small Business Program, which will cut the fee down to 15% for those earning less than $1 million in revenue from the transactions.

Apple already has a program in place for subscriptions, where the commission cuts from 30% to 15% automatically for the second and subsequent years of a user's continued payment for an app.

The 30% fee was even questioned by Apple's executive team at one point, with Phil Schiller asking as early as 2011 whether Apple could scale back the 30% cut to 25% or even 20%, so long as Apple was still earning profits of $1 billion.

Naturally, the modern revenue levels are much higher, but it's still plausible for Apple to cut the commission down, without losing money from the function of the App Store itself. There would be no reason for Apple to offer a 15% commission fee rate if it didn't stand to continue earning a profit.

Since the App Store costs money to develop and function, Apple still has to charge a bare minimum to cover the cost of running the store in the first place. No-one knows exactly how much it needs to run the App Store, and "free" apps still incur costs, so that percentage level is unknown.

The real question that has to be asked is how far down Apple would be prepared to lower the rate to appease developers, while still keeping shareholders happy with overall revenue levels, and fundamentally keeping the App Store itself in operation.

Pros

• Relatively easy for Apple to change
• May help improve relations by increasing developer revenue share

Cons

• Reduced revenue from App Store sales

Enabling third-party payment systems through the app store

Probability: Maybe

Enabling developers to add their own payment mechanism to apps for the facilitation of IAP sounds like it could just be a policy change. It's pretty much the same base idea as referring users to a website to use the developer's chosen payment system, but instead it's within the app and directly usable.

To Apple, this has the same ultimate end goal of enabling developers to avoid its IAP system entirely, and so Apple misses out on that commission once again.

Putting the payment mechanism within the app is entirely possible now, as evidenced by Epic Games' update to "Fortnite" that triggered the lawsuit to begin with. However, introducing a payment system to an iOS app that avoids IAP could introduce its own problems.

For a start, there's the issue of security. If Apple were forced to allow any payment mechanism that a developer wants to use, it would have relatively little control over the transaction itself, and with no way to ensure charges are being applied correctly.

Users will have to trust the developer and the payment platform in use are being above board with their payment details and that the transaction goes through smoothly. While users are very familiar and trust Apple Pay and Apple's IAP in general, users may be wary of taking a third-party payment option, simply from not having used it as much as Apple's version.

Even if the third-party payment platform provides benefits such as a cheaper overall transaction, it could still make a user question their level of trust with Apple's ecosystem as a whole.

Third-party payment platforms can certainly be introduced, but Apple loses that valuable commission, and potentially the user's trust as well if the transaction goes horribly wrong.

As a byproduct of enabling third-party payment systems in apps, this may also force Apple to naturally cut down its commission fee to compete on price.

Pros

• Relatively easy to implement by Apple
• Could be offered without requiring technical changes on its side

Cons

• Reduced revenue for Apple from processing fewer sales
• Potential damage to user trust of Apple if third-party system is faulty or malicious
• Competing payment systems could force Apple into reducing commission fee

Third-party app stores

Probability: Low

On the tougher end of the spectrum for Apple is the third-party digital storefront.

To Epic, it wants the ability to host its own digital storefront on iOS, allowing it to directly sell games and apps to consumers without caring about Apple's App Store restrictions and policies, or even the commission. Owning its own storefront gives it almost limitless control over how transactions take place between Epic and consumers, and potentially enabling Epic to earn more money from selling other games and content.

To consumers, this would give the opportunity to benefit from competing stores, such as being able to buy apps from one store rather than another over price differences. As well as a consumer-focused price war, the competition could force the storefronts to compete on commission levels, encouraging developers to use its store in exchange for more revenue per sale.

Obviously, the impact to Apple here certainly is financial and reputational, as Apple wouldn't have the ability to curate or control the types of app that appear in the other digital storefronts, and certainly wouldn't be able to earn money from those transactions.

Apple also wouldn't be able to directly prevent the sale of apps sold through the third-party store, nor would it be able to ensure a basic level of on-brand-for-Apple quality of apps appearing on its devices. The App Store prevents the sale of apps with obvious adult content, for example, but such a restriction may not be upheld by another store.

This would be a reputational quandry for Apple, but one it would have to accept if it is forced to do so.

One benefit would be that the same third-party app stores would have to handle updates and related transactions. This would reduce bandwidth and support costs for Apple, as that duty would fall upon the third-party store.

But if that store were to suddenly disappear or otherwise become unavailable, consumers could try turning to Apple for assistance, potentially in vain.

Building in the infrastructure to enable third-party app stores while maintaining the security of iOS and iPadOS will also be a challenge, but as explained further down, it presumably could be done.

Pros

• Increased competition beneficial to consumers and developers
• Wider choice of apps to download for consumers

Cons

• Apple wouldn't be able to curate content of other storefronts
• Quality of apps would be down to the app stores
• Consumers could be harmed by third-party app store problems or bad actors
• Competition wouldn't necessarily benefit Apple
• Overall loss of App Store revenue
• Would require implementation of increased security for apps

Casual Sideloading and independent downloads

Probability: Low

The ability to casually sideload an app, namely the act of acquiring an app through other means and loading it onto the device, will have a similar effect to Apple as enabling third-party stores. As such, it is probable that an opening up of sideloading would be performed alongside enabling third-party app stores.

Technically speaking, sideloading is already possible, but certainly not in a way meant for general app distribution.

Enterprise developer certificates can allow some apps to be sideloaded and avoid the App Store Review process, but in relatively low and controlled numbers, and with a list of rules that must be adhered to for their use.

Xcode, Apple's developer environment, also enables some sideloading of apps onto devices, however this again is intended for developer usage, not consumers. Also, devices using Xcode-sideloaded apps have to deal with a repeated resigning of apps every so often depending on if the user is a paid developer, interrupting the user experience but ensuring it's not used for distribution.

A relatively similar area to sideloading is allowing the installation of apps from the Internet without going through an app store or any kind of signing process. This is effectively the same as sideloading, as it bypasses stores completely, and presents the same challenges and issues. Instead of connecting the device to a computer, it's all done as a browser download or through a similar software mechanism.

Like with third-party stores, Apple could accomplish this, but it would have to get around the same sort of technical hurdles in its implementation. Also again, Apple presumably would not see any revenue in the future from setting up sideloading and enabling downloadable installers.

Pros

• Consumer freedom to install apps from practically any source with minimal restrictions

Cons

• No revenue for Apple due to bypassing the App Store completely
• Would require implementation of increased security for apps
• Apple would have no control over app quality or what apps are used on its devices at all.

Security principles of macOS could be introduced to iOS

Adding another app marketplace to an iOS device introduces some engineering challenges that have to be overcome by Apple. While it does offer various checks through the App Store Review to ensure the safety and quality of apps for consumers, third-party app stores may not have the same level of rigor as Apple's version.

It's also feasible for the sideloaded app to sidestep review processes of any stores, both Apple's own and third-party stores. It may even be feasible that the app being sideloaded is purposefully malicious in nature.

This means Apple will have to make sure that iOS is capable of withstanding potential attacks from malicious apps that make it through those other stores, or are added via sideloading.

As to whether Apple can protect iOS under such circumstances, one Epic expert witness believes it can. During testimony, Harvard University Computer Science Professor James Mickens explained to the court that iOS either has mechanisms in place that could protect the operating system, or that Apple could feasibly add macOS-style protections.

There's a few primary protection measures that could be put into play by Apple.

Sandboxing

The concept of sandboxing is to run an app in a way that it is contained from anything else in an operating system and device. To enable the app to function, it is granted access to specific resources by the operating system that are secured and protected.

In iOS, all third-party apps are sandboxed, isolating them from other apps and minimizing the amount of system data it has access to. It ca request access to other information, but the operating system can limit what it sees, or whether it can even access that data at all.

As part of sandboxing, most iOS and iPadOS apps are run as a non-privileged "mobile" user. This prevents it from editing anything in the read-only OS partition or by changing other apps.

Apple has also set it up so apps cannot escalate their own privileges to higher levels to gain more access, such as to modify other apps.

Since the app is contained within a unique home separate from everything else, it is relatively trivial for the operating system to shut the app down or even delete it entirely.

App Signing

While macOS has its own Mac App Store, Apple still enables apps to be installed from other sources. This could be from other storefronts, such as Steam, but also as downloads from the app's developers.

To enhance the protection of Mac users, since macOS 10.15, Apple has required apps distributed outside of the App Store to be signed by the developer, using an Apple-issued Developer ID certificate and a private key. An app that has been signed can be checked by macOS to ensure that the app hasn't been tampered since the app was last signed by the developer.

If the signature fails to be verified, macOS will determine the software isn't necessarily legitimate, and won't run it.

Importantly, the concept of app signing is already in play on iOS, with developers producing iOS apps requiring certificates from Apple, and to sign the apps before submission to the App Store.

The use of certificates is also useful, as it can allow Apple to revoke certificates for developers that are breaking its developer agreements or are somehow distributing a massively faulty or malicious version of an app.

An example of this is the revocation of Facebook's enterprise developer certificates in January 2019, when it was found that the social network had distributed a VPN app to end users. When the certificate was revoked, not only did the questionable VPN app stop working, but also all of Facebook's internal apps.

App Notarization

While an app can be signed by a developer, there's no guarantee that the app is still safe for end user consumption. A signed app could easily be malicious, intentionally or not, and hasn't undergone any separate checks to ensure its safety.

Notarization is a system where developers send their signed app to Apple to be scanned. The automatic process checks for security issues and malicious code that could be embedded within the app, with only those that pass the security checks being notarized by Apple.

This is intended to mimic the same checks and balances that the normal App Store Review process undertakes, but on apps that won't actually appear within the Mac App Store. These notarized apps can be uploaded to a server for distribution through other app marketplaces, or simply for download from the developer's website.

Gatekeeper

The last major piece of the puzzle for macOS is Gatekeeper, a tool used to ensure software that can be trusted runs on a Mac. Chiefly, it checks apps that have been downloaded from sources that aren't the Mac App Store, and therefore cannot be trusted at face value.

When an app is downloaded, Gatekeeper makes checks to ensure that the app's developer signature is valid, that it hasn't been tampered with since that signing, and whether it has been notarized by Apple. Ensuring both is usually a good sign that an app is safe.

On macOS, Gatekeeper also asks users for approval before installing or running the downloaded software. In effect, this can warn a user in some situations that there's something fishy going on, such as if they are trying to open a file that seems to be a document but is really an executable.

The system defaults to protecting the user, and organizations can lock down Gatekeeper to only open software from the App Store itself. However, by the same token, Gatekeeper can also be overridden to allow any software to be run, or disabled completely.

Technically possible

Epic argues that it would be technically feasible for Apple to introduce macOS-style security on its mobile platforms. To a point, this argument seems to be quite plausible, as it appears to be entirely feasible for Apple to produce and add something similar to iOS.

Given that Apple has moved to an architecture in Apple Silicon that allows iOS and iPadOS apps to run in macOS, this would suggest that the same processes could potentially work on its mobile platforms. This is doubly so given that the iPadOS-running iPad Pro now uses the M1, the chip used in the current-generation Macs.

While it is still not known for certain how much code is shared between iOS, iPadOS, and macOS, it's likely that it is quite significant. This certainly doesn't mean Apple could copy and paste code across, but it would certainly know what it's doing when trying to implement similar systems.

It's also not entirely out of the realm of reality for Apple to implement all of the back-end systems required for signing and notarization for iOS apps in the same way as macOS apps.

Such a project would require considerable resources on Apple's side to implement, but if pushed, it would have to.

However, given that iPhone is such a major platform, it seems unlikely that Apple would allow any form of iOS Gatekeeper to be disabled at all, or even give the option to run un-notarized, unsigned apps at all. Apps on other app stores will probably need both to run at all on iOS.

Apple doesn't want to lose, but it could change

As the case stands, the majority of observers think that Epic has a hill to climb, and it has not done so yet. The judge has a history that suggests that she will rule in Apple's favor, and has already made her position known about Epic's stunt in introducing the V-Bucks transaction server-side to generate positive user sentiment, violating its contract with Apple in the process.

It is a bench trial. One judge, one opinion, one ruling — that could go any way.

To Apple, the court case means many things, with retaining power over its software ecosystems being a high priority. If it is forced to give up that power, it certainly has options to do so, though with different levels of effort required depending on what the legal system mandates.

Policy changes are relatively trivial to implement, but bring with them a loss of revenue that Apple may try to recoup in ways that may be challenging to developers. This could be service charges for hosting files in the App Store, or even higher fees for becoming an Apple Developer in the first place.

On the more technical side, it certainly could implement the checks and balances to ensure that apps sideloaded or downloaded via third-party app stores can still be as safe as possible for end users. However, this would be an endeavor Apple would have to accomplish without any guarantee of earning revenue, whereas the existing App Store system maintains it.

Regardless, any "loss" by Apple isn't a binary condition, and will implement, one, some, or none of the above fixes. None of them will be good for its bottom line, but it can certainly make the necessary changes if it is ordered to do so — and after all appeals are exhausted.