To Apple Inc, via Mehrnaz Boroumand Smith

Partner, Kilpatrick Townsend & Stockton LLP

By email

Interoperability request on OS level under EU DMA

Introduction

Theses

Interoperability requests

Software signing

Current design

Request

Proposed solution

Push notification sending

Current design

Request

Proposed solution

App attestation

Current design

Request

Proposed solution

Mobile Device Management

Current design

Request

Proposed solution

Cloud device backups

Current design

Request

Proposed solution

Access to hardware sensors

Current design

Request

Proposed solution

App usage surveillance

Current design

Request

Proposed solution

App notarisation

Current design

Request

Proposed solution

Just in time compilation

Current design

Request

Proposed solution

Ease installation of alternative marketplaces

Current design

Request

Proposed solution

Market control, customer profiling and surveillance

Operating system level

Marketplaces level

App level

Profiling and surveillance

Epilogue

Introduction

Apple Inc, as designated gatekeeper for iOS operating system, according to article 6(7) of Digital Market Acts, shall:

The gatekeeper shall allow providers of services and providers of hardware, free of charge, effective interoperability

with, and access for the purposes of interoperability to, the same hardware and software features accessed or controlled via

the operating system or virtual assistant listed in the designation decision pursuant to Article 3(9) as are available to services

or hardware provided by the gatekeeper. Furthermore, the gatekeeper shall allow business users and alternative providers of

services provided together with, or in support of, core platform services, free of charge, effective interoperability with, and

access for the purposes of interoperability to, the same operating system, hardware or software features, regardless of

whether those features are part of the operating system, as are available to, or used by, that gatekeeper when providing

such services.

However, interoperability request form, located at https://developer.apple.com/support/ios-interoperability/ requires requester to comply with this term:

Your Apple Developer Program membership must be in good standing and have entered into the current terms of the Apple Developer Program License Agreement.

It directly violates article 6(7) of EU DMA, as participation in this program requires payments from $100 to $300 per year.

This is why this interoperability request is being sent to Apple via a known email address and to the EU DMA commission as well, so all parties will have full information on file. We do not intend to enter the Apple Developer Program or sign the Apple Developer Program License Agreement, as we are not Apple developers (we are just developers like anyone else) and Apple Services are not required for our marketplace to be functional.

We are an EU-based IT company, that develops an app store for devices that are running Apple-branded operating systems, requesting device and operating system manufacturer, Apple Inc, to provide an interoperability on operating system and hardware level for our app marketplace platform.

Our app marketplace platform located at https://appdb.to works completely independently from Apple Inc for over 10 years, and is not using Apple App Store services or Apple proprietary software.

Considering the nature of our marketplace, we treat ourselves as an independent competitor for Apple’s App Store on operating system level, as we provide a set of APIs https://rtfm.dbservices.to/#/services-and-features/overview and services that should be interoperable on the same level as Apple’s own app store.

As well as Apple, our top priorities are customer security and safety, so our platform is designed to keep our platform data, app data, customer data separate from any Apple’s platform or services data.

With all the difficulties which we dealt with, we would like to shed some light on the current situation, on existing vendor and platform lock-ins, limitations of a market, unfair competition and unprecedented surveillance that is used by Apple Inc in their operating system, so EU Digital Market Act commission (and the rest of the world) may take appropriate measures.

Theses

Apple Inc, while implementing EU Digital Market act, used the worst practices, in fact, technically changing nothing in the app distribution system. Apple Inc, with their published implementation, still is the origin of every app that will ever be distributed on Apple operating systems, still in control of the whole market and setting monetary and other requirements for independent businesses, e.g. section 2.1.A of Alternative Terms Addendum for Apps in the EU.

You must either:

o Provide Apple with a standby letter of credit from an A-rated (or equivalent by S&P, Fitch

or Moody’s) financial institution in the amount of EUR 1,000,000 according to the

instructions specified in the Apple Materials, and maintain that standby letter of credit as

long as Your Alternative App Marketplace (EU) is in operation; or

o Be a member of good standing in the Apple Developer Program for two (2) continuous

years or more, and have an Application that had more than one (1) million First Annual

Installs on iOS in the EU in the prior calendar year.

Apple Inc defines an alternative marketplace as (https://developer.apple.com/documentation/appdistribution/creating-an-alternative-app-marketplace/ ):

An alternative app marketplace is an iOS app from which someone can install other third-party apps. To create a marketplace, fill out a webform that outlines the qualifications. If approved, Apple enables a code-signing entitlement on your account to distribute your marketplace app on the web. Apple also provides you with a framework that facilitates the secure installation of apps that your marketplace distributes.

However, their own AppStore is not an App - it is a set of services, including accounts, backups, sync, purchases, subscriptions and much more. And it is not a store - it is an app renting platform, as, according to App Store EULA:

Apps made available through the App Store are licensed, not sold, to you…

Scope of License: Licensor grants to you a nontransferable license to use the Licensed Application on any Apple-branded products that you own or control and as permitted by the Usage Rules.

Which means that customers do not own the content that they purchased. Such content can be removed at any time by Apple’s sole decision, which puts customers in a disadvantageous position. There are lots of examples of not available software, e.g. game Infinity Blade, that is not available for people that purchased it a long time ago.

It also violates EU laws: https://ec.europa.eu/commission/presscorner/detail/en/CJE_12_94

Apple forces every new player of a market to use the same sales model, which is not fair.

Currently Apple perverts the definition of alternative marketplaces and forces its developers to use their set of APIs and services, breaking the chain of trust between independent marketplace owner, their customers, acting as man-in-the-middle. However, it is not necessary or required to use Apple-provided service APIs to build an alternative marketplace with its own set of services. Furthermore, by being man-in-the-middle and forcing “alternative marketplaces” to use Apple’s APIs and services, they also force independent businesses to pay so-called “Core Technology Fee” (4.1. Core Technology Fee section of Alternative Terms Addendum for Apps in the EU) and additional fees from every purchase that were made inside apps that weren’t developed by apple and should be distributed outside an app store.

Appdb does not use Apple any Apple platform services of their App Store or App distribution. Our customers currently are being forced by Apple to use Apple Development membership in order to install apps to their own devices.

Appdb and apps that are distributed via appdb are designed to be separated from Apple Services and apps that are distributed via Apple AppStore and user data of such apps.

Each app that is installed via appdb has its own storage for data, and appdb can manage only apps that are installed via it.

Appdb works via publicly available Mobile Device Management APIs since their foundation in OS X in the early 2010s. However, sometime between 2010 and 2024 Apple Inc has locked these APIs usage (but not protocol or APIs itself) via their “MDM vendor approval process”, forcing companies to pass Apple-defined criteria (like having more than 50 employees), limiting competition and controlling the market in this area.

Following our commitment to build a secure, safe and truly independent app store, we are making these interoperability requests on operating system level (iOS, iPadOS), as Apple is considered as a gatekeeper by EU DMA Commission; describing the current Apple model, how it is implemented, how Apple controls it, how it violates EU DMA and a suggestion for real implementation of such interoperability.

It is mandatory to separate operating system APIs and primitives (e.g. URLRequest in iOS SDK) and Services APIs (e.g. SKPayment) that are bundled together inside the iOS SDK.

Currently Apple ensures everyone that it is one unbreakable package, but this is not fair, as Operating System APIs can work without any Apple Service involved, while Services APIs require communication with Apple servers and can not work without them.

Interoperability requests

Software signing

Current design

Apple is a gatekeeper for software distribution on iOS (even with current EU DMA “compliance” - origin of any installable app is still Apple). Developers themselves can not create installable applications without being forced by Apple to use their Services and pay $100-$300 for it.

Current Apple-designed software distribution is breaking the trust chain between developer and end customer. It requires the user and the developer to create an account in Apple systems. Apple takes over an app and signs every app with just one certificate, that is used for All apps that are available on Apple App store. This approach reduces actual security, as every malware that has passed Apple human review will stay on the device forever once installed, as they can not revoke one certificate that is used for all the apps. There were various precedents of malware inside the Apple app store, so relying only on human verification and lock-in is actually “security through obscurity” which is designed to force users and developers to register Apple IDs and use Apple services, as no alternatives are provided. We believe that every person should be able to install and build applications without usage of Apple services. It is not required when using appdb, so technically it is possible, but at the moment Apple is a gatekeeper for this.

In every other operating system, software can be installed without creating additional online service accounts or logging in to vendor-supplied services. Software trust chain is visible and trusted from end customer to a developer, e.g. windows installation dialog, where developer is being displayed:

In Ubuntu, signing is done via GPG keys,

On Android it is done via certificates as well:

All of these digital signatures are coming from developers and operating systems are installing unmodified versions of applications, establishing a trust chain between developer and end customer. Updates of an app can only be installed if signed with the same certificate or/and key.

We believe that the model of software signing that is used in Windows is the best, as it allows developers to use hardware keys and HSMs (even FIPS-compatible) to securely sign their software, plus each certificate can be easily revoked by the developer itself or certificate authority.

Verification (additionally, extended verification) of developers is done independently by trusted CAs.

We have released software that allows developers to sign applications for Apple-branded operating systems with usage of FIPS-compatible HSMs, ensuring best-in-industry security and safety: https://github.com/appdb-official/appdb-build-tools

If developer wants to distribute an app without Apple in the middle and any modifications and resigning it’s own work, Apple issues such certificates to developers or user, but they can be used to sign apps and deployed only on a limited number of devices, forcing developers to use Apple app store to distribute an app; and providing no alternatives, using their control over iOS to limit independent competition and lock developers inside their service platform.

Additionally, Apple can (Paragraph 10 of Apple Developer Agreement)

Apple may terminate or suspend you as a registered Apple Developer at any

time in Apple’s sole discretion.

And there were multiple blatant agreement terminations for developers like us (just for unpleasant questions), or Epic Games (for 3rd party payments inside an app), Kaskpersky (for developing a parental control app that was replaced by Apple’s own implementation). After termination, there is no alternative provided by Apple, so their monopoly power is used to restrict access of an independent developer to a market.

Request

We request Apple to allow apps that were signed with code-signing certificates from globally recognised trusted CAs to be installed on iOS and do not force users to create or use apple ids to install apps.

Proposed solution

Modify trust verification algorithm of Apple-branded operating systems in order to allow software that is signed with code-signing certificate from globally recognised trust authority to run.

Push notification sending

Current design

Apple is a gatekeeper for push notifications sending to apps that are running on iOS.

Sending of push notifications requires the developer to purchase paid apple developer program membership for $100 per year. Apple provides no alternatives for this service.

Request

We request Apple to allow services from developers or/and marketplace developers to send push notifications to apps that are installed from/via them. We have developed our own push notification service https://pushrelay.dbservices.to/v1.0/spec/ , which currently relays to Apple systems due to lack of interoperability.

Proposed solution

Introduce new payload into configuration profiles that configures a second push notification server that device will be connected to in order to receive push notification. Publish documentation of push notifications protocol.

App attestation

Current design

Apple is a gatekeeper for app attestations. These APIs are bundled inside iOS SDK, and Apple uses their keys and certificates to attest apps. This functionality requires the developer to purchase paid apple developer program membership for $100 per year. Apple provides no alternatives for this service.

Request

We request Apple to allow app developers to attest their apps independently for free. We have developed our own app attestation service https://attestrelay.dbservices.to/v1.0/spec/  , which currently relays to Apple systems due to lack of interoperability.

Proposed solution

Introduce new operating system level APIs that allows app developers to trigger app attestation from server, sends attestation data directly to app developer server, without usage and lock-in to Apple Services APIs.

Mobile Device Management

Current design

Apple is a gatekeeper in mobile device management. Apple disallows companies with less than 50 employees to develop device management software, approves every company manually, requires companies to pay $300 per year to be able to do this - this is unfair competition, market limitation with usage of monopoly. We believe that any company should be able to develop management solutions for iOS, like it is done for Windows or Android (various open and closed-source software).

Furthermore, Apple forces companies to use Apple-provided “managed Apple ID” for MDM solutions, for example, MDM enrolment without managed Apple ID is blocked on Apple Vision, it is “by design”.

Request

We request Apple to stop controlling the market and allow every developer or company to use MDM APIs for free.

Proposed solution

Together with push notifications interoperability, allow 3rd party push notification servers to be used in MDM to send commands to devices.

Cloud device backups

Current design

Apple is a gatekeeper in cloud device backups. Every iOS device app data can not be backed anywhere over the network, except Apple’s iCloud. This extends to mobile device management solutions, where there is only option to backup app data is to register “managed apple ID” ( https://support.apple.com/guide/apple-business-manager/use-managed-apple-ids-axm78b477c81/web ) - Apple forces customers and companies to purchase space in their iCloud service, providing no alternatives. Furthermore, storing corporate or any other user private data in Apple’s premises may increase security risks if Apple ID will be compromised.

Request

We request Apple to introduce APIs for per-marketplace, per-app, per-user data backup, so developers may build their own backup solutions for their apps; remove vendor lock-in to Apple IDs for Accounts that are required for School, Company or Marketplace setup via Settings app.

Proposed solution

Introduce new payload into configuration profiles that configures backup server URI. Introduce new push commands that allow server or developer to schedule data backups that later will be pushed by device to a server. Introduce iOS interfaces and push commands for backups restore process. Introduce open documentation for configuring services accounts on devices, like it is done on Android, for example.

Access to hardware sensors

Current design

Apple is a gatekeeper in accessing hardware features, sensors and identifiers.

iOS does not provide APIs to access device hardware information or features like (for example):

  • Limitation of write ability of NFC module.
  • Lack of receiving GNSS signals from the GPS module.
  • Lack of APIs to determine if a device has original Apple components or not.

Request

We request Apple to open access to hardware information, hardware attestation information, raw hardware data feeds.

Proposed solution

Introduce new APIs in SDKs or/and provide documentation.

App usage surveillance

Current design

Apple is a gatekeeper in app usage surveillance and allowance. Every app that is signed by the developer is being checked by Apple on their servers upon every launch with a decision to allow the app to launch or not, instead of verifying validity the certificate of app signature, like it is done in any other operating system. Apple collects app identifier, developer identifier, launch time and other information and gathers unprecedented amounts of data for more than 34 million people (registered apple developers and their testers). There is no option to disable this in the operating system. Other companies or marketplaces can not access this information.

Request

We request Apple to allow end users (customer or developer) to opt-out from any data collection for app usage or eliminate such excessive data collection in favor of real privacy and real security.

Proposed solution

Introduce new payload into configuration profiles and setting inside iOS built-in settings app that disables data collection by Apple. Publish transparency report for data being collected, how is it used and create a service that allows users to delete already collected information.

Or remove such data collection from future releases of iOS.

App notarisation

Current design

Apple is a gatekeeper in app notarization. Every app that a developer wants to run should be additionally notarized by Apple (while it was already signed by the developer and chain of trust is already established). This additional measure, alongside an established trust chain between developer and end customer, is designed in theory to increase security. However, usage of this notarisation requires developer to pay $100 yearly and brings nothing but removal of manual user approval of an app in Security settings of an operating system. Developers are forced to pay this fee just to access this service. For example, a concurrent solution, Windows Smart Screen works without any payments and bundled into the system.

Apple is not an antivirus developer, so such notarizations may be done by, for example, antivirus companies, so the end user may be sure that the app contains no malware.

If implemented correctly, a full chain of trust between developer and end user implements notarization fully. For example, launching software that is signed with Extended Validation code signing certificate on Windows does not require any notarization. For other software, Windows SmartScreen service has warning (not blocking) functionality.

Request

We request Apple to notarize apps without requirement of payments from developers or allow other parties to notarize software as well.

Proposed solution

Open notarization service for anyone for free to bring real security. Publish technical documentation of generation of notarization tickets, allow marketplaces and/or worldwide-trusted parties to generate their own notarization tickets.

 

Just in time compilation

Current design

Apple is a gatekeeper for just-in-time compilation apps. Every app in iOS that requires JIT compilation of code inside belongs to Apple (e.g. Safari browser). They are providing no ability to enable JIT inside any apps that are provided by other developers. Enabling JIT in apps may significantly improve their performance (e.g. browser engines or emulation software). Such an option may only be enabled by developers for debugging of applications only via wired connection and usage of Apple-owned developer tools. There are no other alternatives provided by Apple, access to JIT in release versions of 3rd party apps is not possible and locked.

Apple gains a performance boost in their own software by using their control over iOS and placing  3rd party developers in disadvantageous positions, making their software work slower than it could.

Request

Force Apple to allow JIT in every app that requires it.

Proposed solution

Force Apple to allow JIT in every app that requires it.

 

Ease installation of alternative marketplaces

Current design

Right now installation of alternative marketplace is done by multiple actions, by creating an Apple ID, by visiting device settings, approving everything, visiting back, installing not necessary marketplace app, installing apps from it. This is counter-intuitive and designed especially to keep customers in the current Apple ecosystem.

There should be no Apple-provided services involved in the design of alternative app marketplace, nor Apple accounts (from developer or customer side) required to set it up.

Request

Our marketplace can be installed via one profile installation in settings, however, profile installation comes with multiple warnings saying that “administrator will take control over device and will control apps and data” and other statements that make customers believe that it is insecure.

In fact, these statements relate only to apps and settings that will be installed with usage of this profile (marketplace), without any interference with Apple app store apps or services, there is no mention of this during profile installation.

This is unfair and a shadow practice designed to keep customers in the Apple ecosystem.

We request Apple to change the wording in marketplace profiles and allow users to install multiple maketplace profiles.

We request Apple to change marketplace installation method, so it can be installed from a website without interaction with Apple Services (Apple ID, App Store, etc) - so marketplaces can work without usage of any Apple Services. This is technically possible and this is how appdb works now.

Proposed solution

Change wording of profile installation, explain to the users during profile installations that all warnings are related to marketplace-installed apps only.

Introduce specific marketplace-type MDM profiles.

Introduce an ability to install multiple marketplace profiles.

Market control, customer profiling and surveillance

Apple, as a monopoly, forcibly locks customers and developers in their ecosystem by using not necessary services; and using their monopoly power to limit competition in these areas:

Operating system level

Boot loading sequence on Apple-branded mobile hardware is locked. There is no possibility to develop another operating system for Apple-branded hardware or boot an existing one. Apple provides no alternatives.

Marketplaces level

Apple solely controls services availability in iOS and not allowing anyone to create an alternative independent app marketplace with its own set of APIs and services. Apple provides no alternatives. Their “compliance” with EU DMA is in fact just a rebranding of their App Store, as every installable app that is being distributed via “alternative” marketplace still originates from Apple, requires Apple accounts and Apple is still gatekeeping in the worst scenario.

App level

Apple takes over ownership of an app by resigning it and adding additional undocumented features, breaking the trust chain between developer and developer’s end customer.

Profiling and surveillance

Apple has developed unprecedented analytics and surveillance techniques inside their mobile operating system, including every app launch tracking. These features can not be disabled by user or developer. Apple provides no transparency reports or ability to delete collected data. Investigation of such behavior is difficult because of, again, Apple’s control over the app distribution process. All this information alongside with information that may be collected by Apple in developers apps by usage of digital signature replacement and ownership taking; adding of additional features; is making Apple the largest user data holder and profiler.

We have tested it - upon requesting the copy of the account data via GDPR there are no traces of such data included in the copy.

Epilogue

We believe that one company can not dictate to another company what to do and how to do it; and it is not the company's business what customers are doing with their own devices and how they use their devices. Real independent competition drives markets forward and brings lots of benefits to end customers. And even if one company has created a market, it needs to give equal opportunities for all players, without taking control over it.

Ehitajate tee 110, 13517, Tallinn, Estonia

AYSA OÜ

Registry code: 14471074

Interoperability team

Concat person: Aleksei Borodin apple-dma@dbservices.to

Dated 27 Nov 2024