When Apple decided to support applications on the iPhone in 2008, it did so in the most Apple way possible (see “Apple Announces iPhone 2.0, Releases SDK,” 6 March 2008). The company distilled the complex process of finding, purchasing, downloading, and installing apps down to a simplified user experience. With the App Store, customers could go to a single storefront and do everything with the tap of a finger. Apple vetted apps to meet the company’s standards and security requirements, providing customers both convenience and peace of mind.
Apple prioritized iOS security from the start, realizing that customers were more likely to buy iPhones and apps if they didn’t have to worry about malware. The company leveraged its complete control of iPhone and iPad hardware, iOS, and the App Store to create one of the most secure software ecosystems in the history of personal computing, rivaled only by gaming consoles. Perfect? No. Highly effective? Absolutely. Apple built a security model based on vertically integrated security that combines hardware, software, and services, with the App Store playing a key role (see “Apple Platform Security Guide Reveals Focus on Vertical Integration,” 18 February 2021).
But this foundation is now at risk, largely due to how Apple has treated app developers and payments. On 25 March 2022, the European Union published its draft Digital Markets Act. If enacted, the legislation would, among other things, require Apple and similar companies to support alternative app stores. Apple is still embroiled in a lawsuit with Epic Games that focused on forcing non-Apple app stores onto iOS. Over in the Netherlands, Apple has been forced to open up external payment systems for, of all things, dating apps. While supporting alternate payment systems doesn’t affect security, opening up to alternative app stores will have profound implications.
Apple largely has itself to blame. Apple didn’t create a walled garden marketplace merely to ensure consumer safety; it also did so to own the billing model and financial transactions, and thus the customer relationship. Until a week ago, a developer wasn’t even allowed to link to or mention their website for prospects to sign up for subscriptions. For over 13 years, Apple refused to budge to pressure from developers, forcing them to turn to the courts and legislatures.
Let’s distill this down to understand why the App Store is so important for security, how opening iOS up to alternative app stores or sideloading will reduce our safety, and why this now seems inevitable.
How does the App Store work with iOS security?
Apple uses a vertically integrated security model for iOS devices. That means that the overall platform security is provided by Apple hardware, software, and services all working together. You can read the details in the Apple Platform Security Guide, but here is a simplified summary:
- Developers write their app code using Apple’s tools, which automatically enable certain security features to reduce the risk of vulnerabilities.
- To submit apps, a developer must be approved by Apple and issued a digital certificate to sign their apps. Apple tries to validate that the business is real, but experience tells us that it doesn’t always get it right.
- Developers sign their apps and submit them for approval. Apple assesses each version of each app, including running security scanners to find common coding vulnerabilities.
- By default, apps are completely isolated and have no access to user data anywhere on the device. Even access to capabilities like Bluetooth is restricted. Developers who want additional access must request an entitlement from Apple.
- If approved, the application and its entitlements are cryptographically signed by Apple and placed on the App Store. I’ll explain why this is so important in just a moment.
- On the device side, iOS boots up using a chain of trust. This complex process relies on a series of digital signatures and code signing checks to assure that each part of the operating system is official, trusted, and tamper-proof. It also relies heavily on the Secure Enclave, which manages cryptography functions and holds the root encryption keys and certificates in a secure portion of the device’s system-on-a-chip so they can’t be modified.
- When an app runs, the operating system extends the chain of trust to the certificate used to sign the app itself. That certificate must be valid, and the app’s code has to match code signature checks that ensure it hasn’t been modified since it was installed or updated.
- Part of this process validates the app’s entitlements. Apple signs those so an app can’t suddenly start reading your contacts if it hasn’t officially been approved for an entitlement. Many entitlements also won’t work unless the user is prompted and approves the access. Facebook can ask to see your contacts, but you don’t have to let it. (And for the sake of the privacy of all your contacts, don’t!)
- The app then runs in a sandbox that is isolated from the rest of the software on the device. Apps are provided their own file storage, separate from other apps. iOS uses internal security capabilities to enforce this isolation. When apps do need access to shared resources or each other, this access is also controlled by iOS and relies (partially) on more digital signatures for enforcement.
Now explain it like I’m a fifth grader?
Sure thing. Apple scans every app submitted to the App Store for malware and security vulnerabilities. After approving an app, Apple puts it in a digital envelope sealed with digital wax (those signatures and certificates we talked about). Hardware and software on our iPhones and iPads check the seal and ensure the app was approved and no one has tampered with it. That same hardware and software then isolate the app when it runs so it can’t do bad things. All this keeps your device safe and, via entitlements, protects your privacy.
The entire system relies on Apple services (the App Store and developer program, plus digital certificate servers), Apple software (iOS and iPadOS), and Apple hardware (the Secure Enclave and certain other hardware protections we are skipping).
This sounds great, so malware is impossible on iOS?
Alas, no. There has been malware on iOS. It’s just a lot harder and more expensive to create, much more difficult to distribute, and far easier to shut down. For example, the NSO Group developed an incredibly sophisticated iOS exploit that relied on building a Turing-complete emulator within an obscure PDF feature.
There are also plenty of scammy apps in the App Store that meet all of Apple’s security requirements but still come up with ways to trick users out of their money through sneaky subscriptions or by targeting kids. Unpleasant as these apps are, they can’t take over your iPhone and spread to other devices on the same network.
How do we know this all actually works?
As we like to say in the security world, the proof is in the pudding. There has never been any widespread malware on iOS. Malware is more of an issue on Android, but even there it is less of a concern when users stick with the official Google Play Store.
In Nokia’s Threat Intelligence Report 2020, the company shared a breakdown of malware infections by device for 2019 and 2020. In 2019, Android led with 47% of infections, compared to less than 1% for iOS (the other two categories were Windows PCs at 36% and Internet-of-Things devices at 16%). However, noting that the security of official app stores like the Google Play Store has increased continuously, Nokia found in 2020 that Android accounted for only 27% of infections, and iOS remained under 2%. (Windows increased slightly to 39%; the IoT devices drew most of the malware attention, jumping to 33% of infections.)
These numbers support the fact that there is vastly less malware targeting iOS than Android, thanks to Apple’s insistence on a single App Store. Even within the Android world, the increasing security of the Google Play Store resulted in an overall drop in malware infections, even though they remain high due to the availability of alternative app stores and sideloading.
Why are digital signatures so important?
Earlier, I mentioned the chain of trust. Many forms of malware find a vulnerability on a computer and then use that to embed themselves in some pre-existing piece of software. This technique enables attackers to establish persistence, so the malware doesn’t just run in memory and disappear when the app shuts down or you reboot.
The chain of trust does two things. First, it uses cryptographic signatures to ensure the running software comes from a trusted source. That’s why Apple embeds a read-only signature onto its devices; the attackers have no way to swap in a different signature to fool your iPhone into thinking that it’s running trusted code. Web browser developers like Google do something similar by embedding known signatures into their browsers as certificates that enable a “root of trust.” These root certificates are trusted by the Web browser companies and are used to sign and validate the site-specific certificates used by websites, so you get those little green validation marks when you connect to your bank.
For apps, Apple also makes a cryptographic “hash” of the code and signs it digitally. A hash is a manageable number that maps to the app’s code and changes if even a single bit of the code changes. iOS can then ask, “Does this app come from where I expect?” and “Did the app change at all?” (And obviously, if the answer to either of those questions is “No!” iOS won’t let the app run.)
On iOS, this chain of trust runs from the lowest levels of the operating system when our iPhones and iPads boot, all the way to the apps we download and run from the App Store. The entire chain relies on these digital signatures, certificates, and hashes.
Tell me again how knowing all this improves security?
There are three benefits:
- We know that all apps in the App Store have been scanned and approved by Apple. This significantly reduces the risk that an app we download is deliberately malicious or accidentally harmful.
- We know that all the apps on our iPhones or iPads came from the App Store and are running the same code that we downloaded—malware infections that modify apps are nearly impossible.
- We know that apps can’t get—or even ask for—access to data like contacts or calendars, or features like Bluetooth, without Apple having approved their entitlements.
What about sideloading?
Sideloading means allowing users to install apps directly, without going through any app store. Typically, users must enable sideloading manually, since devices default to staying locked down, but it’s still a huge security hole. Alternative app stores enable installing apps from additional, hopefully trusted sources. Sideloading lets users install anything they want… or can be tricked into installing.
Of course, sideloading is nothing new—it’s how things work on the Mac today, where you can install any app from any source. Although much Mac malware takes advantage of sideloading, none of it has been truly widespread so far. That’s more likely a side effect of the Mac being a relatively small target; there are so many more iPhones and iPads combined that malware authors target them even though it’s very difficult; if it got easier, we’d see many more attacks.
Could Apple enable alternative app stores?
Yes. There are two ways Apple could support third-party stores:
- Apple could authorize another store and issue it a certificate with which it could sign its own apps, after which the chain of trust would expand to include that certificate. This approach would be similar to how Web browsers come bundled with a series of root certificates used to sign the certificates of websites, although that system has been abused as well.
- Apple could also issue certificates to all comers or disable some or all of its existing security checks for apps that users download from a third-party store. This approach, which is how things work on Android, would make possible a range of potential app stores with widely varying approval policies and levels of security.
Why do alternative app stores reduce security?
It comes down to consistency and enforcement. Apple couldn’t review the apps in those stores and ensure they meet Apple’s requirements. Nor would Apple be able to review entitlements in those stores. The alternative app stores would only be as secure as they want to be and are capable of enforcing.
If Apple were to allow only a small number of vetted alternative app stores, this might not be too terrible. Apple could set standards for those partners and issue them special certificates to sign their own apps. Then Apple could build a security program to ensure those partners met and maintained standards that were at least equal to Apple’s.
On the other hand, if Apple were required to allow any arbitrary alternative app store, we immediately run afoul of the same problems that plague Android since there is no way to enforce any security standard. This model would either require Apple to issue certificates to anyone or, more simply, enable users to disable the signing mechanisms and allow any app to run without the security checks.
The first option is much more secure, but it doesn’t provide many benefits to the third-party app stores beyond handling their own payments (I’ll get back to that). Also, Apple would likely still draw complaints similar to those the company faces over the official App Store, since Apple would have to set standards to be in the program, charge to participate, and probably anger all sorts of alternative app stores that don’t align with Apple’s goals. The second option creates a free-for-all without any security enforcement, and we can already see how that model results in a less-secure, malware-friendly environment on Android.
Couldn’t users just stay secure on the official Apple App Store?
Users could choose to trust only Apple, but over time, there would be both direct pressure and scams to move users to alternative app stores. Some popular apps might require you to use an alternative app store and decline to participate in Apple’s. Most people aren’t computer security experts and won’t know the implications of trusting a new app store on their phones, and even tech-savvy users will be forced to install Facebook, Instagram, and WhatsApp.
What if your bank only supports an alternative store? Or someone tricks you into thinking your bank only supports an alternative store? How certain are you that you’ll be able to make the safe decision every time one comes up? Alternative stores and sideloading increase security complexity for users, and history shows us that complexity opens up opportunities for attackers.
Again, we already see this on Android, where users can be tricked into sideloading or using an alternative, untrusted app store to install some app without realizing it is a scam or malware.
Isn’t this how “enterprise applications” work?
Apple does have a program for enterprises to build and install their own apps onto corporate-owned devices. This is exactly how the best-case alternative app store model could work. Apple issues a certificate to these companies, which then use a process to install the certificate on employees’ iPhones, allowing apps signed by that company to run.
This system was abused by Facebook a few years ago, which highlights the trust issues that come into play when Apple starts handing out certificates.
Don’t gaming consoles do the same thing?
Absolutely. Apple didn’t invent the app store model or create the first walled garden marketplace. Video game consoles are probably the closest example. They are powerful computer systems with single-source app stores and locked-down hardware. Game companies have been running walled garden marketplaces since the first home systems appeared. The only difference back then was that we only loaded games from physical media, like cartridges or CD-ROMs.
As a result, game systems also have extremely low rates of malware and scams, just like the iOS ecosystem.
Why do developers and companies want alternative app stores?
The first answer is easy: “follow the money.” Right now, Apple enforces app standards (such as no “adult” apps) and takes a 30% cut of all sales made within apps (there is now some variation in the fees). Apple also takes a cut of all in-app purchases. This is why you haven’t been able to buy a new book in the Kindle app; Amazon doesn’t want to pay Apple 30% of every book sale when it can instead make users buy books within their Web browsers and not share any of the revenue with Apple.
The problem is that Apple has also long prevented Amazon and other companies from linking out to their websites for purchases or even telling users that it’s an option. Happily, after pressure from Japan and the Netherlands, Apple has relaxed its rules to allow alternative payment options or linking to external subscription services. “Reader apps” that are primarily meant to provide access to digital content, such as Kindle, Netflix, Spotify, and others, can now direct users to an external site for payment, albeit with some rather stiff required language. (At least it’s better than it used to be.)
Apple does deserve some cut of transactions—running the App Store does entail significant costs—but well below the standard 30%.
Apple also has a history of frustrating developers in other ways. It sometimes rejects apps for seemingly arbitrary reasons. It doesn’t do a good job blocking clones and copies of popular apps, which can damage small developers. It puts in obnoxious requirements, like requiring developers to use “Sign in with Apple” if they also enable “Sign in with Google” or any other third-party sign-in service. Plus, there are entire categories of apps Apple simply doesn’t want on its platform and won’t accept into the App Store.
Regardless, money, more than frustration, is what drives the push for alternative app stores. I highly doubt Epic Games is suing Apple for any reason other than the cash. It just so happens that Epic Games has its own app store for games where it takes a cut of all the sales from the developers in its ecosystem. Just like Apple does now. And no, the Epic Games Store doesn’t allow alternative stores within it, either.
Money comes into play in another way, too: privacy. Some developers and payment providers want to track users and their purchases so they can further monetize this information. Right now, Apple owns the customer relationship for in-app purchases, which is why, for example, you aren’t spammed by every app you ever downloaded. If you don’t create an account with a particular developer, they have no idea who you are. Also, if you sign up for a subscription to something in the App Store, it appears on your account and you can cancel whenever you want without having to jump through any hoops.
In short, Apple enforces its philosophy that you are the customer, not the product being sold. There are robust ecosystems to track and sell your data that are significantly more restricted on iOS than Android because of Apple’s requirements. For example, Facebook is losing billions of dollars because Apple now forces the Facebook app to ask users for permission to track them. Well, and because 96% of users in the US opt out when asked.
Why are regulators forcing Apple to support alternative app stores?
Many companies have been unhappy with the App Store’s restrictions and financial model. Some of these companies, like Epic Games, have sued Apple in an attempt to force changes via the courts, while others have been lobbying governments. Apple is a huge target, and the European Union, in particular, is open to using regional regulations to increase the competitiveness of its local businesses by forcing interoperability.
Global technology companies like Apple, Google, and Meta (Facebook) are facing increasing scrutiny worldwide due to their dominance across society. Issues surrounding alternative app stores and sideloading are among the many regulatory questions surrounding the tech giants, along with antitrust investigations, encryption regulations, and complex issues around content moderation and ownership.
From one perspective, it seems unfair to force Apple to allow alternative app stores, given that it built a completely contained robust marketplace in a world with Android’s even larger competitive ecosystem.
The opposing view recognizes that mobile devices have become essential and ubiquitous—in the future, everyday activities will be more difficult or even impossible without one. (In some places, you now need a smartphone to scan a QR code at a restaurant even to see a menu.) That points toward governments wanting some say in how their citizens are treated. The world is dominated by just two platforms, Apple and Google, both of which rely on their own app stores (Google also takes a 30% cut), but only Apple’s is mandatory.
Right now, the European Union is the biggest threat to Apple’s model because of its sheer size and influence. But we also see lawsuits and proposed regulations here in the United States, including the Epic vs. Apple case, which is on appeal. (Full disclosure: I signed an amicus brief to the courts in that case highlighting the dangers of alternative app stores.)
Couldn’t Apple just allow alternative payment systems and keep the App Store secure?
It may be too late to prevent governments—or possibly the courts—from forcing Apple to support alternative app stores and maybe even sideloading. Apple had many years to respond to the complaints and concerns that led companies to file lawsuits and lobby lawmakers. When Apple talks about keeping the App Store locked down and exclusive, it always focuses on security without acknowledging the financial side of the equation.
I believe that Apple could have reduced the likelihood of being forced to accept alternative app stores and sideloading by decoupling the security of the App Store from payments. Apple continues to fail to discuss or even consider App Store payments separately from App Store security, but the two are only slightly related. (Apple has some legitimate concern in preventing customers from being scammed by alternative payment systems, but that’s largely unrelated to platform security.) I can’t help but think that developer complaints would have been far more muted had Apple loosened some of its payment restrictions and percentages more aggressively. Apple might not be in this position today if it has been more responsive to developers in the past.
Courts and regulators aren’t technology experts and seldom understand subtleties like the difference between payments and security. They tend to use a sledgehammer instead of a screwdriver. Apple simply let App Store dissatisfaction simmer for too long.
What will happen now?
Sadly, from my perspective as a security expert, I think that courts and regulators will force Apple to support both alternative app stores and sideloading within the next few years. This will materially increase the security risk on iOS devices, especially for those less familiar with technology who don’t understand the security risks. It will start in Europe but quickly spread to other regions, including the US. It could also have larger implications in markets like China, where the government will likely try to exert even more control over what Chinese citizens can buy—imagine a highly regulated Great Bazaar to match China’s Great Firewall.
As Apple customers, we can still protect ourselves. Personally, I plan to stick with Apple’s official App Store and will continue to recommend the same to anyone willing to listen. I fully expect Apple to default to the same level of security we have today and require users to jump through a (hopefully) painful process to authorize other app stores and sideloading. I also fear that, at least at the start, the technical updates required to support alternative app stores will create new attack surfaces and security vulnerabilities that could have a broad impact.
If any lawmakers, regulators, or judges are reading, I implore you to explore the implications of such requirements and consider that there are options to force payment processing changes rather than blowing up the entire security model that has kept iPhones so safe for over a decade.