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.