Apple/EU DMA Compliance Workshop whisper-generated transcript March 18 2024

apple_eu_dma_compliance_workshop_whisper_transcript.txt

Good morning everybody.

I hope you are ready to start.

We still still new participants entering into the room but I think we can start.

So welcome to everybody to our first DMA compliance workshop after compliance day.

So today's edition is with Apple and thanks a lot to Apple for coming here today to explain and discuss our DMA compliance solutions.

Your DMA compliance solutions as well as to all interested parties here in the room and also online.

So in addition to the many participants in the room we also have many participants online.

The numbers are in the hundreds which shows that there's a great interest and also we are looking forward to having today's meeting to here Apple present its solutions and also here feedback from all of you in the audience online and offline.

So as a general scene setter in September 2023 you remember we designated six gatekeepers and the DMA provides that the six gatekeepers subsequently had six months to adopt measures to comply with all obligations and the gatekeepers will probably agree that this preparation time towards compliance has been very intense.

The deadline to comply was on 7th March and the gatekeepers are now under a legal obligation to comply.

So it is time to take stock on the compliance measures that have been adopted.

The gatekeepers have published a non-confidential version of their DMA compliance reports and they will present today and also the others during the rest of the week what they have done to comply.

You may also remember that somewhat more than a year ago we organized the number of pre-compliance workshops last year ahead of the first designation discussions to discuss possible compliance measures in view of the requirements.

Those discussions were very helpful to us and we hope also for the gatekeepers to understand better the perspective of the beneficiaries of the DMA's rules.

Today we will discuss actual compliance measures with obligations that have been become applicable.

Our objective today is to understand better apples choices in creating its compliance solutions and enable third parties and beneficiaries to ask questions and clarifications.

We firmly believe that the views of the third parties and the beneficiaries are essential to assess effective compliance with the DMA.

To this end we have also encouraged gatekeepers to reach out to stakeholders ahead of the compliance deadline to seek feedback and we know Apple has done that.

The reason is that we want to achieve compliance with the spirit of the DMA not just with the letter.

This means that the compliance solutions need to be effective and deliver fair opportunities for business users and choices for end users.

To make sure the digital markets become fairer and more contestable.

So our teams as you know are assessing apples compliance reports and more broadly the compliance solutions offered by Apple.

Today however is not the right time for the commission to give its use.

Today we want to hear from the gatekeepers, from businesses and from users.

So we want to hear from you.

For this reason we will keep our role to moderating and listening instead of making preliminary statements of final conclusions.

We think it is important to have a transparent and constructive discussion and today is really just the start.

We encourage all gatekeepers to keep seeking feedback, to provide recommendations, to clarification queries and engaging with third parties also when the commission is no longer in the room.

Should I do the whole?

Okay.

So then as you can see and I understand slides are now being presented.

So today is divided yes in four subsections to discuss apples compliance solutions relating to the obligations under the DMA which are most relevant to Apple.

The first session will focus on Article 6 III DMA which contains provisions on choice screens and default setting.

The second, given the importance, the longer session will focus on Article 5 4, 6 4 and 6 12 which relate to the App Store and App Distribution on iOS.

After a lunch break we will discuss 5 7 and 6 7 DMA which deal with interoperability and tying.

And finally as the last session we have foreseen a discussion on the data related obligations.

These are 5 2 6 9 and 6 10.

Now I will end with the rules of engagement but they are probably the most important part of this introduction.

So as I said the goal of today's workshop is to foster a dialogue that is constructive and result oriented.

We're not interested in explanations, accusations or fights.

We ask all the participants to bear this in mind when they are presenting and when they are asking questions in the room or online.

You can see the rules of engagement in the slide.

Our moderators will remind us of them throughout the day to make sure they are respected.

I would just like to make a few broad remarks.

Today should not be about looking into the past and we are not here to discuss previous proceedings and the competition law.

We also want to keep the discussion constructive, factual and professional so that it can meaningfully feed into the regulatory process.

The Commission will moderate the discussions.

The Commission's role will be to steer the discussion and relate questions and views from the online audience.

The event is to hear stakeholders.

This event is to hear stakeholders feedback on the concrete compliance solutions that are presented and the Commission will neither provide legal interpretations nor take any positions today.

Also questions should be DMA specific and not relate to issues outside the scope of the DMA.

Given the number of participants we may not be able to take all questions and comments.

In case you do not have a chance to ask your question today, we encourage you to reach out to Apple.

If you have any observations that you would like to share with the Commission, you can send them to our general DMA email address which is on the slide or on the website.

You can also provide feedback and questions through Slido which will be part of the transcript of the meeting.

When intervening, you should keep in mind that the event today is public and you should therefore refrain from sharing any business sensitive information.

It would also be good that you mentioned your name and the company or organization that you are representing.

Now just as a brief transition into the real start of the meeting, you see on our side our managers Lucia Bonova and Luca Agouti.

You see here representatives of Apple who I think will present themselves on this side the other two managers Thomas Kamler and Filomena Kiriko and my co-director, Albert Obakiga and myself as you know director from DG Connect.

I think with this I would like to hand over to Lucia to the next meeting.

Thank you Rita.

Good morning.

My name is Lucia Bonova and together with Luca Agouti, we will be moderating today the workshop and leading you through the sessions.

As Rita already announced, we have four blocks of roughly one hour and a half, two hours.

They are all structured in the same way.

So there will be a very short presentation by the Commission of the Relevant Provision.

So it will be really essentially focusing really on the text of the provision.

Then Apple will present their compliance solutions and then we will have a Q&A session where you will be invited to provide feedback or ask questions.

The good news is that all the sessions are separated either by a coffee break, the coffee, manage the expectations, but okay coffee break and or lunch.

And as Rita said, very important thing is the rules of engagement.

You all have them on your desk for participants online.

They are now being projected.

We will also repeat them each time at the beginning of each Q&A session so that we make sure that if people come in that everyone is aware how we would like to run the day.

And maybe the last thing is that you've seen from the agent that the workshop does not cover all the obligations.

If you have any comments, suggestions, feedback on compliance proposals on these other obligations, please do not hesitate to share them with us in writing via a submission.

Now I propose maybe that the Apple team introduce themselves and then maybe we can start.

Great.

Thank you.

First let me just say Rita and Alberto, thank you very much for arranging this and setting a tone throughout this process of constructive engagement.

I will echo Rita's points at the last six months and really frankly the last 18 months have been incredibly intense both on our side but I also recognize on the commission side and your teams have approached this at all times professionally and really appreciate the tone you've set from the top.

And of course working with Lucia, Luca, Thomas, Filomena and dozens of others, some of whom I see in this room over the last 12 months, I'm very appreciative of your efforts.

My name is Kyle Landier.

I am Apple's vice president of Products and Regulatory Law.

I've been leading our efforts to engage with the commission even prior to the formation of the DMA and through the enactment and obviously implementation, developing Apple's compliance plans, some of which we'll talk about today.

I'm joined by two of my colleagues and I'll allow them to introduce themselves but before I do, I also want to acknowledge, you know, this was an effort across Apple involved hundreds of people.

Lawyers, yes, of course, but also engineers, business people and economists and so it was an incredible effort and some of those teams are represented here today.

We have members of our engineering team here, we have members of our DMA compliance team here, we have members of our DMA regulatory engagement team here.

So it is a true team effort.

So let me allow Brendan McNamara and Gary Davis who will be joining me today in terms of talking through some of the plans and answering questions to introduce themselves.

Good morning.

It's nice to be here with all of you.

As Kyle said, my name is Brendan McNamara.

I'm director of competition law and policy at Apple.

And I've spent the last 12 months focused on the DMA working with the business and engineering teams Kyle just referred to on how Apple is going to comply with this law.

Good morning.

I'm Gary Davis.

I'm Apple's data protection officer.

Every day my focus is on protecting users and their personal data and I know that's a goal that the EU shares as well.

I've been working very closely with the team developing and implementing our DMA compliance plan to try to make sure that what we're doing is everything to ensure that we protect the privacy and security of our users as we comply with the DMA.

And I look forward to talking about a lot of that as the day goes on.

Thank you.

Thank you very much.

So I propose we start and we will start the first session dealing with Article 6 free and choice screen and default settings and Luca will introduce the topic.

Good morning everyone also from my part.

So the first session is about compliance with the Article 6.3 of the DMA.

Article 6.3 consists of three main provisions to enable consumer choice.

So first and usual shall be able to easily uninstall any software application on the operating system of the gate keeper with the exception of the software application that are essential for the function of the operating system or of the device and which technically cannot be offered by a third party.

Then the second provision is about default settings where end user and user shall be able to easily change the default settings that direct or steer the users to the product of the gate keeper.

And this applies to the default settings of the operating system of the virtual assistant and of the web browser if they are designated.

Finally to further enable consumer choice and user should be prompted with a choice screen by which they should be able to choose from a list of the main available provider.

The lines are designed as a virtual assistant or the web browser if these services have also been designated.

In the case of Apple this means that Apple has to show a choice screen for the choice of the browser on Safari because Safari has been designated.

Now I will leave the floor to Apple to present their compliance solution with the Article 6 pointer.

Alright, before we get into the specific topics for this session I'm going to kick it off by setting the stage from Apple's perspective.

I want to share some insight as to how we approached the DMA over the last 18 months.

To begin with we sought to balance a number of different interests.

Of course the starting point was ensuring that we complied with the law.

However as we all recognize there is no single road to compliance when it comes to the DMA.

Our challenge was to find the road that allowed us to continue to provide the best possible experience for our users.

We're proud of the ecosystem we have built over the last 15 years and our customer satisfaction ratings reflect that.

We are worried that we would lose some of what makes an iPhone an iPhone.

We wanted a compliance plan that was true to the values that have served our customers and developers so well.

One that maximizes user security, privacy and safety to the greatest extent that we can while complying with the law.

Yes.

We were forced to make compromises that may put our users at risk.

But we believe we still offer a best in class experience.

We also thought about how any changes would affect the more than one million developers that create iOS applications today.

And the many more developers that could come in the future.

We greatly value our relationships with developers.

They are an important part of the success story of the iPhone.

And we know many have created successful businesses on iPhone over the last 15 years.

It is incredible to think about now, but developers generate more than a trillion dollars in billings and sales each year in the App Store ecosystem.

And that growth has been accelerating.

We understand why developers, both inside and outside of this room, care deeply about any changes that could greatly impact their businesses.

So we spent months working on plans and thinking through all of these issues.

An important part of that work was the engagement we had with the European Commission and other stakeholders.

Those conversations were helpful as we worked to develop and implement our plan.

Now, as you all know, we rolled out a public and comprehensive plan in January.

We did this because we recognized that there were some very big changes that we had in mind.

Probably the most significant changes in iPhone since it was launched 16 years ago.

And we wanted stakeholders to have the information necessary to understand what we're doing and why, even if they don't agree with every decision we've made.

Since that announcement, we've shared extensive documentation on the changes we have made to iOS, Safari, and the App Store on apple.com.

Nearly 100 documents have been posted by my last count.

We provided a landing page for developers that walks through what we're doing in detail and provides links to still more extensive developer documentation.

We've also included support pages that explain new options, like how to start a new alternative app marketplace, and explain new concepts, like how the core technology feed works.

And they include contractual materials, like the alternative terms addendum for apps in the EU.

We always welcome direct feedback from our developers.

In over the years, we have created many ways for them to connect with us.

From developer forums to our annual worldwide developers conference.

Given the breadth of our January announcement, we wanted to provide developers with even more opportunities to ask questions and share concerns.

We recognize the sheer volume of material we've provided and the magnitude of the changes can be overwhelming.

So we reached out to every single developer in our developer program to solicit their feedback and offered developers the opportunity for one-on-one consultations with Apple to field questions and hear feedback directly.

We also launched in-person developer labs to work directly with developers focused on creating app marketplaces.

These labs in Cork, Ireland put developers in a position to roll out alternative app marketplaces when we released iOS 17.4.

All in all, we spoke to hundreds and hundreds of developers.

We listened to their feedback and the suggestions they have for things we should keep thinking about.

We heard feedback from developers of all sizes, large and small, in all backgrounds throughout the process.

And we've incorporated that feedback where we can.

As you may know, since our initial announcement in January, we have announced a number of changes to our plan.

To tick off just a few, first, we launched the ability for developers to distribute their iOS apps directly from their websites later this spring.

We made changes to the browser's choice screen.

We announced that we will make Safari deleteable from iOS.

And we allowed developers to launch first-party app marketplaces.

These are all areas where we listen closely to what developers, the commission and other stakeholders had to say about our plans.

We look at this as very much an iterative process.

We will all learn more in the coming months and years.

Some good, some bad from this experiment.

With a law of this complex and a plan this sweeping, there are bound to be some unintended consequences.

Hearing from stakeholders is important for our efforts to comply with the DMA and align with our values.

And we'll continue to do that.

It's also critically important to acknowledge the significant engineering work that has gone into bringing these efforts to life.

It took hundreds of people and dozens of teams at Apple spending tens of thousands of hours to accomplish what we've launched.

These changes required a ton of testing in engineering.

We created more than 600 new application programming interfaces and a wide range of developer tools that enabled alternative distribution, new options for processing app payments, and new options for alternative browser engines and much more.

Despite all of our best efforts, none of us really know how this will all turn out.

We don't think the results will be clear immediately.

Change does not happen overnight.

It takes time.

And that's especially the case where the changes occur because of an external push from a regulation rather than innovation.

So we don't know how it'll turn out any more than anyone else in this room.

But what I do know is that we're doing our very best.

Since our announcements, we know many developers are working to take advantage of the new options.

So while it's still early days, we're looking forward to seeing where things go from here.

We're here today to address as many questions as we can.

But we want to emphasize that today's workshop is just one opportunity for stakeholders, including those representing users and developers to communicate their feedback to Apple and ask questions.

The work is just beginning.

So on that note, I'd like to turn it over to Brendan.

Thanks, Kyle, for that overview.

In this session, we are going to provide a summary of what we're doing on the web browser choice screen and defaults pursuant to the DMA.

Let's start with the faults.

And specifically, the ability to select a default browser.

For a long time, Apple has made it easy for users to choose a browser in the Settings app.

Many users have already chosen to set a non-Safari default browser even before the DMA.

They can do it in just a few minutes.

The DMA introduces a new requirement commonly referred to as the choice screen.

Apple thought carefully about how it should implement the DMA's requirement to prevent a choice screen for web browsers.

When iOS users in the EU first opened Safari on iOS 17.4 or later, they are affirmatively prompted to choose a default browser.

Most of you in this room have probably already experienced this.

We have received some questions regarding why the choice screen appears when Safari is launched rather during the setup of the iPhone.

Some people think that that screen should appear when a user sets up their new iPhone for the first time.

Others think that it should appear sometime afterwards.

But the text of the DMA is clear.

The choice screen should be displayed at the moment the end user first uses a designated browser.

And in this case, the designated browser is Safari.

We also needed to determine which browsers would be included on the choice screen.

To make it on the list, of course, an app must be a browser.

Therefore, to be included on the screen, apps must meet certain fundamental criteria to ensure they actually function as a browser, providing the user's primary gateway to the Internet.

The next question we had to address is within the category of browser apps.

What does it mean to be one of the main available browser apps within the meeting of Article 6.3?

We determined that to be eligible, the browser must have been downloaded by at least 5,000 users across all the EU app store fronts on iOS in the prior calendar year.

And if a developer has multiple browser apps, only the developers most downloaded browser will be eligible.

In addition, to ensure that each user is encountering the most commonly used browsers, the choice screen will display the browsers that are popular in that user's member state.

The browsers displayed to the user will comprise that specific country's most popular browser apps for a total of 12 choices.

For example, a user here in Brussels on the Belgian storefront will see the 12 most popular browsers in Belgium.

But those won't necessarily be the same browsers listed in France or Germany or any of the other member states.

So today, a user in Finland will see Vivaldi on their choice screen, while user in France won't.

And users in France and Croatia will see quant on their screens, but users in Germany and Greece won't.

The mythology we are using to determine the main available browsers in each member state is objective and consistent with third party sources.

That is how we determine which browsers should be presented on the choice screen.

Now, let's talk about the choice screen itself.

When a user first encounters the choice screen, they will begin with a neutral education page to inform the users about the choice they are being asked to make.

And users have to make an affirmative choice.

There is no option to skip this screen.

We gave real thought to whether requiring our users to choose a browser before they might be ready to do so would complicate the user experience, since so many customers buy iPhones for the ease and simplicity of the experience they offer.

Ultimately, however, after hearing feedback on our initial plan from the commission, we decided to make the choice mandatory.

Users must make a choice when confronted with the choice screen.

I will also note that the order in which users will see the browsers displayed on the choice screen is randomized.

We have specifically been asked whether Safari received special treatment on the choice screen and we want to make it clear.

Safari is treated exactly the same way as any other browser.

Safari is in no way privileged either by its ordering on the list or by the way in which it is presented.

Each browser could be at the very top or at the very bottom of the random list on the choice screen on any given user's device.

This ensures that all browsers are treated fairly and equally and that user choice is not influenced by a predetermined order.

And that random order will be different for each user.

Any browser, including Safari, has the same chance of being displayed above or below the fold.

And speaking of Safari, I want to note that we will be giving the users the option to delete Safari from their iPhones later this year.

We're proud of the approach we've taken on the choice screen.

We believe it effectively enables user choice by presenting the user with a list of options in alignment with the DMA's requirements while making it easy for the user to understand and make that choice.

After all, ease of use remains a top reason why users choose Apple products and it's something we are deeply committed to.

That is why we have specifically made sure that this choice can be seamlessly made in just a few taps.

Even when the user selects a browser that they haven't already downloaded, this simplifies the installation experience to the benefit of both users and browser app developers.

We've received some questions about the specific design of our choice screen and whether it mimics existing ones out there or how it follows or deviates from various studies on choice screens.

At Apple, we pride ourselves on devising innovative solutions to new challenges and compliance solutions are no different.

The DMA's vision of contestability does not require or even call for all companies to offer identical solutions.

Our approach has been to comply with the law while providing the best possible user experience we can.

And this is why we have -- this is what we have done across the board for the DMA.

As I mentioned, the choice screen is simply a new way for users to exercise their ability to pick a default browser, a choice that predates the DMA.

In addition to that pre-existing default setting available for browser apps, iPhone users have also had the ability to easily change their default mail app for a long time.

We haven't limited ourselves to browser and mail apps.

We've also announced a number of other areas in which users can change default settings.

First, Apple will be introducing a new default control for navigation apps.

This new default for navigation apps is a great example of the iterative process that Kyle spoke of and that we've engaged in since we first announced our compliance plan and reflects our ongoing dialogue with the commission.

Second, we've also made new default controls available for users and settings for app marketplace apps.

Now, with iOS 17.4 and later releases, users can easily choose an alternative app marketplace they have downloaded as a default in settings.

If a user selects an alternative app marketplace as their default in iOS, system install sheets will no longer be displayed when the user seeks to install an app from that marketplace.

In addition, when you are using Spotlight to find a new app, the search results will be populated with apps available for download from the default app marketplace.

Third, we've announced plans to provide users the ability to manage their preferred default contactless payments app through a new default setting and select any eligible app as the default app for making contactless payments.

We're continuing to listen to feedback so we appreciate you all being with us here today.

With that, I'll turn it back to the EC.

Hello, we can then open the floor for the questions.

So we just recall briefly the rules of engagement.

So first of all, when you speak, you will have to state your name and organization both in the room and via Slido.

For those in the room, please use the microphone when you are speaking and release when you are finished to speak.

As Rita mentioned before, the questions have to be constructive, have to be relevant and specific to the DMA discussion and to the article that we are discussing in this session.

And they have to be clear and short, maximum to minutes.

Finally, we ask each speaker to limit to one question or comment for intervention.

So now we will start from the room.

If there are questions, please raise your hand and I'll give you the floor.

Thank you very much.

Orelia Mer from Dept.Go.

I just have a question on the reporting from the choice screen.

So we'll participate in apps to be given the ability to detect when an install is coming from the choice screen.

And then we'll also participants be provided with the number of selections made on the choice screen for their app.

We asked the total number of screen impressions for each country.

Thank you very much.

Thank you.

Perhaps we can collect some other questions.

If there are other questions from the room, please.

I'm Mary Pecoco Oliver from the European Games Developer Federation.

When you are going to exercise your right to change the default setting for app and marketplaces, is there going to be some kind of extra educational pages or warning messages present at this stage or are you going to just rely on the fact that this is already attached to an informed decision made by a user?

Thank you.

Are there other questions from the room?

Please.

Yes.

Hello, my name is Darby Brennan from Google.

I have maybe a three quick observations and requests.

One is that the choice screen is shown to users and an app store and an official shows up.

The question is, is Apple open to automatically downloading the browser application from the choice screen instead of going to that to that app store screen.

The second is that the choice screen is shown when non-Safari browsers are default already on the iPhone and the question is, is Apple willing to only show the choice screen in the circumstance when Safari is the default browser?

And the third is that in the choice screen list, only eight of the twelve browsers show up and is Apple willing to implement forced scrolling so that the user is shown all twelve options before making a selection.

Thank you.

Perhaps we can pause here after this first set of questions and leave the floor to Apple to react to these questions.

Great.

Thank you.

I think on the question around data on about our users and the choice of browsers, I'll defer that one to Gary Davis who could talk a little bit about our approach there.

I think in terms of the question around defaults to app marketplaces, I think we approach alternative distribution as we do so many things that are new to our users from a perspective of let's inform the user about what choices are available to them and what actions are taking place.

And so when a user makes that initial decision, and we'll talk about this a little bit later, to download an alternative marketplace or download outside of the app store, we are going to be presenting information screens to the user and make sure they understand what is happening.

This is a new experience and so we'll be doing that.

In terms of the default, I don't believe, and it's a question I'll go back to the team, but I don't believe we're presenting a further information screen associated with the choice of the default.

At that point, the user has made a decision to use an alternative app marketplace is aware of the potential risks and dangers associated with that and therefore we're not going to present another information screen to the user.

But again, that's of course subject to change and as we see activities in conduct to place in the device in this new world, we may have to change our approach as I talked about.

We're going to be learning a lot throughout this process.

Certainly one of the things we're worried about is that over time we're going to have less reputable marketplaces operating on our platform.

That's not what we've seen thus far and we'll get into that a little bit later.

But it is something that we're keeping a careful eye on going forward and again we're going to be focused very much on the user experience.

The question from Google about the choice screen, I believe there were two or three parts to that, again, as Brendan talked about, we approach this from first and foremost a perspective what is the law require?

And then second, how does Apple communicate with its users?

We've built up a language we've developed a relationship with our users over a very long period of time about how we present choices, how we allow users to make informed choices which has always been critically important to us.

And so I think the first question related to the use of our App Store pages to communicate to a user, full some information about the choice they are being made, we think that's critically important here.

I think it's next to impossible and borderline misleading to have a single line of text, for example, describing a browser rather by clicking on it and seeing what the information disclosures that we provide through the App Store and importantly things like the privacy nutrition label which provides critically important information about a browser and how it may be tracking or monetizing its users, giving that user as much information as possible before they make an important choice around a use of a browser is critically important.

And so that's why we relied on the App Store, at least initially to provide that information.

And of course we're continuing to look for ways that we can continue to inform users about the different pros and cons of different browsers.

In terms of presenting the choice screen, I believe we're only presenting it when it comes to Safari.

Safari is the designated product, that is the product in which we're presenting the choice screen.

We're not going to present the choice screen on other browsers.

Of course we've observed a lot of steering and other sorts of behavior on third party browsers.

I don't think I can open up anything on my iPhone today without being prompted to choose a home or some other browser in my experience of my own device.

In terms of choices, we've presented 12 different choices on our choice screen.

A user must scroll through them before making a choice.

There's an option just to pick one they've got to go through all the way through.

So we've accomplished what needs to be done.

In fact, we're seeing some results already.

I think there were articles out last week about how Brave and Mozilla were already seeing an uptick in increased usage on iOS.

So clearly it seems to be working as intended.

Gary, do you have anything to add on the first question?

I do.

Thank you, Carl.

That subject will form part of our fourth session today.

So this is a little bit of a sneak peek into what we will be discussing there.

We will certainly have data that we will be making available to all browser choices that are available.

We're currently finalizing that.

You should receive contact maybe even today or tomorrow from your normal worldwide developer relations team, and that will start the provision of data.

Like all matters, and I will highlight that again later on, there is a means if the data is not what you expected or you think we might have different data, you can come back to us through those contacts, but also we will have a dedicated feedback assistant process associated with it.

Thank you, perhaps we can have another session of question from the room over there.

I think you have to return them.

My question is how is Apple planning to comply with the obligation of allowing the Apple App Store to be uninstalled without that making the other alternative App Stores breaking due to App Store Connect dependency?

Could you please state your name and...

Sorry, my name is Jaime.

Hi, my Gonzalo.

I work for a Spiegel and alternative App Store, and my question relates to the fact that the alternative App Stores have to install App Store Connect, which makes them depend on the Apple App Store.

Once the Apple App Store is uninstalled, will the other alternative App Store still work?

Because you need to allow the Apple App Store to be uninstalled at 6.3, and the other App Stores have to keep working.

That's my question.

Thank you.

Hi there, John Osby from Open Web Advocacy.

We have a few comments.

We think that the DMA introduces choice screens to remove the default advantage given to the Gatekeeper.

However, for choice screens to be effective, you need two things.

First, an effective choice screen design, and second, to actually receive what Gatekeeper gives themselves when they're the default.

For browsers, Apple places their browser in the most efficient position, visible on every screen page of the home screen.

If a user, like myself, say for example, choose to use Firefox by the choice screen, it will simply be placed on the last available home screen panel.

But then every single time a user unlocks their phone, guess what they will see?

Safari, not Firefox, because Safari will be the one sitting in the hot seat.

So by not placing the user's chosen browser in that location, also known as the hot seat, we believe that Apple is undermining 6.3 and making the choice screen ineffective.

Simply setting the default browser is not sufficient to nullify the advantage the Gatekeeper grants their own browser via their control of the operating system's default setup.

So we believe that the simplest solution to prevent this form of self-preferencing is that when a user selects their new default browser, it replaces the Gatekeeper's browser in the hot seat.

This is the only fair and reasonable solution.

And Brendan, you say Safari is no way privileged.

Aren't you giving Safari a default privileged position on the entire OS which no other browser receives when it's on the hot seat?

Thank you.

Thank you.

Over there.

Alexander Rohovsk, a Computer and Communications Industry Association.

How do you think the success of the compliance measures that you presented today should be measured?

[pause] O'Honeyard from the Google again.

The report from Apple is saying that Safari will be fully debatable by the end of the year.

So my question is what is going to happen to the search default setting that currently impacts spotlight?

Is this setting going to be moved elsewhere?

Or will simply the search is made on spotlight be made via whatever search engine is the default on the default browser app?

Thank you.

Thank you.

And now we can turn to Apple to reply to these questions.

So as it relates to the first question around App Store, today any user can remove the App Store from the home screen and they can set an alternative app marketplace as their default in 17.4 and going forward.

As it relates to App Store Connect, that is a developer tool that we use and we're going to continue to use to manage all the developers who are distributing on iOS, whether it's through App Store or an alternative means, whether that's a third party app marketplace or it's through direct distribution on the web.

It's a critically important tool for us to continue to manage review, whether it's notarization review or a full app review to manage our relationships with the developer community that is using Apple's technology and tools and services to create iOS applications.

And so that will be a tool that will continue to leverage going forward.

In terms of the question around choice screens and the placement of Safari, one of the beauties of the iPhone over the last 15 years is how customizable we've made it.

And so today a user can move icons, they can remove icons, they can do whatever they'd like when it comes to the placement of apps on the home screen.

It's the first time I've heard the word hot seat used to describe any particular feature.

But certainly if a user wants to make a different browser on the first page or on that dock in the beginning, they're able to do so quite easily.

And so what we think we've done overall is to first and foremost comply with the DMA.

As we set up at the outset, there are many roads to compliance.

We were guided first and foremost by ensuring that we've complied with the law and then second, that we did it in a way that was consistent with our values and consistent with the language that we've developed with our users over a very long period of time.

And we think we've accomplished that.

The question in terms of managing how we manage success, that's a really good question.

And I think we're focused on it from a user perspective.

Now it's not to say that we're not focused on the impact of developers, but I think from our perspective first and foremost, we'll be tracking very carefully what's the impact of all of these different changes on the user experience that we've delivered to our customers for 15, 16 years through the iPhone.

And what is their confusion?

Are there new threats?

Are there new risks that emerge?

And so we're going to be laser focused on that question.

In terms of developers, we're likewise going to focus on our business users, developers, others that work with us to make sure that the trusted platform that we've created over the 16 years has created so much value and benefit to the developer community, whether it's in terms of the more than trillion dollars of commerce that we provided, the incredible growth of output that we've seen over the last 16 years.

I mean, it's amazing when you think about it, there were 500 developers in our first year of operating the App Store.

There's now more than a million.

There were a handful of apps in the beginning.

Now you've got more than 1.6 million.

And customers have come to trust the App Store as a way to find those applications.

I think in this new world, we have different choices, different alternatives.

It's going to be more confusing.

And there's opportunity in that, but there's also risk.

And so we'll be carefully monitoring that issue.

In terms of the last question, that's one I actually don't know the answer to.

I'll have to take that one back.

In terms of what's the impact on spotlight if you delete Safari, I will say, the effort to delete Safari is not an easy one.

If you think back to the original iPhone, we built that and Steve launched it by saying it combines three things.

A phone, a browser, and messaging.

And tearing apart, we built the Safari deep into iOS because we wanted to create a mobile browsing experience that would be safe, that would be secure, and that would work.

One of the biggest concerns we had then, and one of the biggest concerns we have now, is around performance.

And so for example, is it going to tax the battery?

Is it going to impact the rest of the device?

And so as we've had to dismantle what was integrated deeply into iOS for the last 15 years and we've built upon it year after year and day after day, that's been a big exercise, huge exercise.

And frankly, we don't know what all the different consequences could be as a result of this tearing apart.

You ask a question around spotlight, I'm happy to get back to you on that.

I just know the teams, and this is one that's required a lot of engineering time to try to think through how do we do this?

Because we never thought of it as separate from the operating system until this point in time.

So it's a big project.

Gary, anything you wanted to add on that?

I don't need those.

No, I think on the spotlight issue, I think the question was if you change your browser, will the spotlight results reflect your change browser choice, I think?

And that is the intent and actually I think Brendan covered part of it in relation to alternative app marketplaces that we have actually looked at those issues to make it just work for users.

So we can now take some questions from Lido from people connected online.

Okay, so I will read the questions.

So we have a question from Agata Hidalgo from Franz Gittel.

Could you please indicate what are the objective third-party sources you use to determine what are the most popular browsers in certain member state?

So that's question one.

Then I have a question from Sophie Dambinski, Ecosia, and another participant.

What percentage of users in Europe have seen the choice screen so far?

So I guess iPhone users we mean.

Then I have a question from Lukas Vyor, from Wiek.

Can developers choose to point to a side loaded download of their app in the choice screen instead to an Estyle via an alternative app store?

And then I take another one, Jonah Bolin from Appearam.

Is Apple open to make it easier for users to set default browser via a system dialogue that can be triggered by a browser app?

So for questions for now.

Sorry, could you just repeat that third question?

I'm not sure if I completely.

The third question.

The third question.

Can developers choose to point to that one?

Yes.

Can developers choose to point to a side loaded download of their app in the choice screen instead to an Estyle via an alternative app store?

I'm not sure it was clear the second time, but I'll do my best.

I know.

Just a messenger.

So as to the first question which related to the criteria that we use to choose the browsers that populate our choice screen in different markets.

We look first and foremost, at least in this initial implementation, at the data from the app store.

And so we looked in each app store in each market and identified those browsers have been downloaded most frequently.

We've also rely on a number of third party data resources, kind of ensure that we weren't missing anything in that effort.

I wish I could recite each and every single one of those.

I'm happy to follow up at a later point in terms of some of the data.

Some of it was researched that was pointed to us by the commission.

We also heard from other sources as well.

I think this is again going to be one of these processes that iterate over time.

In terms of the second question in terms of number of users that have been presented with the choice screen here in Europe.

So we obviously launched iOS 17.4 two weeks ago now.

Apple's track record when it comes to users downloading and installing updates leads the industry.

I mean it's an incredible kind of technological record which is within a couple of weeks you have 60, 70% of users downloading the most recent version.

Within a month, two months you have 80, 90%.

It is incredible.

If you compare it with other benchmarks, the Android ecosystem of course is very, very fragmented and confusing and broken in some ways where you have much less immediate downloads of updates.

So Apple's very leading the effort to kind of get it.

I don't know the numbers right now in terms of the number of users who have downloaded 17.4 here in Europe based on our historical data.

My assumption is probably at least 50% at this point.

I would assume most of those users are using their browser.

But that's an assumption layered on top of an assumption.

But we think it's probably quite high at this point and is probably leading the market at this point in terms of people actually being presented with the choice.

I'm going to try and take this third question.

It seemed like the question was whether if a browser was downloaded outside the App Store, would we include it in the choice screen?

Lucia is nodding and says that's a reasonable interpretation at this point and I'm happy to get clarified later.

At this point, we're focused on the App Store data.

That's because that's been the practice for the last 16 years.

Obviously, as we move forward and as alternative distribution becomes a reality, whether that's through third party app, marketplaces, whether that's because of direct distribution from websites, that will be additional data sources that will have to incorporate as we implement next year, year after, year after.

So I think it's a little bit premature at this point.

I think it's a really good question if I understood it correctly.

But I think it's a little bit premature at this point.

The fourth was default browser.

Lucia, I might ask for your indulgence.

Question four was again. [inaudible] Oh, yes.

The system dialogue question.

Yes, it's Apple Open.

I will repeat.

Is Apple Open to make it easier for a user to set default browser via a system dialogue that can be triggered by a browser app?

My apologies.

I think my brain is still in California time.

So the good news is this afternoon it should start to wake up.

But in terms of this question, in terms of a system dialogue that would prompt a browser, again, I don't think that's something I have a definitive answer to.

Certainly, with all feedback we're willing to listen and take into account.

I will say, again, my experience using my devices, I often see prompts to load alternative browsers, to prompts to set alternative browsers as defaults on my devices.

So to some extent, there seems to be no shortage of ability for third-party browsers to inform users about different choices and to prompt them to make different actions.

Can I please just make a comment for people who are on the slide though that they should put their name in the organization because we are getting lots of anonymous questions and we said we are not going to ask in the room anonymous questions.

So some of them are good.

So if you could introduce them with your name and the name of the organization, thank you.

Okay, we are just a few minutes past 10, but we have until 10/20 for this session, so we can collect some other questions from the room if there are.

Thank you.

Vanessa Turner from the European Consumer Organization.

I had a few questions on the choice screen specifically and then on default settings.

So on the design of your choice screen, I was wondering whether you tested it against alternative designs and if so, what the results showed.

So that was the first question.

The second question prompted by what you just said about the rates of installation of iOS users of updates.

If the majority, 90% of users will have installed 17.4 within one or two months.

Are you planning to share the results of the choice screen with users or the commission to see how that has worked out in practice.

And then on the default setting, I think I heard you say that when an end user sets a default browser, that will cover all access points.

If that's, please correct me if I'm wrong on that.

And then one sort of follow up question to that is when a user having set an alternative default browser as a result of the choice screen, when they go into Google Maps, it seems that the default browser is not used, but that user is prompted to actually consider another browser.

And I was just wondering why that would be.

You can collect some other questions from the room.

They are in the second row.

Hi, I'm League of Someone from the European Banking Federation.

I have a question on the, you mentioned making it easier to select a new default contactless payment app.

So when that is done, does that setting or feature when you select the default payment app?

Does that mean that the double click and face ID are then automatically also selected when you select the new default contactless payment app or in that setting does that have to be done separately?

And then also, if you want, does this also apply if you want to set a new depth default app on your Apple Watch, for example?

Thank you.

Thank you.

Other questions from the room?

Mike Sacks from the App Association.

So I have a question about the spotlight search and the fact that apps in the default marketplace will be shown first.

One of our concerns is copycat apps.

So when an app is published, that is very similar to ours or might even steal our IP.

There is currently a pretty straightforward process to contact the app store and have the app taken down.

But I don't know what the process is for alternative marketplaces and I understand that we're going to discuss that later.

My concern would be that if apps are shown first from alternative marketplaces that maybe app developers need to defensively be present in these alternative marketplaces to make sure that users don't get confused by downloading an app that is essentially trying to steer away users by having very similar graphics and copycat kind of techniques.

So is there anything that is in place to mitigate that situation?

Or should we be concerned about basically confusing users with copycat apps?

Thank you.

Perhaps we take a last question from the room.

Hi there.

John Osway from Open Web Advocacy.

I'm going to continue to focus on one more question regarding the prompt from the operating system regarding the change to default browser.

You mentioned earlier that users are always prompted to change their default browsers.

At the moment, there is no way for browsers to detect if they are the default browser in one-click system to prompt to allow users to set the default browser.

And this is standard on all other major operating systems except iOS.

So on all operating systems you can set your browser to default to anything you want except on iOS.

The friction Apple has added to this process undermines users switching to a new default browser and needs to be fixed in order for them to be in compliance with 6.3 and 13.4.

Similarly, changing the default browser at the moment is quite difficult as well.

Currently, Apple does not have a centralized location to change the default browser in the settings.

Searching default or default browser yields no results in the settings and you can try it right now.

Instead, there is an appropriately placed button in each individual browser settings page.

And astonishingly, Apple has added a custom code to hide the option to change the default browser in the Safari settings.

So if Safari is the default browser and prominently show it in a different browser as default, we had thought that Apple would have fixed such a dark pattern prior to the DMA coming into force.

But in the latest version of iOS, it seems that it is still present.

My question is, is Apple planning on addressing these or not?

Thank you.

Now I turn to Apple to reply.

All right.

Like how each question has multiple sub questions.

So I'm going to do my best to respond to each one.

And if I fail to, I'm sure you'll find me somewhere.

So as to the first questions around, I set the questions from the Biotka Consumer Organization.

So in terms of choice screen, I can say that we work through a number of different versions over the last 12 months to figure out kind of what would be true to Apple's values and our way of working with consumers.

And so part of that was obviously looking at what other third parties were doing.

It was part of it was looking at important work that's already been out there.

But at the heart of it, it was how has Apple communicated choices to its users over a long period of time?

And so that was kind of our core focus throughout.

And so as we tested different designs, we kind of looked to that first and foremost.

That's how we settled on the last one.

In terms of sharing the results of what happens after installations, I think that's an interesting question around that we'll see once we get through this process in terms of what the impact is, what we're hearing anecdotally thus far from some of the public reporting is that users are taking advantage of the choices presented to them.

And particularly with smaller browsers, which we're really excited about, it goes back to why we introduced Safari in the first place.

We introduced Safari because in that time in the early 2000s, the only option was Internet Explorer.

And so we wanted to present by our consumers with a different choice with something that wasn't tied to the dominance of Microsoft.

That's why we introduced Safari when we did and when we've continued to build on it over time.

And so it's great to see in the early days of this choice screen that some of the smaller browsers are getting some traction out there and not following victim to the largest player in the marketplace.

In terms of the default setting, my understanding is that if you change the default, all the default settings should then turn to the new default browser.

Again, as I mentioned earlier, this is an incredibly complicated engineering task that we've been embarked on for the last 18 months.

I'm not going to sit here and say everything will work perfectly in version 1.0.

But we've done our very best to make sure that that's what is supposed to happen on the operating system.

Those of you who work with software every day understand that perhaps the way you design it is not always the way it works out in the wild.

And so we're going to be following that and paying careful attention to what's happening with our system now that we've made some of these changes.

It is a big change for us.

It's a big change for the operating system.

And so if there are issues, of course, having worked at Apple now for 15 years, we have millions of interested third parties who tell us each and every day what they think is working and not working.

So I expect that to continue going forward.

I don't really know anything about the Google Maps example that you provided.

Happy to, after this session, better understand that.

Sounds a bit more technical, a bit more detailed that I'm perhaps prepared to.

I like to think I have a lot of answers, but that one, you've stumped me.

In terms of the question around defaults and contactless payments, you know, once we're in a position to launch, you know, the access to NFC, we will, of course, enable the ability of users to change their default payment app.

You know, in terms of what that means, my understanding, again, I've got it to my earlier point about that.

It's not always clear what happens once it hits the wild.

It's been designed to ensure that the default takes advantage either double click or face ID.

So that should work.

Apple Watch is, of course, not a designated product here.

It is out of scope of the DMA, and thus there's nothing changing in terms of the Apple Watch.

In terms of the question around copycat apps and the risks that are posed in this new world, as I mentioned in my opening remarks, this is a very significant risk from our perspective.

We think now that there's options to distribute outside the App Store, unfortunately, one of the outcomes is that you're going to see content that you may not have seen before.

You're going to see apps that knock off copy or offer cracked apps that steal the intellectual property of our developer community.

We know from managing the App Store, you know, we are rejecting thousands of apps for infringing intellectual property each and every year.

This is a real problem, and we know in looking at alternative marketplaces and other platforms, in looking at some of the alternative marketplaces that have expressed interest in distributing on iOS, that they are, some of them do offer, you know, unfortunately, knock off and copycat and cracked apps.

What we've tried to do in our terms, and we'll talk about this a bit later, is, you know, we were prohibited by, to review for this, as part of notarization review.

We very much wanted to do it, but told it was outside the scope of our ability to do so, and it was really a risk that we would just have to live with.

What we've tried to do is put terms in place in terms of distribution outside of the App Store to ensure that third parties have some obligation, but I do think it's going to be a little bit of chaos.

And I think this is an area where, obviously, governmental authorities, both at the commission level and at the member state level, will have to step up and really kind of take a much more proactive approach to protect the intellectual property of developers.

Unfortunately, there's not much Apple can do given the positions that we've been confronted with.

In terms of the last question around the default browser, I think we've covered that at length.

I'm not sure I have much more to add on that point.

Okay, we think in the last five minutes, a couple of questions from Slido.

So a very popular question by Jan Kramer from University of Paso and Sarah, plus other users.

How frequent is the choice presented to users again if they choose Safari as their default on the first time?

Then we have another question from Ecosia, which is asking, right now we cannot detect if our app is default browser on iPhone.

We will enable this.

And when can we expect to learn about selection rates and our app store based choice screens ranking in the future?

So we have five minutes, so I think this should be fine.

Great.

I'll ask Gary to weigh in on the second point around giving an ability to a browser or a browser to track users.

In terms of the first question, the choice as required by the DMA is presented once to users.

Obviously, there's a ton of other ways in which users can choose different browsers, different default browsers if they still choose.

We've worked to make this simple and straightforward.

And we know from the experience over the last couple of years that millions of users around the world choose alternative browsers all the time.

We also know that many of them will choose to make their browser their default one of choice.

That happens all the time.

In terms of what's being required here by the DMA, our focus is on presenting this choice and even more clearly to consumers on the first time you use Safari.

Obviously, there aren't choices being presented when you use other browsers on iOS.

And so we are complying from our perspective with the spirit here.

In terms of a co-seas question around data of installation, Gary, you want to take that?

Yeah, I think it's quite similar to the question we had earlier from DuckDuckGo.

And just to reiterate, your normal worldwide developer contacts will be reaching out today, tomorrow as we gather the data.

This is obviously new data for us, so it's just taken a day or two together together.

And if Apple has the data, we will be sharing it.

That is our bottom line here.

So maybe we take the ones from the slide down.

So we have John von Tettner from Vivaldi.

The choice screen is shown when Safari is not the default, and if the default browser is not amongst the 12, it is not even shown on the list intended.

And then the second question from John Abolin-Opeira.

What will happen if the set default browser will be deleted on system?

How will the system handle the state if and when there is no default?

I'm sorry, I was confused by the first question, so I wasn't paying attention to your second question.

Can you put that one again?

Sorry, the first one was the choice screen is shown when Safari is not the default, and if the default browser is not amongst the 12, it is not even shown on the list intended.

And the second question was what will happen if the set default browser will be deleted on system?

How will the system handle the state if and when there is no default?

Is he on?

I'll get into the advanced placement part of the test.

In terms of the first question, I'm not familiar with the choice screen on iOS being presented on third party browser engines.

The way it's been designed and developed and implemented is to be shown on the first use of Safari.

So I guess I'm a little puzzled by that question, and if that's happening, that's something we should take a look at.

That's not how it's been designed or intended to work.

In terms of the second question, I don't have the answer to that one.

I think that's one that we've now tested the very ends of the limits of my knowledge, and we'd have to get back to you on it.

So there were two other questions from the room.

I would ask you to be very short because we are running out of time.

Thank you.

Thank you.

Coming back to the browser story, when will you add features for browsers to actually detect if there are default and provide APIs to help the user make them default?

Thank you.

Last question.

Hello, the question.

Now that it's clear that Apple would not comply with the obligation to allow the app store to be installed.

The other obligation of 6.3 is about the anti-steering.

There are more than 30 apps pre-installed by default on iPhones, and many of them are Apple owned services, like Apple TV, iTunes and so on.

So, where you plan, yet you are only offering one choice screen for one of these 30, which is Safari.

How are you planning to avoid the anti-steering of the other 30 services?

Well, especially those of them that are Apple owned services from your operating system.

Thank you.

And then we can let the floor to Apple to reply to this question, and then we close.

Sure, as to the first question around the choice screen, 6.3 instructs that we should provide users and present users with the choice screen upon first use of Safari.

And we've presented users with 12 different choices and made that quite clear, providing them with the ability to learn more about each of those choices.

And so, from our perspective, that is what the DMA, both in letter and spirit, requires.

I'm certainly happy to take the feedback about additional APIs and services that Apple can invest in and build in to support alternative browsers.

In terms of Apple's own applications, obviously from the very beginning of the iPhone, we've built a suite of services and applications for our users.

And that really goes to the long-standing heritage of Apple, which integrates hardware, software and services.

We believe this leads to great products and choices for our consumers, and we've always made it possible since the second iteration of the iPhone for them to also use third-party choices and options.

What we've done since that time is almost every single Apple app service and product on those screens can be deleteable.

That was a significant effort on our part as we redesigned our operating system over the last few years.

And now, as I mentioned earlier, we are working to invest in making Safari deleteable as well, which presents some real, real challenges given that it was part of the original design of the operating system 16 years ago.

This is no easy engineering feat for us as we redesigned things.

We do not steer users to any of those apps that we have in place.

We've been very careful about that over time.

We have built in a number of new default choices for our consumers, some of which we've talked about today.

I think if you think about that heritage of Apple building that integrated system of hardware, software and services, it's worked quite well.

I think what's underappreciated though over time is how much we've invested to make iOS incredibly customizable for our users and make it easy for them to make different choices on their device.

Yes, now when you open up an iPhone, it works great right out of the box.

But we also provide the flexibility to allow users to customize their own experience.

So, thanks a lot.

This brings us to an end of this first section on Article 6.3.

We will have a break until 1040, where we will resume on the session 2 on Apple App Store and App Distribution on iOS.

Thank you everybody for the fruitful discussion and if there were some unanswered questions that were not asked, you can always contact the Commission services and we can listen to those questions.

[BLANK_AUDIO] [BLANK_AUDIO] [BLANK_AUDIO] [BLANK_AUDIO] Hello, can you please take the seats?

Thank you in the room.

Session two is about to start.

And something is telling me it's an interesting one.

We don't have Kyle.

No Kyle, no session.

[BLANK_AUDIO] He must have gotten caught.

I'm answering questions on 6-3.

[BLANK_AUDIO] Kyle is back, so we can.

[BLANK_AUDIO] Okay, welcome back for the session two.

So the session two deals with App Stores and alternative app distribution.

So the relevant articles at stake are article 5, 4, 6, 4, and 6, 12.

I will shortly present them.

Then I will hand over to Apple, and then again we will follow with Q&A.

So under article 5, 4, under this provision gatekeepers are required to allow business users free of charge to freely communicate and directly conclude contracts with end users.

In other words, gatekeepers can no longer be called critical information from consumers and impose their distribution channels on business users.

The recital then clarifies that if any remuneration were to be justified, it can only be for the initial acquisition of end users.

The second provision, which we will be at stake in this session, is article 6, 4, DMA.

And under this provision, gatekeepers need to enable on their operating system the installation and effective use of competing App Stores and sideloading of apps from the web.

There are two limited exceptions, if strictly necessary and proportionate, allowing gatekeepers to protect the integrity of the operating system and hardware and the security of apps and App Stores.

Finally, under article 6, 12, access to App Stores need to be provided on a front basis.

So this is the framework of the session, and I will now hand over to Apple to make the presentation.

Thank you.

Hope everyone found some caffeine.

Not to say that the session won't really get the adrenaline going.

I do recognize this session is going to be a bit of a marathon, but at least I hope we can work up an appetite before lunch.

So I'm going to kick things off again by providing an overview of the changes Apple has made to the App Store and App Distribution on iOS.

We're going to peek behind the curtain a bit to walk through our thinking behind these changes and how we see them working for developers and users alike.

I'll start with our approach to alternative distribution.

And then Brendan will talk about alternative payments.

And then I'll take back the mic and talk a little bit about our new business terms.

So as we've talked about, we spent a lot of time and effort figuring out how to comply with the DMA.

We had to consider lots of different interests, the needs of users first and foremost, the needs of developers, and of course, the goals of the DMA.

Our plan reflects extensive input from regulators and stakeholders across Europe.

Of course, we also knew that any plan we landed on would raise questions, and we welcome that.

So in this session, we'll answer some of the questions we've been asked most frequently, since we made our announcements on January 25th.

And we have time at the end of this session dedicated to addressing additional questions from the audience.

So let's start with alternative distribution.

I know this is a topic, it has a great interest to many inside and outside of this room.

And it presented some unique challenges for Apple.

As we explored how to best comply with the DMA's mandate to enable distribution of iOS apps outside of the app store, we were focused on how to best preserve Apple's core values, the things that set us apart from our competitors, and earn us the trust and business of our customers.

We wanted to preserve the privacy, safety, and security of our platform.

For the last 15 years, centralized distribution through the app store has played a critical role in maintaining those values.

And it has been a fundamental aspect of how we compete in a fiercely competitive smartphone market.

To take a step back, we tried to do two things when we opened the iPhone to third party developers over 15 years ago.

One, we wanted to provide access to an innovative platform for any developer, whether a massive corporation or a teenager in her parents' basement to bring their idea to life.

And two, we wanted to do that while minimizing the risks to users that comes with downloading an app from some unknown developer on the other side of the world.

For over 15 years, Apple has invested in the security and privacy of iPhone and iOS to keep users safe with an integrated system of protections.

Installed apps only access what users authorize with features like sandboxing and user privacy controls.

Real people review each and every app through our app review process.

We look to help ensure apps are from a trusted source.

Our free of known malware are checked for privacy and security risks that they work as described and more.

We've done this all while giving developers tools, technologies, and services to help them build high quality apps, reach Apple users globally, and build their businesses.

Our track record speaks for itself.

The iPhone is consistently rated as the safest, most secure consumer mobile device in the marketplace.

There has never been a widespread consumer malware attack on iOS.

Last year in this very building, we talked about our approach to compliance.

We talked about how to comply with the DMA while maintaining our powerful security features, our commitment to defending Europeans' privacy, the tools we provide to protect our most vulnerable customers, including and especially children, and an integrated and intuitive user experience that everyone from a child to a grandparent can use.

And so that's what we've done.

We made changes to app distribution methods to comply with the law and built solutions to maintain these fundamental aspects of iPhone as best we can.

So let's get into the details.

As we announced on January 25th, developers are able to distribute on the app store or an app marketplace.

Of the choices afforded by the DMA, alternative app marketplaces present less risk than direct distribution by developers over the web.

In the weeks that followed, we heard from developers that they wanted the ability to operate first party app marketplaces.

That led us to change the rules to allow developers to operate marketplaces that only distribute their own apps.

I want to repeat that because it's representative of how we've approached this process.

Despite our view of what we need to do to comply, we listened to feedback after announcing our plan in January and significantly expanded the options for how developers can distribute their apps on iOS, along with other changes based on that feedback.

Now, Apple has long been concerned about the risks associated with direct distribution by developers over the web, and those concerns remain.

Although we think the law is clear that we have a choice about the alternative we enable, we were pressed nevertheless to enable direct app distribution via the Internet.

So in response, we have now announced that web distribution will be coming to iOS this spring.

We introduced all of these options for developers in a way that tries to preserve as many security, privacy, and safety protections as possible, regardless of how users choose to get their apps.

Let's start with the marketplace criteria.

Today, a developer that meets objective criteria designed to ensure a minimum standard of accountability can build a marketplace and launch it on iOS 17.4 in Europe.

Operating an app marketplace is a significant responsibility.

It requires making clear statements about any content rules in moderation processes.

Anti-fraud measures to prevent scams, transparent data collection policies, and the ability to manage payment disputes and refunds.

Apple has always taken on this responsibility and the costs associated with it in connection with the App Store.

And the DMA allows us to require alternative app marketplaces and other channels for distributing apps to take similar steps to protect the integrity of the iOS platform.

The end result is a consistent, non-discriminatory set of criteria for app distribution on iOS.

We have built more than 600 new application programming interfaces, including MarketplaceKit, to make it as easy as possible to create new marketplace apps.

We've set up labs at our Cork Campus in Ireland where developers can come to work with Apple experts to support and create their Marketplace apps.

Already, two companies, MobyVention from Germany and MacPaw from Ukraine, have announced that they will have marketplaces ready to launch very soon.

And we have developers working in our labs this week with more to come.

Developers will be able to choose whether they want to distribute in many marketplaces, including the App Store, or can choose to distribute in a single marketplace, whether it's the App Store or an alternative.

No matter what they choose, they only need to submit a single binary to Apple.

Developers can use new distribution tools to easily download their notarized apps to transfer them directly to a marketplace for distribution.

And we've also enabled marketplaces to automatically retrieve developers' apps if that's what developers want to do.

Users can download and install Marketplace apps directly from the web.

And they can then download apps from whichever app marketplaces they have decided to use.

Users can easily select one of them as their default marketplace, and they can change this selection at any time.

Regardless of whether an app is downloaded from the App Store, an alternative Marketplace, or from a developer's website, features like screen time and parental controls will continue to work.

We know that protecting children online is very important to policymakers here in Europe, and it's very important to Apple too.

However, some features will not work the way users may expect them to for apps distributed through alternative distribution.

For example, features like Report a Problem, Family Sharing, and Ask to Buy will not be supported.

The App Store and its commerce system are not facilitating purchases, so Apple has no control over them.

For the same reason, it will be up to alternative marketplaces, or developers themselves, especially for apps downloaded through new web distribution options.

To assist users with getting refunds, preventing fraud, tracking their purchases, and canceling their subscriptions.

So that's the big picture.

I now want to bring Gary into the conversation to discuss some of the risks that these new options create for users, and what we're doing about them.

Gary?

Thank you very much, Carl, and I'm in fact based in that Cork campus in Ireland that Carl has mentioned, and I am celebrating the Irish public holiday for Patrick's Day.

Would you all here today?

So what a great way to do it together.

As you mentioned, we've taken the same approach protecting users everywhere in the world since we launched the iPhone in 2007, using wide-ranging and industry-leading protections against countless TRET vectors.

That includes the App Store, a trusted place where anyone from anywhere can distribute their apps to everyone from everywhere.

The new options we're introducing to comply with the DMA necessarily mean we will not be able to take the same approach to protect users from the risks inherent in finding and installing third-party code on their personal devices.

That is to say, the risks of app distribution itself.

We want to keep offering users the most secure, most privacy-protecting and safest platform in line with what users expect from Apple.

That's why we've designed and implemented new safeguards that will help to protect them as much as we can, while providing them with information about the risks that will remain when sideloading apps.

We've just released an extensive white paper that goes into detail on the steps we're taking in this area.

While these changes will inevitably create a gap between the protections that Apple users outside of the EU can rely on and the protections available to users in the EU, we are working tirelessly to make sure iPhone remains the safest phone available in the EU.

By reducing the risks introduced by these necessary changes, even though we can't eliminate them all.

And one of the most important safeguards we've added to iOS is notarization.

Notarization is a baseline review of all iOS apps, no matter how they're distributed.

It's focused on platform integrity, including security, privacy and safety.

We've based this notarization process for iOS on what we've implemented for Mac apps, but iOS presents different risks, and the iOS notarization, which we've developed specifically for that operating system, reflects those differences.

Notarization reviews for a subset of the app review guidelines focused on maintaining device integrity, specifically on accuracy, functionality, safety, security and privacy.

That will aim to ensure apps are free of known malware, known viruses or other known security threats.

Function is promised and don't expose users to egregious fraud.

During notarization, Apple conducts both automated and human review.

Automated checks use machine learning and years of accumulated data to scan all apps for known malware, known viruses and other known security, privacy and safety threats.

Apple's human reviewers analyze each app and specialists will reject apps that violate the notarization guidelines.

The team launches and runs each app to test whether it works as described and appears to be safe for users.

Because automated review relies on past threats, complementing it with human review is essential, as we try to detect emerging and novel threats.

As cyber criminals become increasingly creative and sophisticated, the human element of our process allows Apple to stay on top of these threats.

And human review is also essential to our effort to stop apps that pose non-software-based threats like fraud.

Or apps that use social engineering techniques to manipulate users into giving them access to their device by pretending to be something they are not.

Human review also helps us identify apps that pose risks to users' physical harm or could damage their devices.

This notarization process also helps us power a new system experience for app installation that shows important, easily digestible details about the app before it's installed, like its name, developer, a description with screenshots and the age rating.

This sheet was designed to give users transparency and control over their apps and help them make informed decisions.

In many respects, it takes inspiration from our privacy nutrition labels from the App Store, which we launched three years ago, and which have significantly increased transparency for users on developer data practices.

Of course, while even human review cannot completely eliminate risk, notarization's combination of automated and human review provides an important baseline defense.

And that's why we're going to be notarizing apps through every distribution method, whether through the App Store, alternative app marketplaces, or web distribution.

Thanks, Gary.

As you said, the baseline review allows us to reduce some of the new risks created by alternative app distribution, even if we can't eliminate them.

But notarization is not the same as the App Store's much more rigorous app review process.

For example, it does not enforce quality standards for business practices and content issues.

For example, we're not going to be looking for illicit content in pornography as part of notarization.

We also won't look at things like how apps market their subscriptions and whether they're using misleading or deceptive marketing techniques, or if apps are pricing purchases at irrationally higher prices.

Of course, other app marketplaces can decide to create their own policies, and at a minimum, must figure out how to out their own ways to stop illegal activity.

At last year's workshop, I mentioned that app review lets us identify and block intellectual property violators like copycat, pirated, and cracked apps.

In 2022 alone, we rejected more than a thousand apps for those reasons.

Over the last 15 years, we've seen and stopped apps like Among Us, a space journey, which ripped off the real popular game Among Us.

Apps like Ad Manager Metacreator, which impersonated the real Meta Ads Manager, and apps like Spotify Music Premium and Premium Spotify Music Unlimited, nefarious copycats to try to pass themselves off as the real Spotify app.

And let me say a little bit more about cracked apps.

A cracked app is a legitimate application that's been tampered with to remove things like copyright protections, licensing, and security features.

This lets a user access content for free that they should have to pay for.

I don't think there are any developers in this room who want to see cracked versions of their apps proliferating across the EU.

And I can tell you that one of the most notorious distributors of cracked apps contacted us immediately after January 25th to express interest in building a marketplace on iOS.

We wanted to continue identifying and stopping these kinds of apps through notarization, instead of just through app review for the app store.

And we've heard that much of the market actually wants us to do that too.

Unfortunately, we were told this wasn't permissible.

All we have been allowed to do is require app marketplaces to have a system to screen for these things and react when it's reported.

But that's it.

Some of you may be wondering why the notarization process is necessary rather than just leaving it to the app marketplace or another third party.

One main reason is that Apple takes responsibility for the privacy, security, and overall quality of our users' experience on iOS.

Users buy iPhones because they want a seamless experience, including privacy and security.

So not getting that experience harms the integrity of the product.

And I also think it's important to emphasize that Apple is the best qualified party to perform notarization for iOS apps.

Teams at Apple have more than 15 years of experience and expertise in reviewing apps for malware and other privacy and security threats.

That includes knowledge of our operating system and a long track record of working closely with developers.

Not to mention our automated review tools have been trained on years of that accumulated data and are informed by institutional knowledge gained from millions of app reviews over the years, which has been critical to helping us uncover harmful apps in the past.

We've also been asked about the criteria that we're asking alternative app marketplaces to comply with.

An app marketplace is a very powerful service.

It's an app that has the power to install other apps.

Operating an alternative app marketplace requires significant responsibility and oversight of the user experience.

And it almost goes without saying, but we want to make sure users are protected from dangerous and scam marketplaces and apps.

That's why we're requiring marketplaces to meet minimum specific requirements, including committing to protect users and developers on an ongoing basis.

That includes committing to comply with laws like the DSA and the GDPR to publish transparent data collection policies and terms for third party apps that the marketplace will distribute.

It's meant to have, as Kyle just said, a mechanism to review apps for intellectual property violations and respond to IP disputes for apps in the marketplace.

It also includes a commitment to the ongoing monitoring and detection of fraudulent, harmful or illegal apps.

Our experience has shown us that this is imperative to protect users because sometimes, despite all of our efforts, we don't detect harmful apps during our review.

And some apps that appear benign during review are triggered after review to then become malign.

We know from experience that it's the marketplace themselves that are the best positioned to read the signals and identify apps like this.

We do that today for the app store by looking at signals like user reviews, information we get directly from customers and analyzing data from the app store like download rates.

So, we are not only requiring alternative app marketplaces to do this monitoring, we are also requiring that marketplaces demonstrate that they have the resources to carry out the monitoring.

These and other standards will help protect users from bad actors who would try to trick them into downloading fake or dangerous apps and then disappearing or into downloading apps that will turn dangerous after they've been downloaded.

Although we can't directly import the safeguards we've built into the app store, we are hoping these requirements will reduce risks on alternative marketplaces.

Now, with the new web distribution option we're adding, there's no independent distributor, so there's nobody who can monitor apps after they're notarized.

To address this for web distribution, we'll be looking to developers with an established track record and accountability to users.

I'll turn it over to Brendan to speak a bit more about the relevant terms here.

Thanks Gary.

On that subject we've heard questions about the purpose of some of the business criteria we've put into place for alternative app marketplaces.

We know from hard experience that marketplaces need resources to provide ongoing support to users and developers.

If users and developers don't have recourse when a need arises or not adequately protected by a marketplace, that compromises all users.

So that's why we've asked marketplaces to show that they can provide at least a minimum level of support to developers and users.

They can do this through a standby letter of credit or simply by maintaining membership and good standing in the Apple Developer Program for two continuous years or more and having an app that has had more than one million first annual installs on iOS in the EU in the prior account.

Another observation we've heard people make is that we allow web distribution on Mac with a version of notarization that's less involved than what we're going to do on iOS and without the additional developer requirements.

So it's natural to ask why the two processes differ.

This comes down to the fact that smartphones are fundamentally different from laptops and by the time Apple launched the iPhone, we've learned a lot from decades spent with the Mac.

Today, we all keep our most sensitive data, including location and health data on a device that we carry with us constantly.

We expect our iPhones to be working all the time, including in emergencies.

That's just not true of laptops or desktops.

So it's especially imperative that iOS functions consistently and securely.

That's why we're putting more guardrails on who can distribute apps from the web on iOS.

That's also why we've enhanced our notarization process on iOS above and beyond what exists today on Mac OS.

We think that's what's necessary to protect our users as much as we can.

We've also heard some observe that the DMA specifically allows gatekeepers to protect security and integrity, so it's unclear why Apple continues to say that the DMA creates risks.

I hope that our explanation of many of the threat vectors we just spoke about, which are inherent to alternative distribution, helps to answer this question.

But there's one more point I'd like to make.

A lot of the new risks are inherent from the fragmentation of distribution.

Even if all new app marketplaces dedicate significant resources to monitoring, and we can't be sure they will, it will be harder to identify these harmful apps than it was before.

Because the signals that marketplaces analyze to identify bad actors will be spread across multiple marketplaces.

And some existing signals will simply disappear when apps are distributed through the web.

Once we bring that new functionality to iOS later this spring.

There is just no way around that as a new risk factor.

With that, I'd like to turn it over to Brendan to talk about alternative payments.

Thanks Gary.

For years developers have been able to use Apple's secure and private commerce system to access a wide variety of tools in selling digital goods and services in their apps on the App Store.

These tools enable developers to manage pricing across 175 storefronts and to support almost 200 local payment methods worldwide, all while offering an integrated fraud prevention system, customer support, and parental controls like Asstabai.

Over the last 15 years this system has enabled an explosion of digital commerce which has created incredible economic opportunities for developers and consumers around the world and in the EU.

In fact, in 2022, 54% of downloads across the world occurred in storefronts outside of developers home countries.

All of this has been possible because our users are able to expect that their payments are safe and secure when making digital purchases through the App Store's secure commerce system.

As we launch new options under the DMA, developers can choose to continue using the App Store's commerce services, including an app purchase when they distribute digital goods and services through the App Store.

And developers can now choose to use alternative payment service providers or PSPs for purchases of digital goods and services inside their apps on the App Store.

These options mean that a developer can integrate an alternative PSP that lets users check out and complete transactions entirely within the app.

Apple is also offering another new option.

Developers can now inform customers of offers and promotions within their apps on the App Store using a link out to their website for users to complete their purchase.

And developers can choose how to design in-app promotions, discounts, and other deals when directing users to complete a transaction on their website.

That's a new feature, something that developers weren't previously able to do.

We make design templates available for developers to use if they would like, but now developers will not be required to use them.

We have received positive feedback from developers who are excited about being able to offer alternative ways for users to complete their purchases.

I do want to address one question that we've received on this.

Why is Apple continuing to take a commission on transactions of digital goods and services that are initiated within App Store apps, but processed outside of in-app purchase?

The answer is that everyone gets the benefits of the App Store, regardless of how payments are processed.

So, Apple's commission model reflects the value the App Store creates for developers, including distribution, discovery, promotion, and trust.

So, that's why they will still be responsible for paying a reduced commission that reflects the tremendous value the App Store creates for their business, like helping millions of App Store users discover their apps and enabling instant distribution of users across the EU.

Of course, developers who use alternative payment processing or linking out to complete their transactions will not pay Apple any payment processing fee.

For developers who choose to direct users to their website to complete their purchase, the inclusion of the link in their app will be entirely free of charge.

When a user taps on the link and completes the transaction on the developer's website, Apple will only charge the reduced App Store commission, and only on transaction conducted within seven days after the link out.

Transactions completed on the website after those seven days are free of any commission.

This allows developers to realize significant cost savings.

Gary?

Thanks Brendan.

We've also received questions about our new protections around the use of alternative payment processors, like the requirement a developer offer either in-app purchase or an alternative payment processor, but not both.

Our requirement to show a system disclosure sheet before users engage in transactions with alternative payment providers for digital goods and services.

So I'd like to say a few words about that.

Taking a step back, it really comes down to how Apple always strives to be transparent and to empower users with information.

Let me explain why that is important.

When we introduced in-app purchase 15 years ago, users could, for the very first time, trust that they could buy digital goods and services from any developer anywhere in the world, and have confidence that they were going to get what they paid for, could request a refund, and wouldn't have their financial information compromised.

That was a huge deal because you really needed to earn that trust in order to convince a customer to buy something that exists only in the digital world.

In many cases from a developer, they had never heard of.

Developers in the EU that choose Apple's new business terms will now be able to offer alternative payment options if they choose.

And because these payments are outside of Apple's commerce system, features that are integrated in Apple's system, like Report a Problem, Family Sharing, and Ask the Buy, won't be available.

Similarly, Apple can only support purchase history, subscription management, and refunds for transactions made using the App Store's Commerce system.

And there are undeniable risks that may arise from payments, including specific predatory techniques that in-app purchase prevents such as subscription traps, misleading payment information, and more.

The white paper I mentioned earlier goes into these in a lot more detail than I have time to do so here.

Swift developers offer an alternative payment solution to make sure our users realize that things are different now and they're no longer transacting with us in the way that they're used to.

The operating system will show a prompt screen displaying a system disclosure sheet before a user makes a transaction for digital goods and services.

A user then makes the decision that is right for them.

These prompt screens are meant to provide critical information to users, regardless of their level of expertise navigating technology.

All of us in this room may be savvy enough to recognize the things have changed, but your parents, your grandparents, or indeed your children may not be.

These disclosures are for all of our users.

We've been asked why the device doesn't show disclosure sheets when a user is making a purchase on an app that sells physical goods.

And this just goes back to user expectations.

In the 15 years of the App Store, Apple has actually never played a role in processing payments for physical goods.

It's not something we've ever done.

That's why we don't think a disclosure sheet is necessary.

We simply are not involved in payment processing for physical goods and users don't expect us to be.

And that's why we're only providing information when we're changing what our customers are already used to.

Thanks, Gary.

I know everyone's probably tired and eager to ask their questions, but I do want to go briefly over our new business terms, because we've gotten a number of questions about those.

To explain how all of this works, I'm going to give a short overview of the terms and why we developed them in the way we did.

Since its launch, the App Store's business model has been very simple.

Apple charges developers a commission only on the sale of paid apps and digital goods and services that are sold within the app.

Under this model today, 88% of the active developers on the App Store in the EU have paid no commission to Apple.

And the vast majority of those who do pay a commission have paid a reduced 15% commission thanks to the Apple App Store's small business program and other initiatives.

Apple's traditional business model reflected the value of all the technologies, tools, and resources that make it possible for developers to build and share apps with Apple users.

And iOS itself provides enormous benefits for developers in ways that sometimes aren't very visible. iOS provides a trusted platform for developers to easily reach a global user base.

Every day, Apple makes improvements to its hardware and software, releasing new capabilities and enhancements that generate concrete benefits for all developers.

We provide a world-class suite of tools that developers can use to easily build and maintain apps for iOS.

For example, we offer more than 250,000 application programming interfaces and 40 software development kits.

An integrated development environment for developers to design, code, test, and debug apps.

Performance tools that enable developers to quickly address problems and make technical improvements to their apps.

The list goes on and on.

And we are constantly improving and expanding these tools, empowering apps to improve and offer a better user experience over time.

And we do the same for the underlying technology, constantly investing in ways that provide increasing value to developers on an ongoing basis.

The investments we make in improving the audio quality on iPhone enable music apps to deliver better experiences to users, making their apps more attractive in the process.

The ongoing improvements Apple makes to its chips, like our neural engine, or what have allowed for advanced machine learning models, which developers can integrate their apps through the core ML framework that we've built.

The advancements we've made to the camera have facilitated the wild success of many social media apps that rely on Apple's video stabilization technology.

And of course, the world-class security architectures we design into iPhones have earned users trust, allowing developers to focus on building great apps rather than trying to earn that trust for themselves.

All this value is created by the platform itself.

I provide these examples because it's really important to understand what our platform enables for developers.

And we also know how important developers are to us and to our users.

We all benefit when each of us invest in enhancements and improvements that ultimately serve users, our shared goal.

For the last 15 years, we've chosen a business model that reflects all that value in a single App Store commission.

But that's not all the value that the commission has reflected.

It has also included the distribution, discovery, and promotion services provided by the App Store, which users have come to trust, enabling small developers around the world to reach massive audiences and easily get their apps under the phones of millions of users.

And it included the value of the many services provided by the App Store's secure, private, and trusted commerce system, including payment processing through in-app purchase.

The new options for distribution and payments under the DMA separate out these many ways Apple creates value for developers.

That's why we've developed new business terms to reflect these changes.

They include a reduced commission for apps on the App Store, a fee for developers who choose to use Apple's payment processing, and a core technology fee that reflects the value of Apple's proprietary tools and technologies, the trusted platform, and so much more that all iOS developers benefit from.

I'd like to discuss each of these components in turn.

But first, let me make clear right off the bat.

We know developers value choice.

So we've given them the option to choose the new terms, or if they prefer to stay on the traditional terms.

We also recently announced a one-time option for developers to switch back to Apple's standard business terms for their EU apps under certain circumstances.

We wanted to do this in order to help reduce the risk of unexpected business changes under the new terms, or if developers simply want to change their mind.

We want developers to be able to decide which terms are right for them.

So let's start with the App Store Commission.

The new terms include a significantly reduced commission to cover the services provided by the App Store, the promotion and discovery opportunities we provide, the instant distribution to millions of users, and more.

For those developers that choose the new business terms and want to continue to distribute through the App Store on iOS, our discounted program commission rate, meaning the commission rate that the vast majority of developers have actually historically paid, has dropped from 15% down to 10%.

And for the small number that have paid a 30% commission, we've lowered our standard commission rate from 30% all the way down to 17%.

All commissions continue to apply only to the sales of digital goods and services, and when these developers distribute outside the App Store, Apple will collect no commission at all.

For those developers who want to use the App Store's payment processing, that is now offered as a 3% optional add-on.

Or developers can use an alternative payment service provider for no additional fee to Apple.

The third component is the core technology fee, which reflects the value Apple provides developers through the many tools, technologies, and services, and the large worldwide iOS user base I discussed earlier.

All of these things generate increased value for developers over time.

Apple is constantly adding new APIs, SDKs, and more.

Developers benefit every year from the work we do to make iOS and iPhone even better, enabling to offer new features to users and grow their businesses, regardless of whether they distribute their apps on the App Store, on an alternative App Store, or through the new web distribution option we're making available later this spring.

Those are important reasons why the CTF applies to an app regardless of how it's distributed.

This fee is 50 cents per first annual install.

As we developed this metric, we kept the importance of regular App updates in mind.

We only count an install once per year, and once per account, not per device.

So developers can keep providing regular updates to their apps to fix bugs, patch security issues, and provide new features to users.

Kyle, I did want to just jump in, which actually involves me grabbing the mic off of you, and this goes back to Apple's focus on security.

I want to reiterate that Apple specifically designed the first annual install metric so that developers can continue to update their apps without incurring a fee every time an update is installed.

Developers are able to build and ship as many bug fixes, security patches, and feature upgrades as they want every year at no additional cost.

It is the right thing for users and is also good for developers.

Let me push it back here.

Thanks, Gary.

We also want to ensure that new and upcoming developers can continue to thrive on our platform.

So we're providing 1 million first annual installs in the EU for free every year for each app.

Because of those 1 million free installs, we estimate that less than 1% of active developers in the EU would pay this fee.

We are also waving the fee entirely for registered nonprofits, government agencies, and educational institutions.

We think of the core technology fee as something that developers only pay after they've used the benefits they get with their Apple Developer Program membership to drive thousands and thousands of downloads.

That is an incredible value proposition for all developers, including the ones that become wildly successful enough to hit the threshold for the CTF.

As I said at the beginning, we've been listening to feedback over the last few weeks, and we've made some modifications to our terms, which include enabling web distribution, developer-specific marketplaces, and more.

Let me highlight just one more example of that.

We initially said that the new business terms needed to be signed at the corporate group level.

That's something we heard a lot of concern about from developers during our meetings over the last few weeks.

We took that feedback, and now an entity can sign up for the new terms at the developer account level.

That may sound like a very technical issue, but it matters to a lot of people, and we're happy to have addressed it.

So before I wrap up, let me just say this.

This is an effort that our whole company has worked tirelessly to pull together, and it's an effort that is ongoing.

We're doing it with extensive input from regulators and stakeholders, and we look forward to continuing the conversation.

With that, I'll turn it back to Lucia so we can hear questions from the audience.

Thank you, Kyle.

Thank you.

Thank you.

So the room is very curious, which is a good thing.

I will just very quickly recall the rules of engagement, so let's keep it as nice and civilized as we had the first session.

So before you speak in the room and on a slide, please state the name and the organization you represent.

Anonymous questions from slide will not be asked in the room.

Keep it clear and short, in particular, if you do not have a question but rather feedback, it's maximum two minutes per intervener.

Keep it relevant and on topic.

There are other sessions, or as I said, if you have observation which does not concern this relevant session, please send it in writing to us.

One question per intervention, let's keep that, especially in this session where many hands are up.

So let's not have, I ask this, this, and this, and also that, because it's also very difficult to follow for Kyle and to answer, and also this way we will have more rotation, you can ask, maybe in the next round.

So no attacks, civilized constructive, of course, and again, the commission is here just to moderate and we will be taking a couple of questions at the time, three, four, and the same thing with Slido.

We will be alternating between the room and the Slido, so I promise that the Slido gets to ask questions at this point.

I have a lot of interest in the room and because we are already over time, I propose that you raise the hands again and I will, okay, so we will do, we have four rows here.

So, lady in the back first.

Thank you, I will be really short and I really have a basic questions.

How long do you plan to keep both business model for the upstairs?

Should not.

The name please, organization.

Caramel Lambo from European Parliament.

How long, I don't know if you heard the question, so, and should not be just one business model that is comply with the law or not.

Hands up again, gentleman with the cap, that's very good because that I can recognize.

Hi, I'm Riley Testut, I'm the founder of AltStore.

First, I want to say I attended the core clubs the past couple of weeks, they were great.

Thank you so much for them.

Very helpful to have engineers we could talk to and get questions answered, especially because we are a two person team and we need all the help we can get doing that.

Thank you for that.

I also want to say as a whole, I see what Apple is doing with these changes and I think they are striking a very good balance between what the EU is asking for and what Apple prioritizes for users.

I am a consumer myself and I chose iOS because it's very streamlined and easy and integrated and I don't want that to change for the majority of people.

I just want some additional options for those that want it.

So, to keep it short, I'll just focus on one thing, the core technology fee.

Again, I think it does make sense for the majority of use cases that Apple has outlined.

However, I really think it's just a truly an existential threat to basically all free and open source apps out there, especially those made by kids.

And that's a strong point for me because when I was in high school, I released a free open source app outside the App Store and it received over 10 million downloads.

That's actually the reason I'm building out stores to distribute that app because there's not a lot in the App Store.

But anyway, so under these new business terms, I would owe Apple 5 million euros for my free app I made in high school.

For comparison, AWS, my first week of hosting was $15,000 and that was way more than I could afford, but I called Amazon with my parents and explained the situation and they very graciously waived the fee for me, understood what I was doing.

So, I'm just going to say, Apple is not Amazon, so my question is, if I was in high school today and I released the exact same app outside the App Store and I got the exact same download numbers, would Apple actually charge me and my family 5 million euros knowing it would most likely financially ruin us?

That's my question.

Hands up for the road.

Yes, please gentlemen.

Hi, I'm Gene Burris from the Coalition for App Fairness.

So, I have a few comments and hopefully a question maybe with a subpart or two, but not to be too, not to be too.

So, the purpose of the DMA ultimately is to create contestability and fairness in digital markets.

And there seems to be a number of explicit provisions of the DMA that have been ignored by, especially by the new business structures and fee structures that's been imposed.

I'll note that there are two provisions in the DMA that specifically call out that things must be provided free of charge by Apple.

One, the right to steer off of the app in order to transact with their customers.

And two, the right to interoperate with iOS free of charge under 6.7.

The fee structure seems to violate both of those provisions in that there is no path for any developer to steer their customers off of the app to transact that can be done free of charge.

I was wondering why those free of charge things seem to have been ignored.

The other piece of it is under 6.12, access to the app store, of course, has to be fair, reasonable and non-discriminatory.

And fundamentally, you talked a lot about the value that Apple provides to developers.

You didn't talk very much about the value that developers provided to Apple.

In fact, developers provided that value to Apple back in 2009, 2010.

I'll add before the imposed requirement for Apple payment processing was used for digital goods.

That hasn't been around 15 years, it was actually 2011 when that came into force.

But this idea, the value propositions you talked about for sellers of digital goods are equally applicable to sellers of all other kinds of goods, both physical and pseudo-digital things like electronic plane tickets or things like that.

All of that value is provided to all of the developers in the same way.

Yet, there seems to be a discriminatory approach to sellers of digital goods that seems to be in clear violation of 6.12.

Under 6.4, also, there is a requirement that actually effective use could be made of alternative app stores and app distribution mechanisms.

The fee structure and other requirements that are in there like exclusivity to either the app store or alternative distribution would seem to undermine that ability for any apps to actually get enough traction to be effectively used.

And I'll add to that too, you talked about they need resources in order to do a good job.

Most of the resources under your new fee structure of any new app store would be confiscated by Apple, essentially making that an Apple franchise where most, if not all of their resources would have to be turned over.

And then finally, it's a question related, it's actually related to 6.2, but you mentioned it in the requirements for new app marketplaces.

The use of data is going to be one of the qualifications that you impose on these third party app stores.

I'll note that the developer community hasn't heard at all how Apple intends to comply with 6.2, which is the use of developer data for competitive purposes.

What internal provisions you might have made to ensure that your engineers don't actually access confidential developer data to use it in competition against those developers.

In the second time, you put in place to make sure that your engineers don't do that.

It's a requirement you're going to impose on third party app stores.

It doesn't seem to be one that you've imposed on yourself.

Thank you.

And for all, please raise hands only if you have a very short question.

Okay, so you're the winner?

Yes, yes, yes.

Hi, my name is Thibbon Kitchiff.

I represent Monster International.

I have two very short questions, hopefully.

You mentioned that you want to enable from the teenager to big corporations, yet you're imposing a 1 million euro requirement for alternative app stores to provide your bank guarantee or another letter.

That doesn't seem to be proportionate for teenagers.

Also, I wonder how do you think that's compliant with 6.4?

Exactly.

And the core technology fee, you mentioned that that's because iOS provides a lot of value.

Why then do you have two business models?

So, on the regular terms that you're still making available, nobody has to pay the core technology fee, but if they accept the new terms they need to pay.

So, to me, this doesn't sound right.

I mean, it's the same value, right?

That was it.

Thank you.

So, I think this is a good...

Kyle, please go ahead.

Sure thing.

So, we're going to test my memory in terms of questions.

So, I'll start with the first from the corner in terms of our approach to developer choice.

And so, as I mentioned, we spent a long time thinking through how to comply with these provisions of the DMA and all of the provisions of the DMA.

And I think as we start to develop and formalize our plans and then begin to implement them, we realize that these were going to be some pretty significant changes.

Obviously, significant changes for Apple, significant changes to our users, and significant changes to developers.

And what we've heard as we've engaged with the developer community over the last 18 months about some of this is that change can be scary.

And so, what we ultimately ended up on was at least at this period where there's a lot of change happening, there's a lot of questions, obviously, coming up, that we wanted to provide choice to developers.

And so, that's why we have both options at this point.

In terms of how long it'll last, in terms of duration, I think those are all questions that are going to have to play out over time.

Obviously, the commission will have a perspective on that.

Obviously, developers will have a perspective on that.

But at this point, we're focused on providing choice and trying to minimize disruption during this period.

What ultimately happens in months and years to come is something I'm not prepared to have an answer for now.

I can say what we will do and how we'll approach it is listening to feedback from all the different stakeholders.

This is my friend with the great sweatshirt.

So, first, it's great to hear that you had a good experience in Cork.

We worked hard to develop those labs and make them useful for people.

So, it's good to hear that feedback.

Now, in terms of the core technology fee, and I know there were a couple of questions that touched on this.

Obviously, what we were trying to do is tear apart a model that's been integrated for 15 years.

And so, for 15 years, the way we monetized everything was through the commission.

That covered everything from technology to distribution to payment processing.

And the beauty of that model is it allowed developers to take risk.

Apple only got paid if the developer was getting paid.

And so, that was an incredible engine for innovation over the last 15 years.

We've seen it go from 500 apps to more than 1.5 million.

To your point, we've seen kids everywhere from 8-year-olds, 9-year-olds to teenagers develop some amazing applications.

And it's been one of the great success stories of the App Store through to the day.

In terms of the core technology fee and our new business model, we had to change.

This, the mandates of the DMA, forced us to tear apart what we had built and price each component separately.

And so, we now have a fee associated with the technology tools and services.

We now have a fee associated with distribution and the services we provide to the App Store.

And then we have a separate fee for payment processing if a developer wants to use it.

To your point, what is the impact on the dreamer?

The kid who's just getting started.

And that could be a kid, it could be an adult, it could be a grandparent.

We want to encourage, we want to continue to encourage those sorts of developers.

We build a store based on individual entrepreneurs, not so much catering to large corporate interests.

And so, we really wanted to figure out how do we solve for that.

We haven't figured out that solution here.

I fully appreciate art.

We looked at the data.

We didn't see many examples of where you had that viral app or an app that just took off that would encourage huge cost.

That said, I don't care what the data said.

We want people to continue to feel and not be scared that, hey, I'm going to -- some parent -- I've got four kids who play around with this stuff.

I don't have five million euros to pay.

This is something we need to figure out.

And it is something we're working on.

So I would say on that one, stay tuned.

Thank you, my quickest thought.

I'll take the many part question next.

Listen, in terms of our approach to 5/4, we are very focused on ensuring that we comply to allow developers to promote and communicate offers from within the app.

And we've done that.

We announced a plan in January that went beyond and allowed for linking out.

We then announced changes just a week ago in which we further let loose controls so now a developer can do whatever they want within the app to promote or communicate offers.

And so -- and we've heard from a number of developers since we announced these changes that they're really excited about this.

In terms of our transactions that take place through the App Store, as Brendan described, those are things that are still subject to a commission.

So whether you're using a service -- a third-party payment service provider, or you're using a web view or website to transact, they're still subject to the App Store commission, and we believe that's fully consistent with the language of the DMA.

In terms of -- there are some -- a number of questions around Fran, both respect our old model and our new model.

I think this has been a fundamental principle of the App Store from the very beginning.

We're not a company that's ever had special deals with any developer.

We have had a standard set of terms from the very beginning, and we've been very clear and public about what those terms are.

We know -- and others take a different approach.

We've seen that.

We know on other platforms there are regular, you know, special deals or unique deals, particularly for large developers.

We've been approached repeatedly over the years seeking special terms, special deals for developers.

We've never done that.

We've always taken approach that we're going to have one set of rules, one set of policies for the entire developer community.

And so when it comes to our commission structure, it applies to everyone who sells digital good or sells contents and services within their App.

That's straightforward.

That's been consistent.

And from our perspective, Fran.

There was a question around all distribution in data that I'm going to defer to Gary, and I know we have another session later this afternoon to talk about some of those issues.

I don't know if you have anything to add on this point now.

Yeah.

I'm happy to, just to give you a little bit of a break for a moment.

So that's actually covered -- I just meant checking when you reference it.

We do mention it on page 11 of our non-confidential summary of our compliance measures.

As you see in that instance, we would consider that we were in a very good position to already comply with any provisions in relation to the use of personal data.

And your interest in this instance is data relating to business users or their users.

So we've actually put a very extensive compliance process in place, just building upon what we already had, because as you can imagine, we already had very strong safeguards in place.

That data is tagged.

Access to it is subject to a very specific approval process.

It will be subject to detail auditing, and it is something that we are very keen to ensure that we actually meet the highest of standards in relation to it.

But if you have the stamina, the session starting at 4 o'clock later will afford ample opportunity to go into that in a lot more detail.

All right.

And then, the last short question.

There are two subparts.

So there are a question around kind of some of the criteria we've put in place for app marketplace.

And again, as we've approached these criteria, we were looking to do two things.

We were looking to create kind of a minimum set of operating criteria that address things like fraud, to ensure that developers have policies related to content and other things.

And we also really -- the second part is really important.

We wanted to ensure that these were accountable developers, that these were not fly-by-night operators.

What we have seen as we've looked out in the marketplace, and we've seen this in a number of different jurisdictions, is marketplaces who pop open and shut down very quickly, leaving users and developers in the lurch.

And so the intent behind the letter of credit, the intent behind the install thresholds, was really an attempt to make sure that we had responsible and accountable developers operating these marketplaces, such that if something happened, users and developers would not be left completely in the lurch.

That said, we're open to feedback about how we can accomplish that goal in other ways.

But that's really what we are trying to do with those two criteria, is again, with our focus on our user base and our developers, have a criteria that ensured that operators were taking care of them.

Second, in terms of the core technology fee and its interplay with our standard business model.

So again, I think I've covered this a couple of times, but just to kind of put a finer point on this, in the past, we had a simple business model.

It said a 30% commission, or more frequently, a 15% commission, that were on digital goods and services.

That covered the entire bundle of value that we provided to developers.

It was the technology and the tools and the services that we invested in in 2009, and it built up year after year since that time.

It is how we've created the App Store to allow developers to reach a global user base, 175 markets around the world, tens of millions of users with a simple click to the button, and also be easily discoverable.

And then of course there was the payment processing piece.

So you had these three kind of what I'll call sticks in the bundle.

What the DMA has forced us to do is to break apart that bundle.

That's never been something we ever thought about, ever wanted to do, ever considered.

So this was something that was forced upon us by the DMA.

And so what we did is we broke it apart, and then we thought to ourselves, "Okay, what's the value of each independent part of this value proposition?"

And we took months, if not longer, to consider what's the appropriate price, what's a fair price, while we're still encouraging development and innovation on our platform, how can we create a model that continues to offer great value to developers while ensuring that we can be compensated appropriately?

So hopefully that answers that question.

Thank you, Kyle.

So to appease the room, I take one more round from the room, and we will do gender balance this time.

So...

Good morning.

I'm speaking on behalf of the coalition for Open Digital Ecosystems.

There has been lots of comments about security, understandably so.

I have a comment on a question, so it's very common for apps and services to be side loaded and distributed by other means outside the app stores, in a way that it's secure for consumers and developers.

So why... the question, I guess, is very simple.

Why can't not Apple... or why would... if Apple could give concrete examples of why this is not happening with IOS, and yet it's possible with other... others can allow it.

Thank you.

Someone is begging their self-read.

Thank you very much.

I'm Lucas LaSotta from the Free Software Foundation Europe.

I have a comment.

We heard that smartphones are fundamentally different as laptops in relation to limiting side loading.

I just wanted to comment as a feedback that smartphones we have today, including iPhones, are general purpose computers, following the same design principles established historically by other lovelace, alloturing, and in von Neumann and others.

Marketing commercial considerations cannot change that fundamental nature of these devices.

Claiming otherwise is an affront against common sense and digital autonomy of devices users.

Thank you very much.

Thank you for brevity.

Ladies.

Thank you.

Good morning.

So do you think... sorry, first introduction.

I'm Bora Bala Sichbathvay.

I'm from the App Association, and we represent more truly micro-sized developers.

Do you think that is likely that negative consumer experiences on third-party apps may create long-term negative effects in consumer trust in the overall app ecosystem as a whole, including Apple's App Store?

So as a bit of context for our membership, which is small app developers, consumer trust is incredibly important because when users choose apps that they want to download, with large apps, there's network effects at play where large amounts of reviews and large amounts of users provide this user trust inherently.

Therefore, for small developers, it's really the ecosystem of the App Stores, which guarantees this user trust, which enables them to go out and venture and explore these smaller applications, which trust.

So do you think that there will be these negative effects, and are there any steps that are being taken to potentially negate these negative effects?

Thank you, and the last one.

Vanessa.

This is a ladies' turn.

Thank you.

I want to ask a question, obviously, from the user perspective, Vanessa Turner from Bay of the European Consumer Organization, and specifically on the prompt screens.

So as the number of speakers said, users want to have safe and secure products, but they also want to be able to make autonomous informed, as was also said, decisions that are enabled, in fact, indeed required by the DMA.

So I was wondering, with that in mind, whether you have tested the proposed prompt screens for alternative payments and transacting outside the app, whether you've tested that they are neutral, particularly in light of a neutral as required by the DMA, particularly in light of previously evaluations by stakeholders, including an EU regulator.

Thank you.

So, Kyle, your turn.

All right.

I'm going to go around.

So I think I'll ask Gary to address the first two questions, where I think are largely related, which goes to kind of the differences between the iPhone and perhaps other mobile devices in the market, or the difference between iPhone and PCs and other types of devices and the security and privacy and safety that we've built in and established over the last 15 years.

So I'll turn that over to you, Gary.

Thank you, Kyle.

I actually think the first three questions might be for me, so I might just elbow my way in there.

So I think the first question was essentially asking for us to produce concrete examples of where sideloading has introduced risks on other platforms.

I actually could probably take the remaining 56 minutes of this session and call out countless situations and examples where sideloading on other platforms has actually brought about negative outcomes for users.

I think that's probably not the right way to answer it, so I think what I will do is I will point you towards the paper, which I referenced twice in my remarks, which is called Complying with the Digital Markets Act.

We published it at the end of February start of March.

It's subtitled "Apple's Efforts to Protect User Security and Privacy in the European Union."

One particular point because I believe you're referring to Android is that even Google itself encourages users who are looking for a higher level of protection under a program called Advanced Protection to actually disable sideloading of apps.

So it's not just Apple saying it, and there are many, many studies, so I think it would probably be appropriate to just, you know, maybe just look at those rather than have Apple speak to it.

I think the second question was that smartphones are computing devices and so much similar to computers, Macs, laptops.

Yes, they are in terms of their capacity, which is fantastic for all of us as we use them, in terms of the computing that they can engage in on the device without data having to leave the device.

There are so many things that will take place on your iPhone in relation to your photos, your health.

I can open up my phone now and give you very detailed insights into my life, which my Mac does not know about me, and it is those detailed insights into my life, which are known to me, and not Apple.

I get to decide what I wish to do with them, which is why we have this very specific focus on what apps and what other third parties in very sort of ways can access the data that is private to me on my phone.

And then I think the final question, which I heard for me, was the question in relation to trust, and I think everything that is in that report, which I referenced, and our approach in terms of notarization, requirements for alternative app marketplaces, the app install system sheets, and the alternative payment sheets are all about trying to maintain trust for our users as they use their devices so that they will continue to engage in that kind of activity.

I think that is in everybody's interests.

And so I think we're trying to do everything we can, but as we sit here today on what I believe to be the 18th of March, we are just at the very beginning.

We don't know where the steps that we have taken are the right ones to try and maintain that trust.

We are obviously worried about it, but we are very hopeful that they will make a positive contribution to maintaining that trust, but obviously we will keep this area under active review to ensure that users, no matter what means they are using to download apps, actually do have as much trust as we can possibly assist them with.

Back to you, Ka.

One other point I wanted to make relates to what we've heard from particularly national security organizations and other police organizations who have issued report over report over the years warning against sideloading and using alternatives other than the app store or on other platforms, the vendors platform, because they were worried about security threats.

And even after we've announced our plans, we've actually heard from dozens of government customers.

We've heard from hundreds of enterprise customers and thousands of users all asking for ways to turn off alternative distribution to be empowered to have control because they are worried about these and other threats.

So it's not simply from Apple, but I encourage you to kind of look at things like from Europol and others who have expressed some concerns.

In terms of kind of the question around trust, I mean, Gary touched on this, but this has been fundamental to what we think has been the success story of the app store over the last 16 years that we built trust with our users on a whole host of levels.

It's easy to forget before the app store, most users were either loading software directly through PCs or through CD-ROMs or downloading software from the internet.

It was a little bit hit or miss to say the least.

There were problems.

The app store made it really easy, and it also made it trusted.

And that those two things led to an explosion of output.

That trust led to incredible growth for established companies, but it also led to incredible growth from some of the small independent entrepreneurs that you were referencing and is critical to what we think about when it comes to the app store.

That's what we want it to be.

And so we are worried about what happens in a world if users begin to lose trust in iOS.

It begins to lose trust in what they might be downloading.

That's something I think we all should be concerned about, and we think there's a very real risk of that.

In terms of the last question around information screens, obviously we've deployed information screens in this context in several different markets.

We've gone through different iterations now.

We feel that we've struck the right balance between informing the user about what is happening and the choices being presented to them because it is a change.

I think that's what's so important here and is often lost is there's a change in user behavior and the experience they've had with their iPhones over the last 16 years.

And so in that context of change, from our perspective, it's critically important to inform users about what is happening and what is the choice that's being used.

And what is the choice that's being presented to them?

And we've done that in a fair and neutral way with the screens that we've introduced.

Thank you, Kyle.

We will now take questions from Slido.

Okay, so we collected the four questions from Slido.

First one from the DAC Mayors for the Center for European Reform.

He's asking will Apple support development of agreed industry standards for app store security to reduce the upper role as the sole ruler, the rule maker in the future.

Second question from Roy Shiro from Simpley.

What is the reason behind Apple allowing developers to return to regional business terms only once?

Does that mean developers will be out moved to the new terms if they don't object?

Third question from Duncan Schulz from Almond.

Can you please explain the floor a user would take to install via the web an application from a new iPhone?

The more clicks would lead to conversion and promote drop-offs.

Fourth question from Harry Helmelide from Estonian Data Protection Authority.

Please specify what criteria Apple would use to assess a marketplace, adding sufficient resources to carry out monitoring.

I'm probably going to dial a friend on this one too with Gary by my side.

So on the first question related to industry standards and security, and this is one I'd love Gary's input, but you know, Apple's always been willing to work with third parties to ensure that there's some base level of industry security.

I think and we'll continue to do that.

Obviously we're willing to work with third parties to create standards on iOS.

The challenge here is we're moving at an incredible pace in terms of technology and innovation.

We release a new operating system every year, a new iPhone every year with an incredible amount of technology and we're doing that.

We're unique in the marketplace in terms of creating the hardware, the technology, the software and the services.

And that integration provides us a lot of insight into how our products work.

It's not complete.

We miss things.

And then we quickly try to address them.

But I think it's very hard and I work with standard setting organizations, have a lot of respect for them.

Speed is not one of the things they're known for.

There is a role, but I think for us there's no way to ever kind of just give up a role, an important role to making sure that the technology that we're releasing into the world is being used responsibly and safely.

Gary, do you have anything you want to add?

Yeah, I think you're right.

We work very closely with standards or standards organizations, including on security.

We work closely with SD here in Europe.

We've contributed to a number of security focused standards issues in relation to working with law enforcement also.

We also input in great detail to ISO standards and there are a number of those on security and privacy.

I don't think there's app marketplace standards currently, but I think we would be very happy to contribute to work of that nature.

We also work very closely with W3C, which is relevant for our earlier session, where we feel it's a very important for ensuring that we have common standards for security and privacy in the browsing space.

So in so far as we can ensure that high standards are set, which as Kyle indicates is typically the experience in that space, I think we would certainly be very happy to contribute time to try and improve outcomes for everybody, which is after all our approach for many years.

So the second question words around the choice that we were presenting to developers in terms of models and whether they could flip back and forth.

It's a question that's been raised multiple times in our engagement with hundreds of developers over the last eight weeks.

I'll say this, it is not easy to switch back and forth.

A particular problem for us is what happens to the user as he or she has switched from one model to the next.

So administratively, operationally, that kind of flexibility is very difficult to accommodate in practice.

So we're continuing to explore it and continuing to engage and think about it, but there are some very real challenges associated with that and there's a real user impact as well that we have to be very careful about.

In terms of the experience when it comes to application third party app marketplaces, we try to create and strike a balance to make it very easy for a user to install an app marketplace.

We lead heavily on experiences we've built in the Mac and experiences that we've built through our MDM enterprise program to create a flow that one was familiar to us and two, and this is really important.

We want to make sure that the user understood what was happening as he or she is downloading this new marketplace or frankly installing an app directly from a developer's website.

And so we were focused on making it easy and simple while also ensuring that the consumer was informed.

Brendan, do you have anything you want to add on the install process?

The opening thing I'll add is Kyle indicated.

We have extensive experience.

Enterprise customers use a similar method today and many customers are very familiar with this process already.

I've also just going back to what I discussed earlier.

Once a user does download an alternative app store, we're making it very easy for the user to interact with that as they can set that as their default app store and a lot of the things that will happen much more automatically if they choose to make that step.

But as Kyle indicated, what we've been driven by is ensuring that customers know this step.

This is an important step.

They should be aware of the step that they're taking.

And then once they've taken that step, we're making it as easy as we can on them to do things like change their default if that's something they choose to do.

Now this is where we test my memory, but we got one last question related to accountability and thank goodness it's for Gary.

Well, I'm claiming it, Kyle.

I believe it was from the Estonian data protection authority, so therefore I felt it was for me.

But I was able to ask any question they wish.

So I think the question was about the criteria we've put in place for alternative app marketplaces.

I would draw your attention to page 11 of our report that I've now mentioned.

This will be my fourth search reference.

So it's compliant with the Digital Markets Act, Apple's efforts to protect user security and privacy in the European Union.

And we've laid out the criteria there in some detail.

It's also obviously available in our very large documentation that we've made available to comply with the DMA.

But the bottom line is this, and I said it in my earlier remarks.

What we're seeking to ensure is that the alternative app marketplaces actually have the means to provide a strong experience to users, which means an ability to monitor apps that are downloaded for how they are meeting user expectations in relation to security, privacy, and a safe and trusted place to operate.

Because it's wanting to want to do something, as we found from 15 years of experience, it is completely another thing to then have the means and the ability to give effect to that.

Often within very short deadlines, if something is operating in a way that is proving very detrimental to users, and that is what we're seeking to achieve.

And I'm actually pleased to get that question from a data protection authority, as you might expect, because I know, and I think that will come out of my presentation later on, we are trying to ensure we are meeting the right balance here and not have our compliance with the DMA open up vectors, which could be threats from a GDPR perspective.

And I know that's a view that's shared by, well, everybody in this room, I would assume.

Thank you.

So we are back to the room as much interest as before.

I'd like to come up please.

You need to grab someone's mic.

Hello, my name is Alexander Kosumone.

I'm the CEO and founder of MacPul.

We are developers of one of the first third party up marketplaces, and we are extremely grateful to Apple for this opportunity, and we've been part of the core collapse with our development team, so we received a lot of support from Apple.

Thank you for that.

So I wanted to say that over the years, we've built a very successful business on Apple's platform, thanks to Apple that was delivering all this APIs and ecosystem, and we've been able to build a successful business.

But the majority of our business is outside of the App Store, so we sell apps directly to Mac users, and 90% of our revenue goes from the direct sales through the website, not the App Store.

And the reason of that is that we are able to precisely control each user's step and experience from our marketing campaigns to the user to each user's direction.

So with this new marketplace that we are building, we also want to repeat this experience for our developers on the marketplace, and we want to give them power to control over the users and the marketing campaigns.

Unfortunately, we still don't have this opportunity yet, so we wanted to ask if Apple is open to provide some additional tools to extend the developer advertisement, ID, or some other stuff that we can implement in our marketplace in order to make it successful.

Thank you.

Sorry.

Okay.

Thank you.

Francois Zog from decision.

I would like to comment on the question, a comment on the previous hearing on the antitrust in the US for Apple, where there was at least a contentious aspect on fair handling between developers, where I quote Tim Cook saying, "I think we should have someone focus on them being by do and other requests like we did for Facebook."

So before there was official expedite handling, there were unofficial handling.

And it was, let's say, at least controversial on the US antitrust hearing.

It was in 2020.

The question is, can you confirm that the only fees that developers will pay will be CTF if they are sold through an alternate app store and using external payments?

Please go.

Good morning.

My name is Paul Trisentos from App Toys.

So just to give a context, App Toys is an European based Android App Store, incorporated since 2011.

Last year, we had more than 100,000 certified developers and processed more than 3 million in-app purchase.

And my question, first, just to set the tone, we are very positive about the model proposed by Apple, and we appreciate the effort that Apple is doing.

Our question is about the operational capacity of Apple to operate this model, capacity or willing to allocate resources.

And the question is as follows.

So, for instance, since February 26, we submitted several apps for neutralization, both for development purpose and for production.

And since February 26, we asked more than 16 times to Apple about how it's going to review and a couple of technical questions related, and we did not have any answer from Apple.

Another kind of review, it is still pending on review it.

And my point is, if we want to operate the people in this room, a marketplace that depends on notarization, and Apple don't put enough resources to review it, it will be impossible to operate that market.

And the question is if you also are willing to commit a service level agreement on how much time it takes to operate and to review those apps.

Thank you.

>> Hi, my name is Mark Perdemo, and I'm here representing the nonprofit App Fair Project, which is building an app marketplace to create and distribute for an open source app, so non-commercial digital public goods.

To be approved for an iPhone app marketplace entitlement, Apple is currently requiring that an organization, either one, have been an Apple developer program member for two years and have an app that has been downloaded one million times in the EU in the previous year.

We've been a developer program member since April of 2022, but it's impossible for us to satisfy the download count requirement because Web browser app that we submitted that year was rejected by Apple.

Option number two is provide a one million euro standby letter of credit from a rated institution as has been discussed.

That number presents a discriminatory and insurmountable barrier to a nonprofit organization such as ours.

I've requested an exemption from our Apple representative and was denied.

My question is, since nonprofit organizations are exempt from the core technology fee, what is the rationale for requiring any letter of credit at all?

And what is the objective fairness and reasonableness standard that prevents Apple from increasing that number to 10 million euros or 100 million euros or some arbitrarily high amount that would effectively exclude all alternative app marketplaces at some point in the future?

Thank you.

So we have four questions.

Many alternative app stores coming.

I'm getting excited.

So Kyle, why don't you take those and then we go to Slido?

I always look forward to Slido.

First, and I'll ask Gary to weigh in here in terms of the question from the MacPaw representative.

Again, I'm glad to hear that you had a good experience in Cork.

And again, I'd encourage anybody who's interested in opening an app marketplace to take advantage of that.

So we're going to continue to run.

Obviously, this has been a huge effort on Apple's part to enable third party app marketplaces in an incredibly short period of time, disrupting something that's been in place for 16 years.

And so I think from our perspective, we do look at this as version 1.0.

And there will inevitably be other functionality, other features, things that fall frankly outside the scope of the DMA that we'll hear about from developers like yourself or others in this room that we say, okay, we should implement this new feature functionality.

Of course, we're going to be, and this is where I'd like Gary to kind of weigh in, we're going to be focused on, okay, is there a user impact here in terms of whether security or privacy or performance, not suggesting in any way that your individual is going to be able to implement this new feature functionality.

And I think that your individual company would do that.

But our approach has always been to make these features and functionalities available to everyone in a similar situation.

And so we have to account for that kind of broad availability as we build out these new features and functionalities.

But, Gary, do you want to talk to that a little bit?

I think it's good news.

It depends, I guess, on my understanding of the question.

But I think also I very much appreciate you enjoyed being in Cork.

I also enjoy being there.

So, I think your question is, will there be something equivalent to the advertising ID?

And the answer is yes, there will be the advertising ID that will be available to any app that is downloaded to the device, whether it's through Apple's App Store, an alternative app marketplace, through web distribution.

It will be available in the same ways it's available on iOS today, which is it will be like other platform level controls such as access to location to health, camera.

It will be available as part of what has become known as the app tracking transparency framework.

So your app will be able to request access to the advertising ID and the system will manage the interface for you.

You obviously will put forward your reason why a user should provide access and then obviously a user will decide whether they wish to grant access to you in that space.

I think that has been since we launched it nearly three years ago now, a tremendously helpful way to improve trust and confidence for our users as they use their apps on our devices so that they know they get to control whether their data is going to be used for advertising purposes across towards party apps and websites.

If of course you're not looking to share data to third parties and you're using it yourself for your own purposes, well then obviously there is the vendor ID that is available and that is not gated by a system control.

So I think the second question, there was a question in the second person around core technology for you.

I do want to address the suggestion that somehow Apple treats large developers different than small developers, because that is simply untrue.

We have always operated the app store in a way that treats all developers in the same way.

In fact, in many ways we're looking to invest in those small and midsize businesses.

We're looking to invest in those entrepreneurs.

We want as many new ideas on the app store as possible.

And that's always been how we run our business.

In terms of the question around the core technology fee, I believe was what if I am distributing an iOS application outside of the app store.

Then, and solely outside the app store, the only feed that will be applicable if and when that app reaches the 1 million threshold is the core technology fee.

And it's important to emphasize here that the fee begins to incur at 1 million.

So you could have 1 million and 1 apps and you're paying 50 cents.

So I think that's because I think in some of my engagement with developers over the last, you know, frankly, eight weeks since we made this public, there's been some confusion about that.

But we set that as a million threshold for everyone.

There is a question around resources that we're putting into app review and particularly for for notarization.

And I think it's important to kind of understand app review.

App review stands outside of the app store.

It always has and always will.

It's an independent organization within Apple that is focused solely on developers.

It is part of our Apple developers organization.

It plays no role and has no relationship with our business.

Obviously, it's going to have to change a bit now that we're introducing alternative forms of distribution.

And we are having, you know, obviously a much smaller set of rules to apply to notarization.

Then we excuse me do for all app review.

You're right.

The demands are going to increase and we recognize that.

We know we're going to have to increase resources.

We know we're going to have to put more people to this.

One of the issues is we know our people are going to have to start looking at things they may prefer not to.

And so we have to think about how to handle that too.

So we're adding contracting resources.

We're adding a lot of resources to support this new growth that we see through alternative distribution.

The last was the question around.

Oh, this was the million euro or the minimum in its all base threshold.

Again, when we think about alternative marketplaces and this was something we thought about for a long period of time, we wanted to assure that we had credible and accountable operators of stores and we want to have a single set of objective criteria.

We did not want to have special deals.

We did not want to have special assessments because as soon as you do that, you open yourself up to charges of discrimination.

And so what we focused on was what is a set of criteria that we could apply to make sure that the operators of these stores were credible and accountable and responsible.

And those were the two criteria that we established in addition to some of the other things I talked about, which is the other commitments, whether it's engaged and ongoing monitoring of fraud to comply with laws like the DSA or the GDPR to publishing transparent data collection policies.

All these other things are important, but at the end of the day, if you don't have an accountable and responsible operator, then those things mean nothing.

And so what we tried to do, and again, I think I answered this in response to an earlier question, we looked to find criteria that would allow us to have some confidence that the operator is someone we can trust to operate a store in the best interest of our users.

There may be others, and so we welcome feedback about what other criteria could we use to accomplish the goal that we've set out.

So we're going to continue and see how things emerge.

Clearly, it hasn't been an issue for a number of different developers, some of which we've heard from today, some of which we know are out there in terms of being able to secure the line of credit to allow them to enter this program.

Thank you.

I have good news.

We are going to take one round from the room before we're going back to Slido, hands up.

Okay, Jarmi.

Thank you.

Jarmi is one of the Shipstead.

Shipstead is a news organization, and we're distributing newspapers in the Nordic region in Europe, primarily in Norway and Sweden.

And we haven't been able over the last years to sell our news media through our apps because of the transaction fee, which is incompatible with the margin that the news media business makes.

That was the case for many years.

And in 2022, when Apple introduced the Reader app exception or entitlement, we have extended the solution to a number of our brands.

And for the room, this is the link out solutions where you can link to your website in order to sign up subscribers.

And that option was for free.

And so my question is a clarification question on the free of charge of Article 5-4.

And he found this stood correctly at the moment.

And not only the Reader app exception is going to be removed from the new term, so there's going to be less free of charge and not free of charge.

So there really isn't anything free of charge under the new terms.

And in particular, my question concerns the distinction that the commission made in its introduction between existing users and new users.

As far as I understand, the commission read Article 5-4 is making a distinction between customer acquisition and then repeat customers.

And we read that in the same manner, which means that if you manage to upsell some products to existing users, Article 5-4 says it should be free of charge.

But unfortunately, we're not seeing this in the new terms.

So if you could provide some clarification on this.

And for context, I note that in the Google plans to comply with Article 5-4, the distinction exists between existing users and user acquisition.

So it's not just the commission, we seem to have understood that this distinction is in 5-4, but also the other gatekeepers operating an app store.

Thank you very much.

Thank you.

Mike Sacks from the App Association.

It's good to see that there are some alternative marketplaces already in the works.

And we hope to see more from some of the people in the room.

But, and I also think that it's fully in line with the DMA's goals of increasing competition between marketplaces.

But we want this to be a race to the top and not to the bottom.

So quality and transparency around the quality of these marketplaces is very important.

And I'm wondering what the mechanisms will be, both for local, for end users and for developers to assess the quality and the trustworthiness of different markets.

Of different marketplaces.

Thank you.

Go in and some gender balance, please.

Hi, I'm Stephanie Adamson King from Playco.

I'm a small developer.

On web distribution that was just announced recently, this seems like a really good option as an alternative distribution mechanism.

However, the requirements that have been put into place, I'm curious how this actually will be.

Comma competitive distribution mechanism because developers, it's been mentioned earlier, but developers with 1 million downloads specifically in the EU for the prior year.

You have to have that.

In the end, they have to have been in the app store already.

So for a lot of developers, they don't need to build apps.

They can build for the app store, native apps.

They can be distributed through the web.

But this requirement is mandating that those apps have to go now build a native app, apply to the app store, distribute that app through the app store and get a million downloads in a year for that app before they would qualify to be able to distribute on the web through this new web distribution scheme.

So I do understand the need for security and safety.

However, I would go back to why is this different for iOS than on your laptop because these are web-based apps.

Thank you.

And one last one.

Please go.

So I have one comment, Alexander Ruhofskas, he's a Europe.

I have one comment, one short comment and a question.

So to start with what's important to underline is that we should not expect changes to happen overnight.

It's clear that the DMA requires significant changes to gatekeepers business models.

To help companies manage the risks, they should be given time to see what is unfolding.

What is more compliance needs to be seen as an ongoing process requiring a continuous dialogue between the commission, designated gatekeepers and third parties.

And now moving to my question.

In the context of security and safety of users, what measures are guaranteed by the DMA to ensure security and safety of the ecosystem?

Thank you.

Thank you.

Kyle.

There we go.

All right.

The first question related to the 5.4 and 5.7.

So obviously we've made a number of changes to kind of comply with 5.4.

5.4 is focused on promoting and communicating out of app offers from within the app.

And so we announced a plan in January and listened to a lot of feedback over the last eight weeks and made some changes just last week that allows developers to freely promote all of their various offers.

From within their app about what's available outside of the app.

In terms of facilitating transactions and providing alternatives to developers to basically allowed users to purchase from within the app without using Apple's payment processing.

We've announced both the ability to use third party payment service providers.

And so developers can use those today under the new terms without paying any additional commission to Apple.

They can also facilitate transactions through linking out of their app to their websites to transact again with no additional fee to Apple.

In fact, it'll be reduced given that we're only charging for those the first seven days after the the click of that link.

So we provided a number of new options for developers to monetize from within their app.

You know, obviously, as I've mentioned a couple of times, given the significance of the changes to iOS in the app store, whether it's from alternative distribution, whether it's through these other forms of alternative payment I mentioned, or through the promotion opportunity.

We had to rethink the whole business model.

That's a natural consequence of these changes.

And so what we've done is disentangled, disintermediate the three pieces of the value proposition.

So there's the core technology fee, there's the fees associated with distribution, and then there's the fees with the payment processing.

And each one of those we were guided by the principles of ensuring that we had developed a model that was fair, that was reasonable and non-discriminatory, and we think we've accomplished that.

In terms of the second question, I may ask Gary to weigh in here around kind of concerns about, you know, how do you assess the trustworthiness, for example, of third-party app marketplaces or alternative forms of distribution?

We have tried to at least, and this is as far as we could go, we wish we could go further, but we've said at a minimum, an alternative marketplace should publish policies about the content it is carrying.

It should publish policies about its business practices and how it's monetizing its apps.

Now, we're not going to be in a position to police that, but we're hopeful with that transparency, users can inform themselves.

But more importantly, there's a critical role for government to play going forward here.

As alternative distribution becomes a reality, as direct distribution over the web becomes a reality, we need even more resources from consumer agencies here in Europe to address these threats.

We've seen some great activity in the United States going after some deceptive and misleading practices by developers.

We've encouraged that.

That's an important initiative by the U.S.

Federal Trade Commission.

We haven't seen the same level here in Europe.

Obviously, we've been following developments with the Digital Services Act, but we think it's even more important in this new world to have much more aggressive enforcement to ensure that these kinds of risks don't come out.

I think there's a really important role, and there needs to be much more resources dedicated to those efforts.

Gary, anything you would add to that?

Yeah, I think Mike's question was an interesting one.

It made me think of our privacy nutrition labels initiative, in fact, which was something at the time.

I think I mentioned we launched it in December 2020.

We got a lot of positive feedback, including from consumer and competition authorities, because it provided a simple means, true to nutrition labels, and standardized questions and processes and icons for users to be able to assess the relative merits of developers.

We talked this is a great idea.

Users will be able to go and look at it.

But then something very interesting actually happened, which we did not predict, which is that developers started competing with each other in relation to the standards that were outlined in the nutrition labels.

There was a very interesting one I recall at the time, which was Signal, used its nutrition labels in order to demonstrate its relative limited collection of data compared to another gatekeeper, who I will not mention, where its nutrition labels ran off the page.

That was a very interesting example of how the market itself will take over.

I believe happened there is a drove competition in a positive way for privacy.

I think Mike's suggestion is a great one, and perhaps we will start seeing that kind of comparative analysis emerge for alternative app marketplaces.

I'm not sure it's for Apple to start producing those, because some of you might think we would be skewing it in some way.

But I think the market will do it, and I think it might be a very interesting way to, I think Mike also said, drive a race to the top, which is in fact what the privacy nutrition labels also have achieved.

And that actually turns out to be in everybody's interests.

>> Thanks, Gary.

I'm going to answer the fourth question, not only because I need to use the restroom, but I think it related to privacy and security.

I think the third question related to direct distribution of iOS apps over the web.

Obviously, we are much more concerned about this channel of distribution.

Our original plans did not include the ability to enable this form of distribution under the DNA.

We were forced to reconsider that option and introduce it later this spring.

We are, though, very concerned that this creates an additional threat vector, and Gary touched on this in his remarks.

With an app marketplace, there is at least a somewhat disinterested third party who may have incentives to ensure that there aren't dangerous apps, that there aren't misleading apps that place some sort of policing function.

That obviously does not exist when it comes to direct distribution of iOS apps from a developer's website.

I fully recognize that there are hundreds, thousands of well-meaning good developers where we shouldn't have any real concern.

Our problem is the only way for us to validate that is through our own experiences with those developers on the app store, at least as we sit here today.

At least initially, it was very important that we at least had a relationship with the developer that we could go and look.

It's not simply, "Hey, are they part of the app store?"

But we have a history and can look at where they engage in fraudulent activity.

What was their history in terms of creating apps that perhaps presented a risk to iOS?

There may be other criteria.

This is new.

This is a brand new system that we've introduced.

I take your point about the impact on perhaps new small developers.

That's not what we want.

We want to screen out the bad guys, and we all know there are bad guys.

We also want to continue to enable and make iOS an attractive platform for developers of all sizes.

We think, obviously, the app store is a great opportunity to do that.

Third party app marketplaces are an opportunity to do that.

First party marketplaces are an opportunity to do that.

Honestly, I think we've got a lot to learn when it comes to direct distribution of iOS apps over the web.

Gary, I think the last one related to C++.

Yes, Carl.

In fact, I'd already been sitting here thinking this was a bit like riders on the Tour de France in terms of a session.

I thought I should maybe think Pari Rubé would be more appropriate in this context because I took my snack as I went along.

It also then became apparent that riders will relieve themselves while they're on the journey, but Carl had to go and do it.

It all ties together very well from Wifi to view.

I think, to your question, I think it was Alexandra from CCIA.

I think I've called out some of those areas in my earlier remarks, but in my afternoon remarks, they will be amazing, so you should definitely come back for them.

There is a piece there where I will point to Recital 12 of the DMA, which very specifically refers to the GDPR Recital 72, which is a very privacy-focused provision, which encourages undertakings to differentiate themselves better in relation to privacy guarantees, certainly something we would welcome.

And then actually in the clauses of the DMA itself, Article 8(1) encourages and puts a self-standing obligation on gatekeepers to ensure they comply with the GDPR as they're complying with the DMA.

And obviously, there's a bunch of provisions in there on integrity as well, which we obviously take heart from in terms of the steps that we are taking.

I'll try not to read those words the exact same this afternoon, just to make it worthwhile, but it will be roughly along those lines.

Okay, Kyle is gone.

We have one question which is...

We spoke for the whole while we spoke.

Wow, he's super quick.

So, okay, well, so let's move to Slido.

There was a security question just for you, but I had it all planned, so now we can go wider.

We are moving to Slido.

We'll take around from Slido.

Yes, so from Slido we have some questions.

First is from Nik Rodelli from CFRA Research.

He asked, "Does an Article 612 front requirements imply that any IP fee due to Apple for transaction routed through a third-party app store or third-party processor be in the 1/5% range?"

Then we have a question from Bruce Lawson from Openware Web App asking in private capacity.

Why must I pay a core technology fee if my app is installed via an alternative store to an iPhone owned by someone who has already paid Apple a premium for core technology it contains?

Then we have a question from Alisa Cooper from Knight Georgetown Institute.

She asked, "Will Apple conduct user studies to reveal what user understand or fail to understand from the new disclosure screen and publish the study results?"

Then we have a question from Nicholas Baldek.

If I develop a web store app placing Web App's icon on the home screen, will the core technology fee be due?

Will you provide APIs for that?

I assume Gary answered all the questions, but I will come back to them.

On Article 612, I believe that was the first question.

Obviously on its face, Article 612 applies fair, reasonable, and non-discriminatory terms to the app store.

We have gone beyond because we want to make sure that the fees that we establish, even outside of the app store, are fair, reasonable, and non-discriminatory.

We believe that's what we've done.

Certainly in terms of -- I'm not sure I followed the idea that we would charge perhaps 5% of a developer's revenue for core technology.

I think that would be significantly more than the 50 cent core technology fee.

There are lots of different ways to do this, and we studied and thought about them over the last 18 months and tried to develop a framework that allows us to balance all the different interests we had in place, and we think we've done that.

In terms of what the core technology fee covers, again, we had to go through an exercise in which we had to break apart what was an integrated model for 15, 16 years.

We had to rethink how we were approaching this over the last 12 months.

And so when we thought about that bundle of value, again, it's got first and foremost technology that we were making available to developers.

It's the technologies, yes, that are built into the iPhone, but it's also all the tools and services that we've created to uniquely support developers.

It is all the application programming interfaces we've gone from 10,000 to more than 250,000 today.

It's the software development kits that we continue to enhance and build every year, including implementing things like machine learning and other really cutting edge technologies.

I mean, from our perspective, as we approach each new iPhone, each new iOS, we're actually building a brand new product and then making it as easy as possible for third party developers to take advantage of everything we've built into that product.

It is a massive engineering effort, incredibly complex, and takes an incredible amount of time.

So the core technology fee was our means to try to say, okay, how do we place a reasonable fee on this?

And then we said, we actually should go even further because we want to continue to encourage those small developers, those entrepreneurs, those individuals, which is why we set that threshold at 1 million.

And so if you're a small developer and you sell 1 million in 10, or you have 1 million in 10 installs, you're paying Apple $5.

That's an incredible value.

In terms of the questions around user studies and how they may inform various screens, obviously, no, we have our own very long history with our users, and we'll always kind of think about it from that perspective.

In this world, and even before, we're also increasingly thinking about third party studies commissioning our own studies and rethinking our approach.

And so we'll continue to do that, and we'll continue to listen to feedback from our developer community, from other stakeholders, from all the various kind of think tanks and other academics who are really asking some really good questions.

And I think we'll all learn something in the coming days and months.

I think the last question related to web apps on a web store, Apple has done a lot to enable and invest in web apps over the years.

We'll continue to enhance those features and functionalities in the coming years.

So if there are particular things that this developer is looking for, again, I encourage him or her to reach out to us through all the various means that I've talked about in terms of developer feedback forms or requests.

A one-on-one consultation, come to our World Wide Developer Conference.

There are plenty of ways to kind of get your ideas heard and listened to, and I think that question is probably a better place to an engineer than a lawyer, and we'll make those people available.

I think the question, the last one, was what the CTF is due for web apps.

Always keeping me honest, and I appreciate it is not due for web apps.

The CTF applies only to applications that are native iOS apps being built with Apple's proprietary technology that are built using Apple's technology and services and other support that we make available to developers.

It is not applied to web apps.

Thank you for the clarification.

And one last one.

Sorry.

I just come in on the back of the question about user studies.

Kyle is correct.

We are doing a lot there.

But Apple actually is engaged in probably the world's greatest user study on an ongoing basis.

We see our software to users.

We see it to developers.

Our users and developers send us thousands of pieces of feedback every day.

They tell us what they understand, they tell us what they don't understand.

They're not shy about it.

They send emails to Tim Cook on anything that they have a concern about.

He does.

He sends them to us and it changes our day in terms of how we're doing stuff.

But that's what we do.

So I definitely wanted to be clear that we are very active in taking feedback on this, including in forests such as this.

So we are receiving it.

People are not shy about passing on their views.

And we change things all the time.

Thank you.

Conscious of the hour, but also of the fact that you went a little bit over time for the presentation.

I will take three more questions from the room.

Simple questions, please.

Short.

Who hasn't spoken at, please?

Hi.

Max Antoon from the Open Markets Institute, we're at Think Tank.

So my questions are about the core technology fee.

The first one, you talked about it in general terms, but I'd be curious to know what your specific methodology for coming up with it was.

So why is it 50 cents rather than 30 cents, say, or 70 cents?

And how does that cost linked to the specific kind of cost of providing the infrastructure to say, you know, alternative app store operators?

And secondly, would you consider eliminating or lowering the fee if you're presented with clear evidence that it's preventing businesses from growing and scaling in Europe, which is obviously one of the core objectives of the DMA?

Thank you.

Please, only those who hasn't happened.

Thank you so much.

I'm Victor Adeposong from the European Tech Alliance.

We represent European Digital Champions, who all members are born and bred in Europe.

I'd like to go back to the first question asked by Carmen, where you imply that it was not clear how long did you scenarios, so the current Apple system and a CTF one were going to coexist.

I'd like to have a better understanding on when you will assess if you go for one option and what it would mean, because for my members, if they have to switch to the CTF, it has serious business implications.

So I'd like to know more about that timeline and the next steps.

Thank you very much.

Thank you.

Please.

My name is Mike Mandel of the Progressive Policy Institute.

We're a think tank in Washington, D.C.

I just had one comment, which, and so it's actually kind of good coming at the end of this.

We study tech employment, and we've studied it for years.

And one of the things that we've noticed is that the EU had very fast growth of app related employment over the last few years, up more than 50% since 2019.

And I'm sort of hoping that under the new DMA related changes that this growth will continue.

I think one more, because the questions were really short.

Can I ask Kyle?

You can do it.

Please.

So Mark, you see.

Mark, you see with Matt's group.

One, we want to thank Apple for being a good partner.

You have been a good partner, continue to be a good partner, continue to give us access to users.

So we appreciate all that work and what has gone into it.

We really need business certainty.

And this dual approach that Apple has today does not give us business certainty, which makes us deciding how to proceed difficult.

And certainly we think when it comes to compliance, it's something that the E.C. has to look at, which is if it's difficult for businesses to do this, that's not an indictment of the DMA.

It is a decision based off of what has been proposed by Apple.

So anything that you can clarify around that.

Speaking on behalf of match, we do support the idea of a CTF as an acquisition fee.

But again, when we look at acquisition, every developer needs acquisition.

So the way this is currently structured, again with some companies, some developers being able to use an old system versus a new system, you don't have any kind of certainty there.

Also wanted to just point out or raise a question around when you say, and we appreciate this a lot, no special deals.

There is still or special considerations.

Apple is making determinations on what is digital and what is not digital and why that is different.

And the reaction, we believe this and have said this publicly, we think we operate the same way that Uber does.

But due to an artificial comment, decision by Apple, we have to pay fees that they don't necessarily, and none of that is franned.

And all of that makes our next decision on what we do quite difficult.

Thank you, Kyle.

All right.

We have the first question related to core technology fee and how we set it.

So as I said, we went through this exercise in which we tried to account for all the various value sticks that we put into a bundle over the last 15 years and price them separately.

We've talked about the commission that's applicable to App Store and Discovery and distribution.

If you use IEP, there's a payment processing fee, and of course there's this core technology fee.

Again, we approach it from a value perspective.

And so we, as I've said, invest significant sums.

We've spent tens and tens of billions of dollars over the last 15 years to make this device.

And we spend more every year to make the next device.

If you think about what the iPhone 15 is compared to the first iPhone or even the fourth iPhone, they're completely different products.

They have different capabilities, they have different technologies, they have different functionalities, and it reflects an incredible investment.

And so as we approached this problem, we thought about it.

We said we can actually charge more for this.

But we ultimately concluded that we wanted to set a fee that we felt was fair, reasonable, and continued to encourage investment by all developers in our platform.

And we think we've accomplished it.

We'll learn more over time.

I certainly understand the concern that you voiced, and certainly something we'll continue to monitor because we want to see new apps, we want to see innovation.

And I think you've seen that reflected in how we managed the Commission over the last 15 years.

We've never increased our price in 16 years.

We set a commission structure 16 years ago, and then all we did over 16 years was reduce it.

We introduced things like the reader rule and the multi-platform rule, which allowed developers to avoid paying the commission altogether under our traditional terms.

We introduced a number of different programs that allow developers to apply for a commission that was at 15%, not 30%.

And so that's always been part of our ethos as we've approached the developer community.

We want to encourage developers to create, we want to encourage innovation on our platform.

And so we'll learn how this works over time.

Like I said, we were basically forced to kind of draw on a blank slate, and this is what our effort was.

And we spent a lot of time thinking about it, and we spent eight weeks, nine weeks talking to developers and other people like yourself to understand what did we miss.

And I'm sure we'll learn more things over the coming weeks and months.

And obviously we're concerned about some of the issues around dreamers who think, what if my app takes off and I suddenly own a huge amount of money to developers.

That's something we're thinking hard about.

We want to Apple, sorry.

That's something we're thinking hard about how to solve.

So I would simply say this is something we're all going to learn from.

And we're going to approach it from a perspective of we want to continue to encourage innovation and investment, whether it's here in Europe or around the world.

In terms of the questions around choice between our core technology around our traditional business terms and the new business terms, how long it will last.

Again, this is an area where we're in active listing mode with our developers and with the commission.

We believe that choice right now is the right approach to ensure as we move through this period of significant change.

And as I said earlier today, this is the most significant set of changes for the iPhone and for the App Store in its entire existence probably.

We have made such, at least in terms of the business terms, we recognize that.

As I said earlier, we're constantly reinventing the iPhone each and every year and introducing new technologies.

But this is the first kind of business change that we've introduced.

And so we think it's important in this period to provide choices and think through and listen to developers in the commission about what the right path is going forward.

I fully take the point that was made around making sure that iOS and the App Store continues to be an opportunity for developers and for employment and for creativity.

We know there's so much work that's out there showing incredible explosion over the last 16 years in terms of software development, which has translated into great benefit to people actually investing in businesses, creating businesses, to employment here in Europe and around the world.

We don't want to see that disrupted either.

We hope that this leads to more investment, but we don't know.

There are risks here.

And I think we have to take a very careful look at to see what happens over the next months and years.

MASH, I appreciate you have been a great partner over the years.

I know we have our differences from time to time, but we've always been proud to have MASH in all your various apps on the App Store around the world.

Again, we're going to continue to kind of listen to our developer community.

As I said, I understand this is a disruptive period for all developers, whether you're the super successful billion dollar developer or the smaller developer.

And so we've got to balance all those interests as we kind of move forward.

And so we're not a company.

We're comfortable saying no to even our biggest partners if we feel it's the right thing to do for our overall ecosystem, whether it's our users or whether it's all the developers that we work with.

And so we're going to continue with that balance, but obviously happy to take ideas and feedback that you might have about what we can do differently.

And I know your teams have been in touch with ours, and so we really appreciate that.

Thank you.

Thank you, everyone, for this marathon.

Thank you, Kyle, Gary.

Also, thank you, Brandon, although you are having a visit.

Thank you to the room for the engagement and also to slide on.

So we are 10 minutes over time as compared to the agenda, but these 10 minutes are not going to be taken from your lunch break.

So we'll be back here at 210.

We are taking it away from our own presentation.

As you've seen, we are very quick in presenting and setting the scene.

So we will finish the next session on time.

So 210, please back, but please be on time.

Thank you.

[BLANK_AUDIO] [BLANK_AUDIO] [BLANK_AUDIO] Please, but it doesn't work.

[BLANK_AUDIO] Can we please take the seat?

There will be another coffee break later.

[BLANK_AUDIO] Thank you.

You guys now follow the time allowed.

[BLANK_AUDIO] Well, you want me to follow and speak 10 minutes about that?

No, I'm not following my time.

[BLANK_AUDIO] Actually, very kind.

[BLANK_AUDIO] [BLANK_AUDIO] Take your seats, please.

We are about to start.

Sasha, you're not listening again.

Down.

See that works.

That works.

Unbelievable.

Very good.

All right.

So welcome back to our first afternoon session.

I hope you have the same energy as you had in the morning.

So we are going to discuss equally important provisions.

So the session free is dealing with what we call vertical interoperability and tying the relevant articles of the MA are 6, 7 and 5, 7.

So quickly to introduce the provisions, 6, 7 is what we call vertical interoperability provision.

Under this provision, gatekeepers shall allow free of charge, effective interoperability with the same hardware and software features, access or controlled via the operating system, as are available to or used by the gatekeeper.

Gatekeepers can take strictly necessary proportioned measures to ensure that interoperability does not compromise the integrity of the operating system.

The Article 5, 7, so-called untying provision, gatekeepers shall no longer require end users and business users to use to offer or to interoperate with an identification service, web browser engine or payment service of the gatekeeper in the context of services provided by the business users using the gatekeepers core platform services.

So we have two provisions and now I will hand over to Apple to present their compliance measures taken to comply with these two provisions.

I already made a mistake.

Good afternoon everyone and thank you Lucia for bringing us all back together promptly.

I hope everyone found something to eat during a break and probably more importantly a coffee or two.

Perhaps it's just me but I needed it after this morning.

In this session we're going to talk about what we're doing on Article 6-7 interoperability.

Apple has focused on responsible and careful opening of iOS to developers for nearly 15 years now.

We enabled developers to leverage powerful technologies we've engineered into iOS and iPhone including more than 250,000 application programming interfaces, 40 software development kits and much more.

This allows developers to build ever more powerful apps.

Developers can use tools like HealthKit to integrate sensitive health information in a private and secure manner.

That means people like me can use their Peloton app on their iPhone to work out in their hotel room and the app can show them the heart rate information from their watch.

Developers can use CarPlay to enable their apps right under users' dashboards and it can use the camera and microphone to let users record content right from their app.

Apple has invested substantial time and resources in ensuring that third-party software and hardware work on iOS.

A rich ecosystem of apps and accessories play an important role in the success of iPhone.

Many of Apple's existing interoperability solutions are the result of Apple's proactive efforts to make iPhones technology and features available to third parties.

These efforts will continue.

Interoperability will always be an essential design principle as we develop new releases of iPhone and iOS.

And our door has always been open for developers to ask questions and share feedback or suggestions.

Apple teams talk to thousands of developers each and every week.

We also solicit feedback through our Apple developer forums and feedback assistant.

The iPhone has been around for a long time now.

And each year we reinvent it to introduce new technologies, new features, and new functionality.

We do our very best to ensure that developers have the ability to access these new innovations safely.

Our approach has been careful.

We err on the side of protecting the user when opening up access.

Building on these efforts, as we announced in January, Apple has enabled alternative browser engines on iOS.

We have also announced plans to enable developers to use NFC technology for contactless payments in their wallet and banking apps.

These were big changes.

And each one took more than a year to build and implement.

Interoperability engineering is complex and requires real care.

We've also launched a new dedicated process for developers to submit DMA related requests for additional effective interoperability with iOS and iPhone.

And we're glad to see that developers large and small have already started to make use of it.

All developers have access to this same process.

While I'll come back to alternative browser engines and the use of NFC contactless payments technology in just a few moments, I want to ask Brendan to describe this new process for developers to submit interoperability requests.

Thanks, Kyle.

Here's how it works.

Apple is evaluating developer iOS interoperability requests on a case-by-case basis to assess whether they fall within the scope of the DMA.

If so, Apple will provide access to an effective interoperability solution if one can be supported and does not already exist.

Such solutions will then be available in future updates to iOS.

Let me walk through the new process for interoperability requests in more detail.

First, we conduct an initial assessment to examine whether the request falls within the scope of the DMA.

As just one example, requests for features that don't already exist in iOS aren't within scope, so please don't use this process to ask us to turn the iPhone into a jetpack.

Second, if the result of this initial assessment is that the request may fall within the DMA scope, Apple assesses whether effective interoperability, in fact, already exists.

If it does, we want developers to use the many tools and technologies we already provides that they can innovate and grow.

If effective interoperability doesn't yet exist, we will assess whether we think we can offer an appropriate solution.

If so, we'll create a tentative project plan.

We consider multiple factors when we assess effective interoperability solutions, including any iOS or iPhone integrity issues that the solution may raise.

If Apple determines that it's not feasible or otherwise legally appropriate to offer an effective interoperability solution, we will let the developer know.

Third, and finally, if an effective interoperability solution is feasible and appropriate, Apple works to provide that solution.

If an app network is highly specific to each request, it will notify the developer when that request is addressed in a pre-release or software update.

We will release relevant technical documentation, too.

Apple has been pleased to see so many developers already engaging with this process since we launched it in January.

In some cases, we are already at work exploring effective interoperability solutions.

Some have asked whether all developers will have access to interoperability solutions that Apple develops based on a DMA request, or if that's something that's going to be limited to the developer who made that request.

The answer is that, as a general principle, access will be generally available for use in the EU.

That said, some interoperability solutions may be available through and subject to management entitlements.

For reasons, Gary will discuss in a few minutes.

But even in that scenario, all developers who meet the clearly established criteria for the entitlement will have access to the interoperability solution.

Of course, the integrity of iOS is always among the most important considerations for Apple, and that will guide whether management entitled is necessary for a particular solution.

We've heard questions about whether these functionalities will also be made available elsewhere in the world, and there may be cases where we offer new solutions on a broader basis or offer them incrementally in other jurisdictions after evaluating our experience in the EU.

Some of you may be wondering why this process is even necessary.

While Apple is always coming up with new ideas for interoperability, this DMA-specific process is designed to enable developers to bring any request for effective interoperability to our attention that we don't address in the normal course of business.

We believe that having a process that allows developers to submit specific interoperability requests that reflect what they actually want their apps to be able to do will allow us to best implement the DMA's interoperability provision.

This, of course, will work side along with the announcements we've already made on January 25th, as well as all of our pre-existing work on interoperability.

I'll turn it over to Gary to talk a little bit more about the motivation behind our approach.

All right, thanks very much, Brendan.

We've been asked why Apple can't just turn on all APIs that are available to Apple itself for third-party apps.

It's been suggested that this would be the most straightforward way of complying with the DMA.

But the idea that there's a simple magic solution out there in which Apple can press a button and make every API available to everyone without compromising the integrity of the platform and the vice is just not the reality.

And I don't think that anyone who is serious about security and integrity of a platform would ask for it.

Here are a couple of examples.

First, to ensure your phone runs properly, iOS manages how much processing time and power all applications get.

If you let an individual application control that allocation, then any selfish application would ensure that it got all the time it wanted, and you might not be able to receive an important incoming phone call or get an urgent push notification.

Or, as another example, the act of making phone calls requires the use of APIs that tell your cellular radio to send low-level signals to cell towers.

If any app had the ability to send those low-level signals, they could actually wreak havoc on cell networks.

Of course, wearing a developer, including Apple, is using an API that accesses a protected resource like location data, camera, or microphone, iOS requires them to request and obtain permission from the user before the API will work.

And that is what you'd expect.

And our managed entitlements mean that we put up some guardrails on the kind of apps that can access a user's sense of data.

For instance, for health data access to HealthKit, the entitlements help ensure that only apps that are using the data for providing health, motion, or fitness services have access, and certainly not for advertising or profiling purposes.

If we just opened up all APIs, we'd expose users to the risk that anyone, including bad actors, could access these sensitive data and resources without permission.

Again, I don't believe that any serious person who cares about user trust and device integrity would ask for that.

We built a new interoperability process around the idea of creating a mechanism for a real dialogue between Apple and developers regarding interoperability.

And so far, it's working.

We've already started working on requests that we received after the 25th of January and have notified a number of developers that we are starting work evaluating the specifics of potential solutions that address the requests.

Developers have been actively engaging with us, including by responding to our notification by sharing additional information relevant to their requests.

And everything I know about this company assures me that we will, in keeping with the DMA, approve legitimate requests that do not pose serious risks to the integrity of iOS and the iPhone.

At the same time, let me just add, and you would expect me to say this, but it's still very true.

The risks to safety, security, and privacy are real, providing toward parties with unfettered access to every part of every EU user's iPhone, would unquestionably compromise user privacy and security.

We have a responsibility to our users to ensure that our platform remains as safe, secure, and private as it can within the structure of the DMA.

With that, Kyle, I'll turn it back over to you to talk about alternative browser engines.

Great.

Thanks, Gary.

In addition to our ongoing work on interoperability, as I mentioned earlier, developers can now use alternative browser engines in iOS 17.4.

That is, browser engines other than WebKit for browser apps and apps providing in-app browsing experiences in the EU. iOS 17.4 introduced new capabilities to facilitate this change.

In both browser apps and non-browser apps, embedding alternative browser engines can request entitlements to access these critical functionalities.

All apps with one of these entitlements, including both browser apps and non-browser apps embedding alternative browser engines, will have access to a set of iOS APIs that are necessary to render web content.

That means users of those apps will be able to engage with web content through in-app browsing optimized by the developer's choice of browser engine.

And browser apps have access to even more to reflect their unique role.

Browser apps embedding alternative browser engines have access to frameworks that offer features relevant in the context of browser apps, including multi-process support and just-in-time compilation.

Gary, let me turn it back to you to talk about some of the protections we're implementing here.

Some developers have asked why we're requiring developers who want to embed alternative browser engines to request and get entitlements before they're allowed to do that.

That's because browser engines are constantly exposed to untrusted and potentially harmful content on the open web and have visibility to sensitive user data, and they're one of the most common attack vectors for bad actors.

This is well-documented and fully known in the security community.

So we need to make sure, as much as we can, that the browser engines that run on and integrate with iOS will help keep users secure.

That's why they need to commit to a number of ongoing privacy and security requirements, including timely security updates to address emerging threats and vulnerabilities.

We expect browser vendors to have a certain level of web standard support, pledge to fix security vulnerabilities quickly, and protect the user's privacy by showing the standard consent prompts for access to things like location.

We're confident most, if not all, major browser engines are already largely compliant with these requirements.

We're only asking that alternative web browser engines meet standards that iPhone users have come to expect.

Thanks, Gary.

Let me also address a few other common questions on this subject that we've seen from developers and other stakeholders.

We've heard from developers of browser apps who want to use alternative browser engines and who have expressed frustration that they will need to maintain two versions of their apps, one for the EU with an alternative browser engine and one built on WebKit for everywhere else.

Our goal is to facilitate a thriving app ecosystem, which is what we've done since the launch of the App Store.

We compete hard every day with other platforms to make developers want to choose to build for iPhone, but we'll never do that in a way that sacrifices the security, privacy, and safety of our users.

And we continue to believe that the WebKit requirement best protects users, which is why we're going to continue to require it outside of the European Union.

To be clear, we comply with the law in every jurisdiction in which we operate, and differences in the law sometimes require different approaches in different jurisdictions.

That's expected, and it's happened before.

This may be the first time that browser apps have encountered this, but it's certainly not the first time it's ever happened on iOS.

Let me say a little bit more about why we're keeping the WebKit requirement outside the EU.

There have been real advantages to having all iOS apps use a common WebKit install.

As just one example, it has allowed Apple to distribute important security updates to more than 1 million apps rendering Web content in a single update.

So we think there are still a lot of really good reasons for this policy.

One last area where we received a lot of questions is home screen Web Apps.

So let me address that now.

When we rolled out support for home screen Web Apps through WebKit, we knew it was essential to do so in a way that aligned with the security and privacy model for native apps on iOS.

That includes sandboxing and the enforcement of system prompts to access sensitive private capabilities on your device, like the microphone, the camera, or your location on a site-by-site basis rather than on a browser-by-browser basis.

Without that kind of protection, harmful Web Apps would be able to read data from other Web Apps and use their permissions to gain access to extremely sensitive user data without the user's actual consent.

We built a completely novel architecture in order to protect users from these threats.

And that architecture is necessarily integrated deeply between iOS, its underlying functionalities, and WebKit itself.

To create those protections for home screen Web Apps powered by alternative browser engines, we'd have to build an entirely new integration architecture that simply does not exist on iOS today.

And that just wasn't practical for us to do, especially given all of the other requirements of the DMA.

So we decided, out of an abundance of caution, to remove the home screen Web Apps feature in the EU with iOS 17.4.

After that rolled out in the beta, we received requests to continue to offer home screen Web Apps through WebKit.

I'm sure some of you in this room were among those asking for us to do this, and we listened.

So the existing home screen Web App capabilities remain available today.

Let me turn it back over to Brendan to wrap up with an explanation of what we're doing on NFC contactless payments.

Thanks Kyle.

We have also announced new DMA compliant APIs for developers to support NFC contactless payment transactions from within their banking or wallet apps using Hostcard emulation or HCE.

This is a software solution that is similar to how Android supports third party NFC contactless payments.

Users will be able to initiate payment transactions from a third party app at compatible NFC terminals.

Users will manage their preferred default contactless payments app through a new setting in launch the default app by double clicking the side button or when an iPhone detects an NFC field at compatible terminals.

Wallet and banking app developers are responsible for certain industry and regulatory requirements, including licensing regulations and security standards.

As a result, in order to access and use these capabilities, developers must request an entitlement and commit to ongoing security and privacy standards.

This ensures that only authorized app developers who meet the appropriate requirements and are committed to keeping their contactless payment apps secure and private can access these APIs.

Thanks Brendan.

I know there's probably a number of people who have questions, so at this point I'll turn it back over to Lucia so we can start to have my nose.

Very good.

Thank you very much for the presentation.

So I'm turning back to the room.

I will just recall rules of engagement in case you forgot over lunch or in case some new faces are in the room or on the slide.

Before speaking, please state the name and the organization we represent that this valid also for slide participants.

We will not read aloud questions which are sent from anonymous.

Keep your intervention short and clear, maximum two minutes.

So even if it's feedback, please try to be disciplined.

Keep it relevant on the topic.

So let's focus on what is at stake in this session.

If there is anything else you can always send a submission to the commission to our ECDMA mailbox.

Please try to keep it one question per intervention.

Otherwise it's difficult to follow and it's really testing Kyle's memory, although he's been doing very well.

So maybe we can challenge him further.

We will try to make sure, I mean, you can ask twice a question if there is room for that.

Otherwise we will try to give opportunity to everyone.

And of course, let's keep it civilized and constructive as we've been doing until now.

So with this, I'm opening the floor for the room.

Please raise your hands and we will take four questions.

Please.

Hi, John Asbe from Open Web Advocacy.

I have one question and a little bit of context to fill for that question.

Apples 15 year ban of third party browser engines has effectively removed browser competition from iOS.

This prevents any browser vendor from significantly competing on features, stability, security or privacy as evidenced by their 90% market share on iOS compared with their 48% market share on Mac OS.

Apples compliance proposal in respect to browsers is unworkable in three major ways.

First, Apple is geo restricting browser competition for iOS to only the EU while Apple remains exempt from this restriction.

They can use their engines everywhere.

Minutes ago, Apple has just claimed that the reason for not allowing browser competition globally is security.

But when Apple claimed that their browser engine security was superior to rival browser engine to the UK regulator, the regulator found that there was no substantial evidence to support Apple's claim.

Second, Apple is asking browser vendors to create entirely new browser apps only for the EU rather than update their existing apps or offer a different version of their app for their users in the EU.

This will force browser vendors to ship a new separate app and lose all their existing customers as a result.

If Apple wishes to insist on gaining browser competition to only the EU, they need to allow browser vendors to ship two bundles under the same app ID.

One for the EU and one for the rest of the world.

That way, EU residents can simply receive a browser software update and start using the real browser engine powering the browser as soon as it becomes available.

Apple needs to then let browser vendors ship a dual browser, which can be configured to use either the WebKit WebView or their own engine of choice.

This is to allow browser vendors to phase in their browser and do A to B testing.

Apple explicitly prohibits this in their API access contract for browsers and so we'll need to remove that rule.

Apple has not provided any security justification for such a rule either.

Every other operating system has always let browser vendors ship real browsers using their own engines.

Every other one.

Effectively banning all other browsers other than their own on a major operating system is unique to Apple.

Third and final.

Apple has a new browser engine entitlement contract for competing browsers that is full of non-security terms and a number of astonishingly unfair and unjustified terms.

Apple's browser engine entitlement contract is literally a contract for API access.

Importantly, this is for all browsers and I.S. including ones outside the App Store.

Article 6.7 states that the gatekeeper in this case Apple is only allowed to make strictly necessary proportional security measures.

This means all non-security rules that are in the browser entitlement contract needs to be stripped from this contract for API access.

Some of the non-security rules could be moved into Apple's App Store rules although some are so ludicrous that it is not clear that they will survive the fair aspect of FRMD.

Some interesting clauses from the browser entitlement contract and these are merely the best ones by the way are Apple can break or remove any API at any time with no notice.

Apple can reject their browser for any reason at its sole discretion.

The browser vendor agrees to follow all rules in the delightfully vague Apple materials which Apple can change at any time and if you break any rule in Apple materials which is not defined Apple can permanently remove every single app of your company.

Distributed on any Apple platform including macOS globally.

None of this is a joke.

It is what's actually in the contract that has Apple published by Apple.

This is not a contract produced in good faith.

So Kyle O'Brenden, given how unfairly browsers are treated globally by Apple on iOS, will you at least make them minimally viable in the EU by enabling browsers to ship their own engines under a single app ID and rewrite your contract so that they're both reasonable and compliant with the DMA.

Thank you.

Hands up.

Please.

I'm Eurepika Koleva from the European Games Developer Federation.

So ability to manage subscriptions on device level and parental control tools to manage in app purchases for children are very much operating system features.

Although Apple does not process the payments, it would not be a major technological challenge to include an interoperability with this feature allowing the subscription management and the parental control tool settings on the device level.

Still, you are very clear on the fact that this is not possible.

Could you please describe a little bit more what's the main reason for this.

One would assume that interoperability with these kind of features would actually strengthen the safety of the users.

Okay, please.

Thank you.

Benio Miniat, Guardian Project for Background Developer of Onion Browser.

Currently for background currently Apple, the APIs Apple provides currently are making onion browser insecure.

I would love to change to another browser engine.

But as far as I understand the APIs, Apple forces onto engine developers seem to be a huge hurdle for systems which are developed for over 20 years.

How can you justify that?

Thank you.

Thank you.

So we have heard a dishiving on Thalo from Aspiegel.

We have heard many times today Apple claiming that Apple security is great.

However, when you look into the top security companies in the world, the top 50 Apple is not in the list and some of these companies have an app store.

So that explains the reason why last month there was a Trojan on iOS stealing, facial recognition and stealing Mac accounts with it, how solar winds infected 128 million devices of Apple and so on.

It's normal.

It's not about doing it.

App Engine is a good job.

It's just not enough.

So my question is, since the only way to interact with the iOS is through the core technology of Apple and some companies are arguably better at security than Apple.

Despite the claims we heard today, is Apple intending to create a monopoly of middleware by only allowing their own core technology blocking better security solutions from implementing better security for your own users?

And second, if the Apple core technology is the only way to interact with the operating system, how you plan to comply with the obligation of 6, 7 of making that core technology of interoperability available for free and not for a core technology fee?

Thank you.

Kyle, over to you.

So I think it's always important to place some of these questions into context.

And as I mentioned earlier today, when we designed the first iPhone almost 16, 17 years ago, you know, obviously the browsing experience was core to what we were seeking to do in that first iPhone and that first operating system.

And so we spent a lot of time engineering a browser engine into iOS.

And we wanted to do it for a couple of reasons.

One, obviously there were concerns about security and privacy and safety when it comes to browsing.

We were well aware of the risks that it emerged and developed on other platforms, and we wanted to make sure that we learned and drew upon that experience.

And so we deeply integrated the browser engine into iOS.

It was also critically important from a performance perspective.

You know, Apple has always stood for the idea that if you marry hardware, software, and services, you'll result in better products.

And that's across safety and security, but it's also in terms of performance.

And so, again, we're talking about a mobile device that would be in the pockets of hopefully millions and tens of millions and now hundreds of millions of people.

And so we wanted that browsing experience not just to be safe and secure, but also to make sure that the device worked as it's intended.

And for 16 years it's worked.

It's worked.

There has not been any specific attacks through the WebKit.

We have managed to update that.

As Gary mentioned, I'll ask Mattalk a little bit about this in terms of some of the ability to quickly update it to respond to threats.

You know, I think what sets us apart from kind of third-party browser engines is the fact that we have built this system.

We've enhanced this system.

We continue to marry all of these things together.

And that integration has resulted in a better product that I don't think is going to be replicable by third parties.

Now, we obviously had to undergo a very massive, complicated engineering effort to tear this apart, and we rewrite the operating system to rewrite the browser engine.

And we had to make decisions and calls about how to create a suite of APIs to enable browser engines.

And that's exactly what we've done.

I think over time we'll probably continue to enhance that and develop it as we learn, because this is something we never anticipated for this product.

Never.

And we don't know how it's going to turn out.

Hopefully there won't be any problems, but I doubt that's going to be true.

Our experience tells us otherwise.

But there will inevitably be challenges.

Gary, do you want to talk a little bit about some of the security issues?

Yeah, probably just a little bit.

I think the security threats that we have been pointing to are real and documented.

I don't think these are Apple findings.

I believe there are many researchers out there that have shown that browsers are a way to attack users and steal their data.

Just on experiences that we've seen in other platforms, and it's not a single amount, we did do some research of browser apps on the Google Play Store this time last year, apps that had more than five million downloads.

What we saw is that nine of those were not up to date, and one which had more than a billion downloads was last updated four years prior nearly in October 2019.

By contrast, because of the way in which WebKit operates, all browsers operating on WebKit on our platforms were updated as of February 2023.

I just don't think we should underestimate the real security benefit that is bringing for users to be able to release those kinds of updates.

We have actually also now deployed a new feature as part of iOS called Rapid Security Updates, which allows for updates to be deployed immediately to user devices in the case of critical security exposures.

We have had at least one of those for Web engines.

In terms of the question, there was a question I think about parental control apps in the availability of third-party services.

There's a number of third-party apps today that manage and offer parental control apps.

We provided APIs for them.

We continue to enhance those going forward.

I think as we enter this, just kind of picking back up on the browser engine, because I know there are a couple of questions around that.

Obviously, this is an area that will continue to develop and enhance over time.

I think we'll respond to threats as we see them.

We are taking an approach that we think has the user first and trying to be as careful and deliberate as possible as we create this.

Again, this is something that's brand new.

This is something that was, from our perspective, never meant to be separate from the operating system.

We've had to do some radical changes here.

I will say the proof is kind of in some of the studies we've seen.

There is a suggestion that somehow our platform doesn't appear on the top most secure platforms.

I guess I haven't seen those studies.

Every study I've seen has said iPhone is the most secure, is the most safe mobile device or computing device in the marketplace.

That's consistent over and over and over again.

We have not had to offer third party or first party security services or applications on iPhone because it's built in.

It is intended to be as secure as possible.

Now, we're entering a world where there's going to be less security.

Ironically enough, users may have to pay for additional security from third parties.

We'll see what happens.

But to date, that hasn't had to happen because we've delivered on that promise year after year after year.

Thank you.

We do another round in the room.

Please go.

Yes?

Yeah, the every separate game is just being up in the question at the end, which have made things answer them.

And just interested in how the core technology can be reconciled with six, seven, which necessitates access to the operating system, pre-emchildish.

But also today, you've sort of cited APIs and SDK, quantum schools, and it's the HANA OS, which I believe will be captured by the operating system in the hardware.

I wonder if there's anything else in that seat or could take it outside for me a bit of that.

I don't know if you could specify what that is.

Thank you.

Please.

Hi, League, Sam and the European Banking Federation.

First with some background.

So we see that with the widespread and growing use of mobile devices for the provision of financial services, access to functionalities such as NFC directly impacts the ability of third parties to distribute and to scale financial services products in a fair and equitable way.

And also if we're looking forward with the adoption of the Instant Payments Regulation and a future possible digital euro, we really see that this base is going to continue to change and to innovate.

So access to NFC is very welcome.

But also there's other functionalities.

And if I look at recitals of 56 of the DMA, others are mentioned such as this secure element and authentication mechanisms.

And I really want to stress also the access to the secure element.

So given that Article 6.7 says that the access should be provided to the same hardware and software features, accents are controlled via the operating system.

The gatekeeper wanted to ask how will you roll out the access when it comes to the secure element in particular.

Thank you.

Thank you.

Hands up, please.

Thank you, Jan Penfert from European Digital Rights.

Is it admissible that I give my speaking time back to the to refer to the questions that the colleague from the Open Web advocacy had asked about the contracts and the possibility that those are incompatible with DMA because those haven't been answered at all.

Maybe I can refer back to that if that's possible.

One more, please.

Yeah, thank you, Jean Burris from the Coalition for App Fairness.

Following up a little bit on the free of charge language in 6.7 that seems to have been ignored.

And I think it's particularly important to put that into the context of 6.7, which is to enable fair and contestable competition in the vertical sense.

So where Apple is offering a competitive solution on its own platform, ignoring the free of charge language would seem to defeat that purpose in that a developer that is forced to turn over all perhaps in some cases even more than all of their profitability to Apple just for the privilege of competing on their platform means it will never actually be competitive.

It feels a lot like we've done vertical integration in the past thanks to the commission in some respects back when Microsoft was forced to provide interoperability with respect to browsers, media players, server protocols.

And it feels like Apple is attempting to impose a new solution that would have been the equivalent of Microsoft demanding of Apple in 2004 that it pay Microsoft 30% of its iTunes revenue when it put iTunes on Windows, which of course I have a pretty good idea how that would have been met by the commission at the time.

So question about that.

And then the second follow up to that is on this idea that instead of just publishing the accessibility information for your vertical apps use, you're kind of introducing this ask and work it out approach which seems a little also inconsistent with the idea of competition and contestability in that you're asking your vertical competitors to disclose to you their product plans and their product features before they're even introducing them.

Perhaps there's some strict protocols within Apple that prevents that information from ever leaking to anyone involved in the product that would seem to be untenable.

Thank you.

Kyle.

Great.

So as I mentioned in our remarks, Apple has consistently invested an incredible amount of engineering time and effort to facilitate interoperability for our developer community.

We've gone from 10,000 APIs to 250,000 APIs today.

We have invested tens of billions of dollars in technologies and functionalities to build out the iPhone.

We've invested hundreds of millions of dollars, billions of dollars in creating tools and services for our developers to make it incredibly easy whether you're a multi-billion dollar corporation or a small individual entrepreneur trying to create a new iOS app.

And so these investments have gone on for 16 years.

And we don't understand the DMA to say suddenly all of those efforts must be given away for free.

The focus of the DMA is on providing interoperability where there's something lacking and ensuring that you're not trying to put a developer at some sort of competitive disadvantage.

And certainly I don't think anyone can look at the core technology fee.

There's nothing discriminatory about it.

It's applicable to every single developer in our community.

There's no focus on a particular technology or feature or service.

So from our perspective, it's fully compliant with both 6.7 and with 6.12.

There are some questions around NFC access and perhaps the need for additional forms of access.

Obviously we continue to evaluate those.

We think we've addressed the vast majority through the NFC solution that we've put forward.

We'll see if that's ultimately adopted and embraced.

We may have to pivot to something else.

I think a lot of different things are on the table in terms of trying to figure out how we ensure effective interoperability with a set of technologies.

Particularly, the NFC is one thing, but I think with the secure element and authentication, that's an area in which you're really starting to talk about some concerns around security and how that could be misused.

So there are some real difficult questions that we have to tackle with respect to those particular features and functionality.

In terms of the terms that we've applied to browser engines, we address that in our networks.

What we're trying to accomplish is to make sure that we have a set of terms that provide for a minimum set of standards that ensures that whatever emerges in terms of third-party browser engines doesn't compromise the integrity or security of iOS.

Something we've invested in for now 16 years, something we know very deeply and have a deep understanding of given it's the product we've created.

So we think the contracts in terms are reasonable.

They are designed and intended to ensure a basic minimum level of performance and of security.

Looking at the last thing I would simply say in terms of interoperability, iOS managing and operating system is an incredibly complicated engineering task, particularly, even more challenging when you're talking about hundreds of millions of users and millions of developers all using this system.

And we're constantly seeing new threats emerge each and every day.

And as we've said, we take a conservative approach when it comes to opening up access.

If you think back to the original iPhone, there were no third-party applications.

We did that because Steve and others were really concerned about what would happen to the device, what would happen to the security promise and the privacy promises.

We made to our users if we opened it up to third parties.

That's why that first software development kit only had 10,000 APIs because we were so concerned.

Now over time we've opened it up 10,000 to more than 250,000.

That's enabled an incredible amount of innovation over the last 16 years.

As Gary mentioned in his remarks and perhaps he wants to elaborate upon them, if we were suddenly just to switch on and become a totally, any developer could do whatever they want with whatever technology it would break the iPhone.

It would break.

It cannot function that way.

No operating system can.

I don't know, Gary, if you want to say anything further.

Yeah, a few points.

Thank you, Kyle.

I think I'll start with Jean's question.

I think it's kind of similar to the earlier question in relation to Article 6(2) relevant data, so interoperability requests.

Absolutely alive to that we are very conscious of how any data of that nature will be handled.

It is being tagged.

It is restricted from who has access to it and the circumstances.

Hopefully that is conveying to you that we are very conscious of these obligations under DMA.

I hope is not a reason why people will feel in any way inhibited from making interoperability requests.

As I said in my comments, we are very much open for business for those.

In terms of access to the secure element, that is at the core of the security of iPhone.

There are many good reasons why we heavily restrict what can and cannot access the secure element.

Many Apple services also do not have access to the secure element.

A security engineer, I'm sure, could set it out in more detail than I would.

I would, however, point out that TouchID and FaceID have been available to third-party developers as a means of authentication since we actually rolled them out.

The user can engage them and I know that there are many third-party apps who are using those for authentication on the device.

Today I know I must accuse them across a bunch of apps that I use to sign into myself.

Thank you.

I propose we take questions from Slido.

Yes, indeed.

We have some questions from Slido.

So we start with the first question from Alisa Cooper from the Knight Georgetown Institute.

She asked, "Will Apple publish a transparency report explaining the types of interoperability requests that have been rejected and why?"

The second question from Jasper Van Denand, a web developer.

Can browser vendors add their engine to their existing app where users can simply update it or will users have to install a separate app?

Third question from Daniel Puyazón from Banco Satander.

"Could you provide more rational on how in a fast of all being a tech environment, Apple can ensure that interoperability is future-proof?"

Question 4 from David Paul, National Association of German Comparative Banks.

"When will it be possible to accept NFC payments via third-party application on gatekeeper devices?"

We can pause here.

Thank you, Kyle.

I think I may ask you to repeat the second question, but let me go through the others and then we'll go to the last one.

In terms of the interoperability requests, we are, as Gary said, receiving those requests today and evaluating them.

As already has been mentioned, some of them may be sensitive, some may be commercially sensitive, and we're still very much in the early days of assessing what are we going to make available publicly.

Obviously, if we decide to grant a request, that will be public.

In terms of rejecting requests and those sorts of things and what information will provide, I think it's too early to say how we're going to manage that process.

And of course, we'd want to take into account the developer's perspective on those.

I believe the second question dealt with browser engines or third-party browser apps?

I can repeat.

It was the kind of browser vendors that they're enjoying to the existing app where users can simply update it, or will users have to install a separate app?

So, yes, as already has been mentioned, in that case, we are going to require the user to download a separate app.

That app is only going to be available in Europe.

That is not something we're going to be doing globally.

In terms of the future-proofing of interoperability, I believe we've got a really good process today.

We have a track record for 15 years of developing interoperability solutions for our developer community that are stable, that are safe, that are secure, that are supported, and we're going to continue to build on that process.

When you're talking about an operating system that's gone from 10,000 APIs to 250,000 APIs, when you talk about an operating system that now has more than 40 software developer kits, when you think about all the services we provide, we're going to continue to work on that and continue to enhance that year after year after year.

There may be instances in which there are gaps, and that's what we're going to look to fill here.

But the general practice of Apple has always been as we reinvent the iPhone, as we reinvent the iOS each and every year to provide access to all the various technologies that we make available to developers or make available through the iPhone to developers.

We're going to continue to build on that.

Whether it's the developer forums we've talked about, whether it's the worldwide developers conference, whether it's all the various ways that we touch base with developers.

Our developer relations team talks to thousands of developers each and every week.

There's a lot of ability to have that voice heard.

We take advantage of that by listening and implementing solutions in our operating system.

In terms of NFC and different use cases, obviously that's something we're continuing to work through and resolve.

And so that one is simply, you know, stay tuned.

I am sure there'll be more developments in the coming weeks and months.

Thank you.

So hands up again in the room.

Yes, please.

Thank you.

Now that you've confirmed that browser vendors who would want to use their own browser engine will have to issue a separate app under a separate ID.

Can you explain why that is necessary?

And aren't you worried that that might be interpreted as a circumvention for your choice screen obligation because obviously if they are obliged to issue a new app, they will have, well, zero downloads and they would not be on the choice screen for quite a while.

Don't you see that that's a problem in terms of competition?

Thank you.

My team is, we are losing the steam in the room.

Please.

Two quick ones from the coalition of OpenGIT telecom systems.

How can developers know what types of interoperability Apple provides with services?

And maybe couldn't have Apple proposed to make those publicly available so that they know what they stand on DMA.

And second, because they're very short, the ticketing system could become a black box where thousands of requests go unanswered.

How do you see this working in practice and what resources are you putting behind this?

Thanks.

Please.

Thank you.

Lukas Lasota from the Free Software Foundation, Europe.

We heard from Apple that no reasonable person would require for interoperability as it pose risk for security and integrity.

I would like to point out the very nature of Open Internet.

Internet is interoperability.

The entire free and open source ecosystem of innovation flourished with interoperability.

So my question is, instead of burdensome requests imposed on developers, why can't Apple rely on open port protocols and standards that can ensure a secure interoperability and work with other players to implement in a deal to same standards and protocol?

This would allow more competition and trustworthiness.

Thank you.

And one more in this round.

Please.

Lukas, from the European Banking Federation.

Thank you also for your response before.

Just picking up on the question and your response also and the importance of future proofing and tying that into the interoperability requests.

For example, a use case that we see that's maybe not so future but it's already here is tapped to pay.

So we see that Apple has introduced this functionality in France and the Netherlands and it's a functionality which chooses the NFC controller of a virtual network.

And the NFC controller of iPhone devices to enable the acceptance of contactless payments by merchants.

And it is important to ensure that third party payment acquiring services can offer the same user experience.

So in terms of this type of use case which is actually also being rolled out now in Europe, would this be something where the compliance would already be extended to?

Or is this something that you see would be fall under the interoperability request box?

Thank you very much.

Thank you.

Kyle.

So the first question was I think related to to a browser engines.

And I think we've been straightforward throughout that, you know, this is not something we thought we needed to do or should do.

It's something we had to do.

And so we've complied with the law here in Europe by allowing third party browsers and non browsers who all have to do.

And we're going to see how this develops over the coming year.

You raise a good point about what's the impact on the choice screen?

Something we'll monitor as we see third party browser engines evolve.

Certainly, you know, we'll reflect that in our choice screen methodology going forward.

But it's probably too early to kind of say how that'll work.

If I understood the second question related to the process that we've put in place to kind of stop get measure that we view.

Because again, as we look at our track record of interoperability, we're quite proud of it.

You know, we've worked very hard over the last 15 years to ensure that developers have access to all the various technologies, tools and features and functionalities that we make available to in the future.

And we're available to, through iOS.

As we get new requests, obviously we're evaluating them very quickly.

We have, as inevitably will happen, there are going to be some back and forth in terms of understanding the requests in terms of understanding how that technology will be used.

Again, because in so many of these cases, we haven't opened up technology access because we've been concerned about security or integrity.

This will force us to take a careful look at that going forward, an even more careful look.

But again, it doesn't mean we're going to simply ignore it.

And so the process is designed to be iterative.

It's designed to move as quickly as possible.

We've dedicated a significant amount of engineering resources to this program.

We meet three, four times a week as a team to kind of discuss the various requests to make sure we're moving those forward, to make sure we understand them.

This is taking up a lot of time and attention on Apple's part.

And we're moving as quickly and efficiently as possible.

Maybe in terms of the question around, why don't we simply redesign iOS to be an open system?

I think Gary, you might be best placed to address some of that.

Actually, by the way, I worked out that I didn't need to keep pressing the button every time.

I took the mic from me because it's live already.

So there you go.

Interoperability working up here.

Look, I think the ask that you're making is to turn iOS into something that it's not, which you're entitled to point that out.

We feel very strongly that the way iOS operates has provided fantastic security and privacy to our users.

And we don't believe, and I think Brendan said this in his introductory remarks, that the DMA requires us to become the same as everybody else.

In fact, it's intended to encourage competition not to encourage a race to one overall standard.

So we're very happy with the way iOS is operating.

There are some changes which we will make for the DMA, but certainly of the type that you obviously wish to suggest that's not a direction Apple will be traveling in.

In terms of the last question involving different use cases for NFC, that's something we're continuing to evaluate and assess on a case-by-case basis.

And we'll continue to kind of think through those issues in the coming weeks and months.

Thank you.

Any other questions in the room, please?

Sorry, I was a bit confused with one of the answers to the question of the gentleman.

I just want to make sure that I understood correctly.

So the question of the gentleman is what about the compliance of 6, 7 in terms of the core technology fee?

So just to confirm that the Apple answer understood correctly is that due to the investment of Apple into developing your technology, you decide to not comply with your obligation to make the core technology free of charge for interoperability.

But there was one thing that said we're not giving to give all away.

I don't think that the gentleman proposed to make it open source or give it all away.

You can still monetize.

He asked only about the core technology interoperability because it's the only way for alternative apps to interpret with the apprentice.

There's no alternative.

So the answer is that the decision is not to comply with that obligation.

Thank you.

Please?

You mentioned home screen icons and progressive web apps earlier in the presentation, and I'm curious when we might be able to see functionality extended to other competitive browsers so that they can also build towards better consumer experiences with progressive web apps and home screen apps.

So if you can address that and talk to timelines, that would be great for folks who are trying to build on the web.

Thank you.

Thank you.

I was going to ask exactly the same question.

Will you now start working on allowing web apps to use browser engines of their installing browser?

Because public the Apple have stated that getting web apps to use alternative browser engines would require an entire new integration architecture.

And Apple stated they wouldn't do to low user adoption of web apps and DMA workload, but giving you a state of this and it is a requirement under both 5, 7 and 6, 7, will you be doing this?

And I saw it from the room.

I'm Bora Bala Sichbath from the App Association.

And so I would like to just explore another perspective from, again, a small app developer perspective where developer tools are extremely beneficial and useful for small businesses to be able to compete on markets.

It really helps reduce the market barriers.

And so for us, actually these new APIs and developer tools and interoperability opportunities are very exciting.

So we would like to hear a little bit more about some of these new opportunities and what you think would be the most exciting opportunities for small developers.

Thank you.

Okay.

Great.

So as to the first question, I think we've been very clear that we believe we comply with the DMA.

We've spent 18 months assessing the law, engaging with stakeholders across the board to develop our compliance plan.

We spent the last eight weeks taking feedback.

We strongly believe that the core technology fee complies with all of the provisions of the DMA.

The core technology fee was designed to provide or to compensate Apple for its significant ongoing investments in developing technologies, tools and services for the developer community for the entire developer community.

What we will not do pursuant to six, seven is to charge an additional fee for interoperability.

So we believe we fully comply with the DMA in that respect.

In terms of the questions around home screen web apps, today, third party browsers can continue to use iOS to offer home screen web apps.

We restored that functionality prior to launching 17.4.

And so developers will be able to continue to operate as they were before.

In terms of the last question, I believe it was really kind of focused on what are the options here, I think.

From our perspective, we've launched a program and maintained a program 15 years ago that have allowed developers of all sizes to make requests to Apple about different technology solutions, different features, different functionalities that they wanted to see us both to introduce and develop.

And then also for us to provide access to, and we've done that year after year and we'll continue to do that.

So we have our World Wide Developers Conference coming later this summer.

There's going to be a lot of exciting things coming out of that in terms of the next version of iOS.

We're continuing to invade on a whole range of fronts that I think will provide incredible opportunities for our developer community to continue to build and create new apps.

Thank you.

So I think it's the time to close the session.

So we have now again a 20 minute coffee break and then we'll be back for the last session dealing with data obligations.

Thank you.

Thank you.

Thank you.

Thank you.

Thank you.

[ Silence ] Let's please take the seats.

Sasha, Michael.

>> I can't believe this.

>> Let's please take the seat.

Well, this is the mic, huh?

[ Background noise ] >> Station 4 is about to start.

[ Background noise ] >> Let's please take the seat.

[ Background noise ] >> But it's only for those who are online who get the benefit of this.

Here, no one hears us.

Can we please take the seats?

The session 4 is about to start.

[ Silence ] [ Silence ] [ Silence ] >> Okay, welcome back to this last session.

I see some empty seats, so we are losing some people along the way.

But all strong, we just have the last session to go on.

This session is going to be about data.

There are three provisions that we're going to cover into this session.

The first one is provision related to Article 5.2.

Article 5.2 is a cross-platform provision.

This obligation enables consumers to choose what gatekeeper can do with their personal data.

This is to ensure that gatekeepers do not unfairly benefit from data accumulation advantages across platforms and undermine the sustainability of online services.

To respect the end-user choice, gatekeeper will also have to offer a less personalized but equivalent alternative and should not make the user of their service conditional on users consenting on the data used.

Under Article 5.2, consumers will have to express their choice in relation to the following uses.

The processing of data for online advertising services, the combination of personal data across platforms, the cross-use of personal data across the core platform services, and the signing of end-user to other services of the gatekeepers in order to combine personal data.

Then moving to the -- to other provision on data portability, we have to provision one on end-user data portability and the other on business user data portability.

So Article 6.9, under this provision, end-users and outright third parties shall be able to obtain free-of-charge portability of their data.

And this covers both the data that are provided and generated by the end-users on the gatekeeper platforms.

And gatekeepers shall facilitate the effective exercise of such data portability, including providing continuous and real-time access to this data.

Under Article 6.10, on data portability for business users, business users and their authorized third parties shall obtain free-of-charge portability in use of the aggregated and un-aggregated data.

And this includes the data that are provided or generated by the business users and the previous consent also the data generated or provided by end-users that are engaging with the services provided by those business users.

The portability and data access provided by the gatekeeper needs to be effective.

High quality continues and real-time.

I will then hand the floor to Apple to present their compliance solution on these three obligations.

I also pass clickers really well and professionally.

So, good afternoon, everybody.

Thank you very much for continuing to join us.

I thought I would make a joke about it being a bit like an Irish funeral, not very many people sit at the front, but there was standing room only at the back, so the people who were watching online wouldn't know, but I'm not sure I can carry it across.

I do thank you all, however, for sticking with us for these important date protection, privacy, date-related provisions that are in the DMA.

And I think I should also apologize to Gene, who I feel I know very well now, and I'm sure you've done your 6.2 questions.

There's actually no 6.2 in this.

I just felt we were discussing it so much that it was there, but I'm sure we can get to it in more detail.

So, for anyone who wasn't here for the earlier sessions, my name is Gary Davis, and I'm Apple's data protection officer.

In our final session today, we'll discuss the data-related provisions of the DMA that will find the fully comply, while at the same time, continuing to protect the privacy, safety, and security of EU users to the best of our ability.

To begin with, I'm obviously very proud of Apple's leadership on protecting user data and honored that I get to be a part of that leadership.

We believe that privacy is a fundamental human right, and we're proud to be one of the few companies, if there were, in fact, others, who publicly supported the EU's efforts to enact GDPR while it was under discussion, and many times subsequent to its entering into force nearly 6 years ago.

Now, we strongly believe users must be able to choose when to share their data and with whom, and our DMA approach reflects a shared understanding that no one wants to move backward on privacy.

And certainly, the DMA was not intended to do so.

And I think I gave you all a little bit of a run-through of this earlier, but I'm now going to read it again.

Recital 12 makes clear that the DMA is intended to operate without prejudice to the protections for natural persons, personal data afforded by the GDPR.

And Recital 72 encourages undertakings to differentiate themselves better in competition through the use of superior privacy guarantees.

This is reflected in the operative clauses of the law, too.

Article 8.1 makes it clear that the gatekeeper has a self-standing obligation under the DMA to ensure that the implementation of the compliance measures complies with the GDPR.

So our desire to ensure that we comply with the DMA in a manner that reduces the risks for user security and privacy as much as possible is not something that we've dreamed up, and we know that Europe, the home of data protection, shares our goals.

Over the years, we've introduced many features to protect user privacy, like app tracking transparency, which I mentioned earlier, which ensures that users have control over their data.

Apple's app tracking transparency framework requires apps to obtain user consent before tracking them across different third-party apps and websites for advertising purposes.

Apple holds itself the same standard and higher.

In fact, Apple never uses personal data for third-party apps for the only advertising service we have here in the EU, which is search ads in the App Store, which simply provides a means for developers to promote their apps in the App Store.

In addition, users, through Apple's data and privacy page, can obtain a copy of their data, delete their Apple account, and more.

Simply put, we believe that users should be in control of their data.

Now, in response to the DMA, Apple is giving users in the EU more choices over how their data is used and with whom they share it.

Article 5(2) of the DMA was certainly not designed with Apple in mind, given our industry-leading practices in relation to user personal data.

In the limited circumstances where Apple did share personal data between, say, App Store and other first-party services, we have taken steps to stop this sharing unless a user gives explicit consent.

These are circumstances where previously we would have validly relied upon legitimate interests for limited data use that we fully highlight to users.

And such use was indeed limited, as Apple has not confronted users like other companies have with a barrage of new apparent consent screens in recent weeks.

The screens you are encountering are actually serving to highlight where widespread data sharing is or was taking place by some companies.

These are the same companies, in some cases, who seek to distract from their data and security practices by highlighting aspects of how Apple has complied with the DMA.

They want compliance measures to be more in their favor, one can assume that SUDI can have access to user data more easily.

I really hope that we will remain alert to such tactics and we will call it out where we see it.

Let's move on to how we are ensuring we share insights with app developers through analytics.

We want to provide the information developers need to operate and grow their businesses, while ensuring that personal user data remains not identifiable in the developer's hands unless a user makes an explicit decision to share it with them.

Apple's approach is to always minimize the amount of data collected and shared by Apple or other partners operating within the Apple ecosystem.

To the extent possible, with the goal of collecting only the minimum amount of data required to deliver what a user needs for a given service.

As one example, our app review guidelines require data minimization as a condition of distributing an app through the App Store.

And data minimization is, of course, a principle of the GDP as well.

As for Apple, the only data in scope of the DMA that is processed in a way that identifies individual users and that Apple can share with developers is in relation to the App Store.

Apple collects no personally identifiable data from the use of iOS and Safari by our customers.

This approach aligns with that underlying belief in data minimization.

Even before the updates we have made to the analytics reporting available to developers, which I'll return to in a moment, Apple has for many years provided developers with deep insights into how users engage with their apps in a manner that is protective of privacy.

Developers have had access to dashboards and reports providing valuable insights to help measure their app's performance through app analytics, sales and trends, and payments and financial reports.

This includes reports and dashboards provided through both APIs and web interfaces, such as the App Store Connect API and web interface for Apple's developer tools such as Xcode.

To reflect the DMA's changes, Apple has expanded the analytics available for developers apps to help developers gain even more insights into their businesses and their app's performance.

Over 50 new reports are available through the App Store Connect API in areas like engagement, commerce, app usage and frameworks.

These new reports provide developers with additional information in important areas like the number of App Store users that are interacting with their app or sharing it with others.

The developers now have available more detail regarding the way in which their app interacts with iOS capabilities like widgets, photo picker and more.

Apple has introduced a new API to provide access to reports on an ongoing basis that include data from the App Store and iOS.

Developers will also have the ability to provide third-party access to the reports using the new API.

To protect the privacy of users, we are applying measures necessary to help ensure that users are not identifiable at an individual level.

The App Store engagement data will be provided as daily aggregates where we have identified a risk of re-identification based on the data made available to developers when combined with data which developers could reasonably already hold in relation to users.

We will take measures to address such risks.

This may include crowd anonymity.

That measure removes near-unique records of individuals so they are blended into a crowd of other individuals which essentially leads to the de-identification of these individuals.

We may also rely on the addition of noise.

As the name suggests, noise can be added to data in order to mask information about individuals which also leads to the de-identification of these individuals.

The use of such techniques which are necessary to protect user privacy will be kept to a minimum to ensure the maximum utility of the data for developers.

We have gone to great lengths to explain these measures in detail to developers so that they can easily understand how to use the data most effectively for their apps.

Given the efforts we take to protect personally identifiable information, we have received some questions regarding whether developers will be able to access this type of sensitive information.

The scenario posed is when a user has signed up for a service through a developers app and the developer wants to be able to identify that user in order to provide customer support, for instance.

It's important to understand that this is an issue where there are competing interests and concerns.

We work every day to make sure our platform is one in which developers can succeed by serving their customers.

But we also need to fulfill important commitments regarding the privacy of our users, especially when those users may feel only comfortable signing up for a specific service because of the protections provided by Apple Secure Commerce System, including privacy protections.

It is important to remember that a developer may at any time engage a user directly within their own app if they wish and explain to the user why the user may wish to provide personal data to the developer.

It should also be noted that Article 13 5 of the DMA explicitly recognizes the role of providing data in a privacy protected manner.

Making clear that the Julianonomized data may be a suitable alternative to the provision of personally identifiable data.

Already, users around the world can choose to share device analytics data either with Apple only or with Apple and third party developers.

With iOS 17.4, data sharing options provided to users with regard to device analytics data has been updated to facilitate equal access to both Apple and developers in the EU.

This will be implemented through a single consent screen by which users are able to choose to share device analytics data with Apple and developers or not at all.

And of course users still have the option to change their choice at any time in their privacy settings.

Developers can continue to submit feedback related to Apple's data sharing tools via feedback assistant.

Apple has also updated this important tool to make it even more intuitive and transparent for developers to submit feedback or suggestions to Apple.

Developers can also submit requests for new categories of data if they believe such data exists.

So that's how things are as we sit here today, but we're planning to make further changes to developer data access.

Taking note of the comments I made just now in relation to Article 13.5 of the DMA, we are nevertheless working on a secure solution for a user to authorize developers to receive that user's personal data to the extent it is available to Apple and the user has consented to their personal data being so shared with the developer.

That's something we're aiming to make available by the end of the year.

Next, we're going to talk about the DMA's new requirements for data portability.

It is worth noting that Apple has dedicated significant efforts to data portability long before the DMA and for years we have been actively contributing to several initiatives aiming to improve the ease and speed of data portability such as the Data Transfer Project which has become the Data Transfer Initiative.

The Data Transfer Initiative is a nonprofit organization dedicated to empowering technology users to transfer data from one service to another.

We in fact implemented the means for users to export a copy of their photos from iCloud to Google Photos three years ago without waiting, as I believe most orders would or in fact have, for a reciprocal import function.

And from the very beginning of the GDPR, we made all user data on our Data and Privacy page available in a portable format such as XML for instance, where we taught there might be utility for another service to ingest that data and provide immediate services to users.

We did this as it was and is the right thing to do.

To reflect the DMA's changes, Apple's Data and Privacy page has been enhanced to provide users with a discrete App Store data category.

It now also provides users with the option to consent to exporting this data to authorized third parties, including alternative App Marketplace developers if they wish.

To help ensure that sensitive user data remains protected even with this new capability and to help prevent third parties from misusing data, there are minimum eligibility requirements for third parties who want to access this account Data Transfer API.

This includes that the third party confirms that it does not intend to use the relevant data for data brokerage related purposes and that it is not subject to a relevant enforcement action by a data protection regulator.

Again, this kind of checking, which will be performed by our Data Protection team, is absolutely necessary to ensure that this provision of the DMA does not become synonymous with the misuse of the data.

We are also very conscious of the need to provide real and continuous access to data as required by the DMA.

But again, this must be done in a way that does not provide a means for criminal access to user data on the undermining of security.

Users are therefore now able to schedule, in advance, daily downloads of their App Store data for up to 30 days, or weekly downloads for 180 days.

The data provided is updated continuously and corresponds to the data available to Apple at any time following a user's request.

We designed the chosen periods to protect users by ensuring that the data does not continue to be transferred in cases where users may have forgotten that they have initiated a continuous data transfer or do not log back in to the data and privacy page to alter the data transfer they've requested.

Users can review and revoke access to third parties at any time.

Apple has also carefully considered known and potential additional security and privacy risks and has implemented appropriate measures to mitigate those risks.

To ensure that the data transfer to a third party is indeed authorized by a user, we have applied the exact same robust authentication and authorization process as we do for other user rights on our Data and Privacy page, which requires that end users authenticate themselves to their Apple ID.

This step allows the integration of two-factor authentication, which is a globally acknowledged and appropriate security standard for ensuring that it is the users themselves who are requesting the transfer of their data.

These are methods which have won the approval of data protection authorities in repeated account security reviews.

Apple also plans to make further changes to its user data portability offering.

Today, there are a number of third parties that offer migration solutions to help users transfer data between devices with different operating systems.

To build in those options, Apple is developing a secure, seamless solution that helps mobile operating system providers develop more user-friendly solutions to transfer data from iPhone to a non-Apple phone.

Apple aims to make this solution available by fall 2025.

It will require extensive work with other operating system providers to ensure the secure, seamless experience that users will expect.

Apple is also creating a browser switching solution for exporting and importing relevant browser data into another browser on the same device.

We're aiming to make this solution available no later than early next year.

And with that, thank you very much for listening to me.

Kyle?

I think I'll turn it over to our friends at the commission.

I think we'll take questions on these data issues.

Thank you.

Indeed, we can open the floor to questions.

Let me just remind the rule of engagement, especially for those that have just joined us online.

So, state your name and organization before speaking and keep your comment and question short, two minutes maximum, relevant on the topics that we are discussing and be as much as possible constructive.

Okay, on these, I will open the floor starting with the room.

So, if there are any questions, please raise your hand.

Okay, so I take the question from you.

Hi, Mark Prudamo from the App Fair Project.

The specific apps that people install and run, including where and when they launch them, can be considered sensitive information when it comes to political and social activity, women's health and free speech.

Does Apple track personally identifiable information about which apps are installed from third-party marketplaces and where and when they are when the apps are launched?

If so, Apple may be compelled to disclose this information to any of the various legal jurisdictions they operate in.

This could jeopardize vulnerable users.

Will this app installation launch activity still be reported to Apple, even when they opt out of sharing analytics with Apple?

Thank you.

Other questions?

Dantremen Thier?

Yeah, hi, Jean Burris again.

Nice to see you again.

If I could be indulged a little bit on 6/2, just a couple of brief follow-up questions.

One is why haven't you chosen to change the terms of your agreements to reflect the limitations on your ability to use data collected from third-party apps competitively?

Because right now it continues to say you could use it for any purpose that you wish.

And then two related to that is you talked earlier about kind of protocols on how data is collected, how it's stored, how people are able to access it or not.

Will the limitations on using data from third-party apps be applied worldwide or is it just going to be within the EU?

And if it is just the EU, how would that work?

Is it data collected in the EU?

Is it data collected from EU devices?

No matter where they are in the world?

Is it developer apps from developers in the EU versus otherwise?

If it's not going to be applied worldwide, how do you intend to apply that limitation?

Thanks.

Thank you.

So there was some questions on the back a little, please.

Hi, I'm Mary Pekkakalava from the European Games developer Federation.

Continuing on the previous question, so your compliance plan is very much focused on access to aggregated data through analytics tools.

But could you describe a little bit more on when and under what conditions game developers can access non-accricated data?

Is this as a previous question indicated only for the EU users or non-EU users only on the data from the EU area?

Or when the EU user is somewhere on other parts of the world on how does this actually work?

There are some crucial data points Apple doesn't share at the moment and as you say, there are often competing interests in this area.

For example, currently when a player asks a refund for an in-app purchase, a game developer doesn't have an access that data enabling them to identify which user has asked their money back on 10-meter old in-app content they have asked the refund for.

So this is very crucial part of the EMA implementation to get you correct.

Thank you.

Is there perhaps a last question?

Thank you.

Look at the Lassata from the Free Software Foundation Europe.

What are the formats used by Apple for data portability solutions mentioned some minutes ago?

Thank you.

Thank you.

We can pause here and have a first batch of replies and then we collect another question.

Great.

Let me take those.

I didn't quite understand the first part of the third one, but I'll clarify it and obviously Kyle, you should feel free to elaborate upon any point that I don't get to.

The first question I think from Mark from Appfare was the question about data installed from the App Store and from alternative app marketplaces.

In that instance, I'm going to somewhat highlight Apple track record in relation to responding to requests from law enforcement where we consider that the requests are disproportionate or inappropriate and clearly in such circumstances we have shown that we will raise questions about those requests and where appropriate pushback.

Obviously, if a request is lawful and is proportionate, we do our best to assist law enforcement in those circumstances.

Where we do have personal data associated with the download of an app, it is simply the download of an app.

It doesn't indicate anything about usage.

We do not collect any information about your individual usage of an app in a personally identifiable way.

Some will come from analytics that is shared with developers, but that's across the population of users, not individual users.

And the same installed information that we have from the App Store will be available for app marketplace downloads as well.

The second question I think Jean was on the 6-2 provisions, and I think you raise a point in relation to the update to the terms.

That's not something I have been involved with in great detail.

It's certainly something I can take back unless Kyle has something to add to it.

I will say my focus in terms of the work that I have been leading is to make sure that we identify all in-scope data, market appropriately, and ensure that it is only used for the purposes for which developers are submitting it to us.

And I am very focused together with everybody else in the company and making sure that we have strong guardrails in place around that data.

That is very important to us.

Was there a second part?

That data will be marked worldwide in terms of how we will manage it.

Obviously we'll need to take account of the different legal regimes, but the data will be marked on a worldwide basis.

I think the third question from the European Games Federation, it was that one, that the first part of it I wasn't clear about.

But I'll answer it as best I can.

In terms of, I think I answered that in my remarks in that we are later this year providing a means for you to directly ask users using an Apple interface to provide their data to you on what will be a real time and continuous basis.

So that's to come in relation to that.

And then I think there was a question about the formats.

The formats will vary.

From the will be XML, there will be CVV files, there will be some that will be available in PDF, and not for seeing any issues about an ability for a developer to take that data and use it to gain insights.

But if in fact you find there are such issues, we are very much listening for any feedback.

Our intention here is to provide that data in a way that is useful to you.

We have no interest in doing it in any other way.

We've only ever received positive feedback from when we've provided it before.

I don't believe this will be any different.

But true feedback assistant, we would be very happy to hear any thoughts that anybody has on the data that might be available.

And then I think there was a question about adding additional data.

I believe we've provided all the data that is available to Apple.

But of course, you know, sometimes maybe I have not fully taught of all the different vectors.

I believe we have.

But again, if any developer having viewed this data, which is available today, wishes to make a suggestion to us for an update, we're very much open to that and looking for that feedback and will happily engage if you wish to use the feedback assistant for that.

So let me just kind of build on the answer to Jean's question because I want to make sure he doesn't feel ignored or overlooked.

But I think it's important when you're thinking about this from a 6 to perspective to understand how Apple's organized itself in terms of its interactions with developers.

And so today the app store stands separate.

It reports up to our executive team and our CEO in a totally separate organization from our developer relations team, which is the team that is tasked with interacting with developers each and every day, who also conduct app review, which we talked about, which really interacts with the developers.

I have to say, you know, as a general rule in my 15 years at Apple, we see very little competitively sensitive information there.

This is an area that I've long been focused on since joining the company from the Federal Trade Commission, which is to ensure that there was not a blurring of the lines there and that, you know, we have built that up over time, which was an informal process when we were in the beginning of the app store to a much more formal process.

There's a member of my team who's dedicated to this to make sure that, you know, there isn't a leakage between these different teams.

And we back that up with some of the work that Gary's doing in terms of making sure there's strict technical segregation of data.

In terms of other teams, there's obviously we have our services and software team.

They report wholly separate.

So that's another area in which we're very careful and very sensitive to to make sure that there's even in the corner, even in the rare cases, or even in close cases where, you know, it's going to be a little bit different.

It's public data.

We're not sharing that across organizations.

So we have three separate organizations between the app store, the developer relations team, and our services and software teams.

Those are separate teams.

We've long had policies in place to ensure that data isn't being shared across those teams.

And as a result of the DMA, and frankly, some of the other questions that have been raised, we've enhanced those efforts.

And we've enhanced those globally.

That's not something we're just doing in Europe, but that's something we're building out on a worldwide basis.

Thank you.

I think there are some more questions.

I think over the year.

Thank you.

Clara Riedenstein from the Center for European Policy Analysis.

So you suggested the addition of crowd anonymity and noise to the data that you share.

How do you reconcile that with the obligation under 610 to provide high quality accurate data?

Thank you.

Thank you.

We can take a question here.

Hi, from Coalition of Open Digital Existence.

The fact that you will not be implementing a user-friendly solution for data portability between IOs and other devices and services before fall 2025 is a bit concerning.

We find it a bit too late.

Users should enjoy the benefits of data portability under DMA in a timely manner.

And they should enjoy a complete level playing field.

Will you or can you implement data portability earlier than that?

Let's go to the question over there.

Good afternoon.

Daniel Friedlander, CCA.

Obviously, some of us, including many of you, will be here all week with many different presentations.

And as we perched in, I was just thinking, if I could have your thoughts after a very long day on whether the DMA, all these obligations, all these solutions you've been working on actually allow enough space for different gatekeepers to actually differentiate themselves, yourselves, solve the problems unique to your systems and designations to comply in ways that actually allow you to keep differentiating on key topics, business models, privacy, and all the other things you've highlighted today.

Thank you.

One last question.

Hi.

John Asbe from Open Web Advocacy.

This is a general question, but one that has to be asked and hopefully this time we can get an answer.

Apple's compliant report is woefully lacking in detail relative to the reports created by the other gatekeepers.

And the lack of detail in Apple's compliant report makes it impossible for, to quote the DMA, third parties to assess whether the gatekeepers comply with the obligations laid down in this regulation.

Microsoft's report was 421 pages.

Google's report was 271 pages, but Apple's report was 12 pages.

Even if you include all of Apple's online documentation, it is inadequate and I'd encourage my fellow attendees to make their own comparisons.

My question is, does Apple honestly believe their 12 page document enables third parties like us to comprehensively assess whether they comply with all of the obligations laid down in the DMA?

And do they believe it effectively complies with Article 11 and Versailles-Gil 68?

Thank you.

Thank you.

We can turn to Apple to reply to these questions.

After this batch of replies, we'll take questions from the LIDO, so people online, you have your chance of asking questions of LIDO.

Great.

Thank you, Luca.

I think I'll take them and turn them.

I'll ask Kyle to take the last question from John because I think it's broader than just the data provisions.

So, Clara, I think you asked about how do we ensure that we are providing high quality, accurate data?

Well, we actually have gone to really extraordinary lengths to examine the utility of the data that we're providing.

We've published some very detailed overview information for each data element in each category, detailing the specific measures that we have applied in each case.

By doing so, it is our assumption we brought in our obviously our data privacy team, but obviously importantly our data science team.

We are very confident that the data has high utility to developers.

So, I think we've done a good job there, but as I've indicated, very happy to take feedback, and also very happy to explain the measures in more detail where it might allow easier understanding of them, but I think we have a very strong baseline there.

The question in relation to iOS to another operating system portability and the timeline that we've put in place, I should say first of all that we are doing that because we think it is the right thing to do.

We are not entirely convinced that's something that's specifically required by the DMA, but we listened to feedback from stakeholders, and we put together a detailed plan in response to that.

But providing a means to seamlessly and securely move all the data that I have on this device to another device that's not part of the Apple ecosystem requires detailed work with other parties.

That detailed work has begun, and we want to do it in a way that is consistent with the experience that our users have across the Apple platform, and that is something that takes an extensive amount of time to achieve in a manner that meets that experience expectations, but is also secure.

I feel that's a time period that actually will allow us to achieve it in a way that meets user expectations for when they do it.

I think Daniel had a question which was maybe also for Karl as this kind of broader one in relation to how gatekeepers will be able to differentiate themselves on different topics if you want to take them.

No, and I think both of the third and fourth questions are important ones.

So obviously Apple is still very focused on how we can differentiate ourselves from our competition, how we can continue to innovate in ways that benefit both users and developers.

Do we have concerns about the erosion of differentiation?

Absolutely, as I mentioned at the outset.

Are we concerned about our impact to continue to innovate and release new features and functionalities here in Europe?

Yes, we are, and it's going to be a complicated process going forward.

We have been able to operate for 15 years in a way that we could release one product to the world with all the technologies and features and functionalities that our engineers are working on without having to think twice.

Now we are having to think two, three or four times before we release something in Europe and that's unfortunate.

And it doesn't just simply limit itself to the iPhone but across all of our products.

It's a much more complicated and complex environment.

Fully recognize and understand the policy judgments that are being made, but then the outcomes of that is we have to think a lot harder about what we are doing.

And in terms of differentiation, this is absolutely critical, particularly when you are talking about a company like Apple, which is always try to set itself apart.

We have always taken a unique approach to the marketplace.

We have always taken a unique approach to how we think about privacy and data protection.

We have pushed hard both in terms of encouraging laws, but also what we can do on our own platform to ensure privacy.

Do we think that's going to be lost on what?

Yes, we do, and we are worried about that.

So there's a whole host of things where we want to continue to be unique.

We are a different type of company.

We are a different type of product.

If you think about the gatekeepers, we're the only one that offers an integrated set of hardware, software, and services.

That's having to change somewhat, and we don't fully know what's going to happen in the days and weeks and months to come.

In terms of the question around our summary of our compliance report, I am not one, and I've never been one, to think that the number of pages equals transparency or equals how much people can comment or understand our plans.

I think the DMA is quite clear that it requires a straightforward, transparent summary of the confidential compliance report.

It's exactly what we've done.

The summary provides a plain language, what we've done.

It provides a roadmap in terms of links to over 80, 100 different documents that we've made available to third parties, whether it's developers, whether it's users or otherwise.

It's an incredible tool that enables people to quickly grasp what Apple has done, and then if they need more detail, they can quickly hit a link and find that detail.

I think the proof here really is in the pudding, so to speak, which is what has happened.

Apple's January 25th announcement, its release of the documents I've talked about, its release of the beta software version, has generated incredible debate.

We all see that in this room.

We all see it every day.

Whether it's on social media, whether it's coming in, all the developer forms that we've held, whether it's all the consultations that we've held, we're hearing questions that are informed questions.

No one is confused, it's seemingly about how we complied.

They may take issue with what we did and could we do it in a different way, but there's nobody that seems to be confused about what we've done.

And that's because we've been incredibly transparent and comprehensive in the plan that we released in January that we updated in March, and it would continue to refine and develop.

And so, yes, I'm aware that other gatekeepers complied a redacted version of their compliance report.

I don't think that's an effective way of providing people with a clear and transparent and digestible understandable way of what did they do to comply with the DMA.

I think everyone in this room understands what Apple has done to comply with the DMA, so I think we've accomplished our goal there.

Thank you.

We can now turn to Slido to take some questions from there.

Yes, thank you.

So we have a couple of questions from Slido.

The first one is from Tom Fishcode.

That appartibility appears limited to App Store data.

When will Apple deliver data portability for all free CPS, including iOS?

That is, for instance, screen time data.

The second question is by Jan Kramer, University of Passau and Sarah.

Apple interprets real-time data portability as daily or weekly refresh rate.

Can you confirm that Apple itself does not get the data at a higher refresh rate?

The third question is from Albert Ibera Martinez from University Carlos III of Madrid.

Building up on Apple's engagement with privacy.

Why is Apple's report on consumer profiling under Article 15 not publicly available?

And the fourth one is Ferruzi Masmidazi on Article 610.

Why does Apple now impose users to accept sharing data with Apple before being able to share them with developers when Apple is a third party?

I think all of those are yours.

I am not sure I can let Eddie have those with you, but feel free to chime in as appropriate.

Okay, so I think the first one we see was data portability limited to App Store data.

I think maybe since that question was posed on slide, I answered it in relation to iOS and the solution that we're putting in place in fall of 2025.

I think I also answered in my remarks in relation to the browser Safari related data on device solution that we're putting in place for the end of the year.

There was a specific question about screen time data.

Apple itself does not have access to screen time data that passes across our services from device to device in an end to end encrypted manner.

And certainly the DMA is not seeking to have Apple break and encryption for data that we ourselves do not have access to.

But obviously as we are looking at our solution for iOS to alternative operating system portability looks like we will be looking at all data types to meet user expectations in relation to that.

I think there was a question in relation to the second question as to how we have interpreted real time.

Again in my remarks, I believe I indicated that the data which we are providing will correspond to the data that's available to Apple.

We are not pouring through data as it comes through to us.

I think that should be very clear from the overall remarks I've been making.

So we are making an effort to collect the data on a daily basis and provide it to developers.

We don't think there's any insights that they'll be missing and certainly there's no insights that Apple will have access to.

I think that's the foundation of the question.

And then the third question is why is Apple's report on consumer profiling under article 15 not publicly available.

I got a great answer to that one.

It is in fact publicly available.

We have made a report available on our privacy governance page.

There is a caveat to that.

Again, it should be clear from all the remarks that I've made here today.

Apple does not believe it's engaging in any profiling as it is defined in the GDPR.

However, we were happy to make a report available which details the very limited use of data that we make in the App Store and for marketing purposes.

So you will find that if you search for Apple privacy governance.

And then the fourth question, I will answer it to the best of my ability which is why does Apple require sharing data with Apple in the first instance in order to share it with developers, which I think is a reference to the new screen that we're putting in place.

Well, I think it has to come to our servers in the first instance for us to be able to make a means to provide to developers.

I don't think Apple is a third party in relation to it.

This is common data from a user's use of iOS.

That is data which is also helpful towards many instances so that we know which apps are causing the device to crash.

Overheating the device, many reasons why users wish to share that with data so that they're experiencing with Apple, so that their experience in using their device is the one that they expect, but always in a non-personally identifiable way so that we can try and maintain and improve the operation of iOS.

I think that's it.

Do you wish to add anything?

No, I think I'll cover that one.

Okay.

Get an A for that one.

Thank you.

So we have last 10 minutes.

Let's see if there are other questions from the room here.

Okay.

Okay.

Thank you.

My name is Christina.

I'm deputy legal counsel at found at private association for all the vision media in Germany.

I have a question with regard to what was said with regard to 80 T and that Apple holds itself to the same standards and higher.

And also the relation with regard to other gatekeepers and their positioning.

The financial times reported in 2021 that Apple's advertising business has more than tripled its market share in the six months after it introduced privacy changes to iPhones that abstracted rivals, including meter from targeting its consumers.

So what do you say to people who say, okay, this is contradictory to sticking Apple to innovation and second aspect.

I mean, France and Germany are engaging in proceedings against Apple 80 T with regard to self-preferencing.

So isn't there a contradiction?

Thank you.

Yeah, we have asked question like to be very much focused on the data portability.

So if you have something specific on the portability, you could rephrase your.

No, that's fine.

Are there other questions from the room?

No, I'm checking with the slide.

I don't know if there are other questions.

How will Apple provide publishers with information about the users who downloaded their newspaper and magazine apps to enable direct communication with readers questions from Angela Mille suede from EPC?

So I think I think I've answered that one in terms of the solution which we're bringing, maybe in response to the question from the European Games Federation earlier that developers will have a means to directly ask users to share their data.

I would like and I do appreciate just broadly sticking within the lines of the session.

I would like to address app tracking transparency in a high level manner.

It is a framework which we announced in June 2020, I guess at this point.

It had one goal and one goal only, which was to give users for the first time ever a clear means to express a consent as to whether they wished for their data to be used for advertising purposes across third party apps and websites.

It so happens that Apple does not engage in those practices.

As I mentioned in my remarks, the only advertising which is available here in Europe for Apple is for developers to promote their apps in the App Store.

We do give users an explicit option as to whether they wish for that promotion to be personalized which actually just means a limited amount of App Store data.

Never as you would expect any third party data in any way or even data from other Apple services is extremely limited.

We think it is a choice that has actually been a huge boost to users to express that choice.

Obviously there are some people who don't agree with it.

Some of them have complained to certain authorities.

Those authorities of course are free to look into it but we continue to feel that it is the right thing to do for our users.

The exact same way as we've taken the principal position.

Maybe the only company that will be here this week that has supported the e-privacy regulation update.

I think we might stand on our own there.

I think we're also the only company that was supportive of the European Commission position on the cookies pledge.

Might have been standing alone on that one as well and so maybe if we take those things together there is a bit of a pattern there of Apple actually supporting initiatives which allow the user to express a new product.

Thank you.

Thank you everyone.

I think we are finishing a couple of minutes ahead of time.

I see some tiredness in the room.

It was a long day.

So I go to close a bit earlier.

I leave the floor to Alberto Bachega for some closing remarks from the European Commission side.

Thank you very much.

It's been a long day indeed.

A marathon won a few times.

I think there is a key difference from a marathon when you run normal.

You can breathe fresh air.

It was not abandoned in the room.

But first of all I would like to thank all the participants.

I would like to thank all the participants who participated online and put the question slide.

All the participants in the room also who were very active and we very much appreciate it.

Let me thank in particular Kyle, Gary and Brandon for being there and actually presenting and taking questions all day long.

I would like to thank all the participants who participated in the program and the team who participated in the program.

I would like to thank all the participants who participated in the program and the team who participated in the program.

We also have a huge impact on the team's experience and the team's experience and the team's experience and the team's experience and the team's experience and the team's experience and the team's experience and the team's experience and the team's experience.

We all agree that a user-centric approach is the key when displaying choice screens and providing for default switching and up an installation.

We have a display of choice screens for browsers on iOS and APOs that are sharing on the status of the default browser and selection rates.

In addition, the discussion focused on many technical issues with the callers asking how a poll solution would work in practice.

During the second session, we focused on app distribution on iOS and in terms of articles of the DMAs, 5.7, 6.7 and 6.12.

We discussed Apple Propose Solutions to allow third party app stores as well as side loading and link outs.

We understand that these changes will allow for new ways of distributing apps on iOS, but there remain many questions and we heard them today as to the effectiveness of the solution to achieve the objectives of the obligations and in particular, Apple's role in allowing a monitoring third party app stores and the apps offered on these.

We know that there are many concerns and questions on Apple's new fee model as well that we have discussed at length.

Afterlands, the third topic of the workshop concerned vertical interoperability and tying, so articles 5.7 and 6.7 of the DMAs, Apple outlined its approach to allowing interoperability with iOS.

Specifically, Apple explained its interoperability request process and outlined in its interoperability solution for web browser engines and access to the NFC chip.

In the discussion, many stakeholders expressed concern on the interoperability of and competition on iOS, especially for browser engines.

These concerns include the commercial and technical conditions as well as the security and integrity requirements set by Apple.

Lastly, we discussed data related obligations just now, so articles 5.2569 and 6.10 of the DMAs.

Apple outlined its approach to data analytics and data portability.

Questions here focused on the technical implementations and details.

For example, on the type of data, the sources of data, the standards for the data and the formats of the data made available for porting.

So it's been a very rich day.

We have had literally dozens of questions.

I think for to say a number of them have been answered.

A number of them, Apple mentioned that there is an open dialogue that can continue and on a limited number of them said that they will come back to the question at the later stage.

And we will have to digest all these, but maybe some questions also, I think at least for me, would need to have more interaction to in order to achieve a full answer that.

We can all fully understand.

And this speaks to one important fact that also Apple remarked that the 7th of March is the beginning of a process that will necessarily take time and will need adaptation over time.

That I think is true for Apple, is true for any other gatekeeper and is true for all stakeholders.

For us, it's very important, the workshop that took place today, because we wanted to have an open forum and hear the voice of not only the gatekeepers, but also the stakeholders and help the interaction.

Of course, there is a direct interaction between gatekeepers and stakeholders as well.

We very much welcome it.

There is also a possible interaction, of course, between stakeholders and the European Commission.

We are very open to hearing from you.

We are very open to hearing your remarks.

We are very open to hearing.

So what you think about this format and how useful it is, as you saw, we posted several times our mailbox for topics that we could not cover today for a clear limitation of time.

We very much welcome of that.

The ultimate objective of the DMA is to ensure fairness and the contestability, as we know, know, and the way to do that is effective compliance.

So what we really also want to hear from everyone is how effective the compliance solutions are and how really enable business users and users to take advantage of the provisions in the DMA.

So I hope that you will share with me the thought that this has been a very interesting day.

I hope a fruitful day as well.

And so I don't want to hold you any further.

It's been a very long day, as we all said.

So just thanks again to the appers representative for having been with us today.

And thank you to you all.

[Applause] (applause)