Last month, the European Commission issued “preliminary findings” regarding Apple’s iOS operating system, publishing a set of sweeping proposed measures for Apple to fully comply with the Digital Markets Act (DMA). The proposed measures primarily implement Article 6(7)’s interoperability mandate, applying the provision inflexibly to 11 iOS features, mandating that Apple make each of them just as available to third-party developers as they are to Apple itself. Observers who thought the Commission would respect the technical realities of making operating systems interoperate with third-party software and devices were undoubtedly disappointed to see that feasibility does not figure into the proposed requirements. Compounding this short-sighted approach, the Commission also chose to ignore input from any App Association members. Ironically, it selectively curated the respondents, ostensibly to demonstrate support for the adoption of proposed measures that eliminate the ability for Apple to choose its own business partners. From the standpoint of small developers who benefit from Apple’s active management of the iOS ecosystem, a few issues stand out as especially problematic and could serve as lessons learned as policymakers in other jurisdictions consider DMA-style regulations. Fortunately, the Commission still has an opportunity to adopt a more proportional approach that better serves the wide range of iOS developers—instead of exclusively those that are most well-resourced—and we hope that these considerations help with the Commission’s deliberations.
Encumbering or Eliminating a Broad Range of New Features and Updates. One of the great benefits of the iOS ecosystem for small developers is that Apple rolls out new features at a vigorous pace and fixes bugs efficiently across millions of devices via regular updates. It also has a robust beta program for developers. Unfortunately, the Commission proposes that, across all 11 of the iOS features to which the document applies, Apple must “inform third parties of the addition of new feature functionalities or updates of the relevant feature as soon as Apple has taken the decision to add these feature functionalities or updates” (emphasis added). But these provisions would operate more broadly than those 11 iOS features, effectively applying to any features that may be the subject of future requests. This extraordinary scope would require that third-party developers be in the room even during the development phase of either a new feature or even a simple update to any of the features, which could dramatically slow down the update process. Compounding this issue, paragraph 131(d) would prohibit Apple from restricting “business users, directly or indirectly, to make use of any interoperability solution in their existing apps via an automatic update.” The provisions would work together to effectively give each and every developer the ability to preview the rollout of any potential update to an undefined range of iOS features and give some developers veto power over updates. As a result, the few well-resourced developers with the significant resources needed to dedicate staff and time to participating in this iOS update review process would dictate the course of iOS updates in the proposed measures’ scope. They would rationally elect to control the issuance of iOS updates to serve their own interests at the expense of the much more numerous small business iOS developers that have long depended on efficient updates designed to serve the broader ecosystem. More insidiously, this would put in place a durable framework that is neither grounded in DMA’s legal requirements nor limited to the Commission’s contestability objectives. Apple would be required to maintain this permanently broad and complete access in perpetuity, diverting resources to catering to unforeseen use-cases from specific developers and away from rolling out new features, technologies, and updates developers actually want. Developers (except those with the most resources and specific interoperability needs) would expect overall slower and less responsive rollouts in Europe.
Background Execution Management. Section 1.2 of the proposed measures mandates that Apple must provide full access to background execution—processing functions taking place in the background, including when the phone is locked—to any developer of a companion app that goes with a third-party connected device. The fundamental problem here is simple: computing resources are finite. Developers know that the inability for iOS to manage access to computing resources presents a classic tragedy of the commons. If the operating system cannot say no to unlimited requests to access computing capacity, it is easy to see how poorly the phone could operate. Background execution functions allow for connected devices like watches and headsets to upload data to or perform processing on the iOS companion app even while the phone is locked. Here is where things get unfair. One of the most intractable issues with virtual reality / augmented reality (VR/AR) headsets is providing for adequate compute capacity inside of—or in equipment connected to—the headset itself while avoiding adding too much weight to the device or making the assembly cumbersome to wear. Meta would love to offload major computing functions necessary to support the next Quest model to consumers’ smart devices via the iOS companion app. In fact, it would be nice if all of it could happen via background processes while the consumer’s phone is locked. Conveniently, this is exactly what Section 1.2 would require. It would essentially force Apple to supply the Quest’s AR/VR computing needs. This would solve Meta’s device weight problem by pushing the compute capacity problem onto iOS. Unfortunately for the rest of the ecosystem, Meta would have every incentive to maximize the amount of computing done on consumers’ iPhones, in order to lessen the weight and cumbersome aspects of its own device. This would result in a few major problems, including eliminating compute capacity for other apps to run, overheating of the device and other issues that may arise when an iPhone must accommodate more demands than it was designed to handle, and uncontrolled demands on battery life. Small app companies, in particular, would lose in this scenario because the well-resourced device companies would be allowed to monopolize iOS resources, leaving no capacity and a diminished iOS experience for the rest of the ecosystem.
Automatic Wi-Fi Connection. Unrelated to the device interoperability requirements, Section 3.2 of the proposed measures would separately mandate that Apple make the automatic Wi-Fi connection feature for iOS devices available for any device. iPhone owners know that they can share the Wi-Fi network to which they are connected and the password to that network with one tap to another nearby iOS device. This provides a major convenience and as currently designed, it protects privacy by only making the information available to the devices themselves. In order to facilitate the function, iOS enables iPhone owners to save networks to which they have connected in the past and the associated passwords—this allows them to connect automatically and to share the saved information with nearby iOS devices. This structure allows for the information to be saved and shared among iOS devices without Apple having access to it. A device maker having a record of every Wi-Fi network to which you have been connected is obviously a risky proposition, since that data can illustrate a picture of all of your past whereabouts, from job interview locations to doctors’ offices. Section 3.2 would require Apple to first gain access to the saved information so that it could then create a mechanism to share it with third-party device makers. Forcing Apple to collect sensitive information creates a new privacy risk that runs against privacy best practices, especially in Europe where the General Data Protection Regulation (GDPR) is the law of the land. But even worse, the mandate to make the information available to any device maker—from Huawei to the KGB—is plainly reckless.
Due Process Problems. The Commission says it received responses from 248 developers providing feedback for its proposed iOS measures, but apparently none of them were App Association members. In fact, the Commission never published its outreach to stakeholders and never made the App Association aware of its outreach seeking to learn developers’ views on its extreme interoperability implementations. Here, it is possible that the Commission reached out to specific developers it knew would support its conclusion that Apple must take measures that are technically infeasible and harmful to their business prospects. Ultimately, the Commission did open up the proposed measures to public comment on December 19, 2024, closing the comment period on January 9, 2025. This short comment period over the holidays, when most in the European Union were not at work, provided rather limited opportunity for parties to comment in a detailed manner on wide-ranging proposals. The message to the marketplace was that opposing views are likely too little too late.
AirPlay Interoperability. Section 2.3 would eliminate the ability for Apple to verify the security features—including honoring digital rights management technologies—of a third-party device when connecting. Streaming pirated content could be much easier under this measure, breathing life back into an embattled market for now-infamous Kodi boxes. Similarly, hamstringing iOS’ ability to secure communications between third-party connected devices and iPhones creates unnecessary and completely avoidable new risk surfaces for bad actors to exploit.
Ultimately, DMA is the law of the land in Europe. It is unlikely that we will see the statute itself completely or substantially repealed anytime soon. But it is not too late for other jurisdictions to sit up and take notice of how harmful and costly its essential facility-style mandates are, especially when interpreted strictly, as the Commission has done with its proposed iOS interoperability measures. In this instance, the Commission’s mistakes are two-fold. First, the Commission erred in adopting the DMA in the first place, causing innovation to flow around the European Union (EU) like a pothole on a busy highway. Second, even DMA’s statutory provisions stop short of requiring the Commission to banish Apple from the driver’s seat of its own operating system. The fact that it proposes to do so here could steer iOS and its developers and users headlong into the ditch.