The Changelog: Software Development, Open Source - Big updates in Safari 14 (Interview)

Episode Date: June 29, 2020

We're joined by Ronak Shah and Beth Dakin from the Safari team at Apple about their announcements at WWDC20 and the release of Safari 14. We talk about Safari WebExtensions, Face ID and Touch ID coming to the web, Safari's plans to advance the web platform, and it all comes down to their focus on privacy, power, and performance.

I try to look up what Chrome's mission was in terms of what they're optimizing for. So you often think about what are you optimizing for? And what you're optimizing for isn't market share, at least on the Safari front. Maybe in other areas you might be as a company. But when I go, and these stats may not be accurate, but this is just a quick Google search. Roughly 18.2% global market share for Safari, while Chrome sits at roughly 63.9%. So they may be optimizing for market share. You're optimizing for these sort of three pillars you sit upon, which is privacy, power,

and performance, meaning that the moves you make for Safari aren't just focused on getting it to be the best, most used browser. It may be the best browser, but it may not be the most used browser. You know, I think it gets even simpler than that. At Apple, we build the products that we want to use. Ultimately, numbers aside, that's what it comes down to. We want a browser that protects our privacy. Just personally, that's the browser I want to use.

I want a browser that preserves my battery. I want a browser that I can use without slowing down my system. And we're always going to prioritize the user when we make these types of product decisions. And as we kind of think about what we're going to do in the future, it's really as simple as that. Being With Your Change Log is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at Change Log because of Rollbar. Check them more at Fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at Rollbar.com and we're hosted on Linode cloud servers.

Head to Linode.com slash Changelog. All right, welcome back everyone. This is the Changelog podcast featuring the hackers, the leaders, and the innovators in the world of software. I'm Adam Stachowiak, Editor-in-Chief here at Changelog. On today's show, we're talking with Ronik Shah and Beth Dakin from the Safari team at Apple about their big announcements at WWDC 2020 and the release of Safari 14. We talk about Safari web extensions, Face ID and Touch ID coming to the web, Safari's plans to advance the web platform, and it all comes down to their focus on privacy, power, and performance.

And one more thing, huge thanks to our friends at Linode for helping us to make this episode of The Change Log interruption-free. So we're joined by Ronik and Beth from the Safari team. Thanks so much for coming on the ChangeLog. Great to be here. Thanks for having us.

Fresh off of the big announcements at WWDC 2020. Lots going on in Safari world. I feel like this was a particularly big Safari announcement, both for consumers and developers. Do you guys share that sentiment? Totally. I mean, this is probably the biggest update we've done since we first introduced Safari. We're forwarding everything from performance, continuing to deliver industry-leading battery life, doing lots to continue protecting user privacy on the web, which is so, so important to us.

And in addition to all of that, we have all of these amazing features, customizable start page, built-in translation, and a redesigned tab experience that I think users are going to love. Just right there, it's a huge release. Then on top of that, for developers, doing things like supporting the web extension API so that developers who have built extensions for other browsers, they're going to be able to bring that over now to Safari really easily.

There's a lot there. This is a huge release for us. This is a huge release indeed. I was just curious from each of you, maybe we'll just start off with what your pet topics or features are. What do you think is the biggest release for developers? What are you the most excited about, both Beth and Ronak? Take your turns. I think it's got to be the web extensions. When I think about developers this year, it's a huge new world

to open up to web extensions. We've built some really nice tools to make it easy to bring those extensions over to Safari. That's something that I'm really excited about. To follow on to that, I think developers are going to be excited that they can take advantage of the Web Extension API and the tools that we built to make that process simple. Once they've done that, we spent the time to create this whole new category in the App Store just for Safari extensions.

All of that hard work that developers put in to bring extensions over, we're going to be able to showcase that so that users can easily find extensions that they're interested in and start using them right away. I'm really excited that we thought about this end-to-end from the developer perspective all the way to putting it onto the store

and getting it out to users. When it comes to web extensions in particular, what was the, I guess, hurdles in prior architecture? Why is the new way you're doing it now so much better than previous ways? One of the things with web extensions that we really wanted to think about a lot is the privacy angle. There are so many APIs available there where if a user just installs this extension, they might not realize the full extent of what it's capable of accessing. So we really wanted to think about a thoughtful way to give that power to developers while also empowering the users

to only use that when they really want it and to understand what that little program is able to do. So I'm really happy with what we came up with, where we have some extra privacy controls on the extension button. And we encourage users to consider to enabling the extension only for a day or only for certain websites, if that makes sense for them. And, you know, we thought we came at this from an angle of privacy being our biggest concern, but the two other biggest things we're always thinking about are performance and power. And really having those controls is huge for those also because extensions can make web browsing slower and they can use up a lot of battery. And so just having a little bit extra ability for users to control the extension and when it's running and encouraging them to consider that makes me feel a lot more comfortable with how powerful web extensions are.

So this API that you're now supporting, this was developed by Mozilla? Is this an open specification and Mozilla and Google have been supporting it and now Safari is supporting it? Give us a little bit of the history on that because I'm not aware. So it's technically not an open standard right now. It'll be interesting to see that because we want to contribute to it in an open and collaborative way. But I believe it started as Firefox. I could be wrong about that. I'm going to want to go double check that.

But I believe that they started a web extension API and Google kind of took it and ran with it and built a lot on top of that. And then it's been this thing where they're kind of all supporting the web extensions and catching up with each other, but it's not actually in an open standard. I would love to see it in an open standard, personally. So without being in an open standard,

it's kind of being treated like one, where developers are creating extensions, using it, and expecting them to mostly work interoperably between the browsers that support that API. So we're coming to the party now, and that'll be fun. Awesome. You got a welcome from Mozilla in the front. Caitlin Neiman mentioned in a blog post on the Mozilla blog,

she mentioned at the WWDC20 event that you announced this thing. And she even in her own words says, similar to Firefox's Web Extensions API. But they're welcoming you to the Web Extensions community. Aw, thanks. That's awesome. And it's going to be great for developers to have this common set of APIs.

And there may be differences here or there, but to have that common set of APIs that they can develop against is going to be a big deal. Yeah, so as a web developer, a lot of the extensions that I end up wanting to install are developer-focused extensions. And so these are a lot of people scratching their own inch. I even have created a couple over the years as well,

and I felt the pain of writing this common little JavaScript interaction and then saying, okay, now I have to create a Firefox extension and a Chrome extension. And I am a Safari daily driver, so I'd create a Safari extension. But because of that extra step, a lot of developers,

because they aren't using Safari as their development browser, they just don't take the time. And so as a Safari user myself, I would go find a cool extension and it would be Chrome only, or it'd't take the time. And so as a Safari user myself, I would go find a cool extension and it would be Chrome only. Or it would be Chrome and Firefox. It seems like Safari wasn't, you know,

it wasn't in the party as best as. So how easy is it now when, is this Safari 14 or is this 13.1? Well, when the new stuff gets into Safari, this web extension support, how easy is it to get those Chrome extensions, those Firefox extensions, either ported over or is there no code changes? How does that work?

So step one is you'll need Xcode. But from there, if you have an existing extension, it's super easy. We built a command line tool, Safari web extension converter that can take a Firefox extension or a Chrome extension or an Edge extension and convert it to a Safari extension. It will create like an empty app shell that you don't need to do any modifications to if you don't want to. But that's part of how our extensions are bundled in the App Store. Or you can choose to modify it. Up to you, of course. And the script will let you know if there are keys in your manifest that aren't currently supported in safari so it sort of gives you that heads up about any needed changes but what we've found because we've been testing extensions and

converting them ourselves to see if they work is that many just convert and work right away. So what happens to the current Safari extension store? It's been its own thing. I remember there was a web interface. Does it go away and everything's in the app store, or is it already sort of integrated into the app store? Right now when I open it up, it opens up a thing that says Safari extensions. It looks kind of like the app store app, but is this exposing it to more people,

or maybe that already happened and I just didn't notice? So we're going to continue to support our existing extension model and both existing extensions, of which there are a lot of popular ones like Honey and Grammarly that are already available on Safari. You're going to be able to get those from the same new category in the Mac App Store as these new extensions that are based on the Web Extension API. So we're going to have one convenient place in the App Store. And what's cool is we're going to actually have editorial, top charts, all of the tools that people love to use in the App Store to make it really easy

for people to find these. And so from a user perspective, they're going to be able to pick from this great selection regardless of how a developer's built the extension. I actually just installed Pocket and following your instruction, Jared, I went to the App Store preview, which launched the actual App Store Mac app that now shows me a preview of a few Safari extensions. And I was just telling you before the call that I think I just did this because when I installed Pocket to Safari, it launched the Mac App Store. I installed an app from the Mac App Store, and then Safari could talk to something behind the scenes. As a user, it was pretty interesting, but having been down this road

before with Safari installing extensions, it was foreign. But I was like, I think I just did this. And so I see here on this Safari's extension preview page here in the Mac App Store now that's showing me pockets. I'm assuming that was true based on it being there. Is this Mac OS only? Or are you guys bringing extensions to Safari for mobile? So this is for Mac OS.

So we support extensions on Safari and Mac OS. We've certainly heard feedback about extensions on our other platforms. So we're aware of it, but we're talking about Mac today. Yeah, fair enough. So what is the most important thing, I suppose, to developers when it comes to extensions?

It might seem obvious, but what are the things that developers should be most excited about with web extensions? Good question. I mean, one of the things that's just obvious is mostly what we've been talking about, that if you already have an extension, there's a whole audience out there for you. If you're starting from scratch and you want to build an extension, it's also a great choice because for that same reason, the interoperability reason. And then in terms of the APIs, there's

just a lot there. There's so much you can do. There are so many APIs. It's epic to go through the number of APIs. If you sum them all up throughout the different browsers, because not everyone implements everything, but the total possibility there is extreme. And I think that that part is exciting as well. There's just a lot that you can do with them. You know, and I think just putting myself in the shoes of an extension developer, being able to reach this audience, this huge audience that we have of Safari users who are really passionate, who are often super enthusiastic

about the apps that they run, the technologies that they use, and being able to reach them now with your extension so that they can dial in their browsing experience is a really big deal too, I think. Are those numbers you can disclose to some degree? I know you have installs of Safari, of course, but actually active users of Safari? I don't have hard numbers to share, but we have tens of millions of Mac users out there

and a whole heck of a lot of them use Safari as their primary browser. So it's a lot of people. It's a lot of people who use the latest. They upgrade to the latest versions of Mac OS, and they're super knowledgeable, and being able to reach them with your extension is going to be great.

I know Jared's not in his head because he's been a diehard Safari user forever. I bounce around from Chrome to Brave to Firefox, now I'm back to Safari again. One thing I love most about the last, I would say, two years, maybe a year-ish, two years, has been the utter focus across the board for Apple when it comes to privacy. And so I take that as a diehard Apple user.

You see a classic Mac behind me. You see the trash can behind me. The pseudonym for the prior Mac Pro. I'm using an iMac Pro right now. I've got an iPhone in my pocket, I've got an Apple Watch on my wrist. I'm an Apple user, long story short. And so to not

use Safari primarily was kind of troublesome. And some of that was because of the lack of dev tools or the differences between different browsers, which I'm sure we'll probably talk about. But Jared nods his head every time I say Safari, so he's a diehard Safari user. Whereas me, I'm wayward when it comes to browsers.

I'm wayward. Experimental. You've heard us say it before, but truly we believe that privacy is a fundamental human right. And it's something that we think about deeply as we think about how we're building our products. And you see that in Safari. You've seen it over the years since we were actually the first browser to include private

browsing. People forget this. But way back when, we introduced the world to private browsing. We were the first browser to block cookies by default. We introduced intelligence tracking prevention a few years ago. People may not know this, but back in March, we actually became the first browser to block all third-party cookies by default. I believe we're still the only browser to do that. So we have a long history here of being pioneers

and protecting user privacy. You see it even in this release from the protections that we built into extensions, into this release of Safari, to what we're doing with Privacy Report. Users are aware of how they're being protected as they browse. There are things that we do to protect our user privacy. We're also doing them because we think that we can help push the industry forward on this

in the hopes that users become more aware and they demand more from the technologies and products that they choose. Yeah, I think if we don't have people like you and Beth leading the charge and the rest of Apple to focus on privacy, I mean, it's a license to not care if you don't have companies like Apple stepping up to do that. At its core, not just in the Safari world, but at its core. Absolutely. And that's a responsibility that we take really seriously in the product.

It's not who we are to not care. We care deeply about our products and our responsibility to our users. So this is something that you're going to continue to see us pushing forward on, for sure. So security, privacy, and usability, these things are eternally at odds. You trade them off and we see people trading

privacy and security oftentimes for convenience to our own detriment and then it takes us a while to realize that that was a bad idea and we start to learn. And so one of the things that's been a long time problem for web developers and web applications is how do we do authentication? How do we do security? How do we manage these things in a way that's A, secure,

B, not annoying, and C, usable? And one of the things that seems cool is that you're bringing some of Apple's technology around Face ID, Touch ID, and these passwordless authentication schemes to the web. As a Face ID user, I just love when I can Face ID into an app.

If I can launch my bank app and not have to do a password, or if I can launch my whatever app that I would have to sign into and just Face ID boom, or Touch ID boom. Doing that on the web seems like it could be a nice balance between not giving up that security, removing the need for passwords maybe,

but then also having the usability of, I can just look at it or I can just double click on my watch. Tell us about Face ID and Touch ID for the web. Yeah, we're super excited about these. This is using the Web Authentication API, which is an open standard JavaScript API. And we added support for web authentication for use with public keys last year. I think it was last year, unless it was the fall. I think, let's say last year. and what's new now is that you can also use Face ID and Touch ID, and I think that that's going to be, like you, from the user perspective, that's huge, especially when I'm on my phone typing in a really long password. Usually I'll get the autofill, so that takes care of you too.

Right. But I just love that this will be an option. And I also love because it has this opportunity to give you that extra layer of security because it can be a second factor authentication also. And another thing that's really exciting about the Face ID and Touch ID for the web is the Apple Anonymous attestation part of it. So I don't know if you've heard about that.

That's a thing. So whenever you're doing one of these authentication processes, the website can ask for the security key or the phone, in the case of Face ID or Touch ID or Mac, to perform a process called attestation to prove that it really is what it says it is. And that can potentially be something, if it's always the same, if the security key is always returning the same attestation, then it's potentially a fingerprinting vector across different websites. But the way we'll do this for Face ID and Touch ID for the web is that each of the domains that you have a password with, that you have an account with, will get a different attestation. And that keeps it totally privacy-preserving,

removes the possibility that there's a fingerprinting vector there. So that's one part of that technology that I'm really excited about. That's very cool. So let's take a standard website that uses an email and password today, and they find out about Face ID and Touch ID for the web. What does it look like to integrate and get it set up? Maybe it's go read the web authentication API and leave us alone. But what does that look like? What are the steps?

It's not a lot. I don't have them in front of me, but basically there are really just a few JavaScript calls that you need to be able to make and use. And probably you need to add some user interface as well, where you're actually encouraging users to set up Face ID and Touch ID, because it won't be a replacement for your password since it's tied to your device. In case you lost your device, that would be a problem. So you still need a regular password, so it's like a second step. So creating that user interface is probably the hardest part, to be honest. The actual JavaScript calls that you

invoke, they're minimal and pretty straightforward. We have a session at WWDC this year all about this. Meet Face ID and Touch ID for the web. And there's some sample code in there that's very straightforward. Jared, you mentioned passwordless earlier. I didn't catch that as part of this talk. So is there something in there for passwordless that I missed? That they released? Not that I know of. I was just saying that perhaps it's a way to go passwordless

if you have a completely Apple-using. Face ID, text ID. Yeah, okay, gotcha. So I guess then that question might be then is what about passwordless sites? Because I know changelog.com is passwordless. We would probably add this as an alternative or as a secondary way of authenticating.

Or like Beth said, two-factor auth is actually a great use case for this because you can always fall back to the SMS. But as we know, the SMS-based two-factor auth is really fraught with all kinds of problems. Not to mention the one where it's not usually a second factor because if you're on your Mac, it autofills it there without having to have another machine. But regardless of that, I think as a second factor

would make a lot of sense. Unless you had a website that was like maybe macrumors.com. They could just go passwordless, face ID auth only. But they're probably the only ones, or all the other Mac sites. I think it's worth mentioning also that, of course, so many developers have adopted sign-in with Apple to replace the traditional account

so that users have this really seamless way to sign in across apps and the web. And so that's something that we've seen huge success with. I think we've had 200 million accounts created using sign-in with Apple already. It's a lot of millions. And a lot of developers are seeing actually an increase in accounts created, we think, thanks in part to sign in with Apple. So we're super excited about that as well.

Let's talk about the motivation there then for users to use sign in with Apple. Because you see sign in with fill in the blank all over the place. Why do people choose sign in with Apple and why you see sign up with fill in the blank all over the place. Why do people choose sign up with Apple? And why is that successful, I suppose? What makes people use that versus sign up with Twitter, LinkedIn, GitHub, you name it? Well, I think the big thing here, there are two big things. One is that it's so simple to sign up. We've made that process

seamless. You don't have to share your personal information. You're in control of it when you create an account. And you're not being tracked. As you use apps and across the web, we talked about how important privacy is. And this is just yet another example of that, of giving you a way to easily sign in, to be in control of your information, and to do it in a way where people aren't tracking your behavior. And you can kind of tell from the numbers that that's something that people care about, and it's a really big deal. Well, as I read off the list, too,

I sub-thought was those are all social networks of some sort, and Apple is not a social network so having my authentication tied to say twitter github which isn't really a social network but it kind of is or linkedin which totally is or facebook which well it's facebook totally you know it totally is so there's no scrutiny there. I guess I have less concern with if for some reason that got hacked, somehow I'd be tied to my social network being taken over by someone. We're in the fortunate position where our business is built on doing what's best for the user. So we don't need to compromise when it comes to things like

helping you log into a site. We get to put the user's best interest first. And you can see that in the product itself, the way that it gives users control. So there's web authentication API. I can back Beth up on her statement about the extensions API not being a simple thing. It's not like you guys just added one API

and you're like, hey, it works now. I actually clicked through on the link. We'll put it in the show notes. I just scrolled and scrolled and scrolled all of the... I mean, there's tons of stuff inside that. It's mind-boggling. And so you're adding lots of support for new things. Now one, I guess, reputation that Safari has got amongst

developers and web developers is that y'all have been slow to add new features, really web platform features over the years. And this has got developers to grumble about Safari. There's some that have even called Safari the new IE. I disagree with that. I think it's clickbait. But you've probably seen those kind of articles out there, not in terms of like, it's dominance, but just in terms of it slowly adding things, it's like, it works everywhere except for IE, was the old saying.

And there's lots of features that worked in lots of places except for in Safari. Web Bluetooth, WebVR, WebGPU, there's lots of them. I'm just curious what you all feel about that criticism. Do you think it's unfounded? Are you well aware of it? Does it hurt your feelings? Are you trying to change that perspective?

What are your thoughts on that? So definitely aware of it. And it does hurt my feelings, but we don't have to get into that. But when we add APIs to Safari, we want to be really thoughtful about it because the most important things to us, our core principles as a browser and as a browser engine, are privacy, power, and performance. And if a new web API enables those things, then we're super excited. We're all over it. A lot of the web APIs we've pioneered over the years have been APIs along those lines. And for APIs where we take pause and we have some concerns about power performance or privacy,

that it can easily be viewed as like, oh, just not implementing the latest thing to give the capability and I want to put all of my code together. But we just have some deeper considerations that we want to think through really carefully. That makes sense. Ronak, what do you think? Yeah, it's funny because I look back at the web standards process

and we've helped pioneer so many of the ways that we use the web today. So you go back in time, a good example is HTML5 video. We pushed hard for the industry to move to HTML5 video away from things like Flash, as an example.

Safari, especially on iPhone, played a huge role in that. We've continued to do that, actually, over the years. But like Beth said, we want to push the web forward while also putting user privacy first, while putting battery life first. Our users care deeply. They want our devices to have great battery life, to deliver great performance. And so we have to be really thoughtful about how we adopt these APIs because that's so important to us and it's so important to the user experience. And it's funny because those decisions directly translate to the performance that we're able to deliver.

They directly translate to our ability to deliver industry-leading battery life. I don't know if you've seen those numbers, but as an example, you can stream video on Safari up to three hours longer than Firefox and Chrome. And that's because, not just because we pay attention to optimizing Safari, but because we're really careful about what we support in our engine. I try to look up what Chrome's mission was in terms of what they're optimizing for. So you often think about what are you optimizing for? And what you're optimizing for isn't market share, at least on the Safari front. Maybe in other areas you might be as a company. But when I go, and these stats may not be accurate, but this is just a quick Google search.

Roughly 18.2% global market share for Safari, while Chrome sits at roughly 63.9%. So they may be optimizing for market share. You're optimizing for these sort of three pillars you sit upon, which is privacy, power, and performance. Meaning that the moves you make for Safari aren't just focused on getting it to be the best, most used browser. It may be the best browser, but it may not be the most used browser. You know, I think it gets even simpler than that. At Apple, we build the products that we want to use. And ultimately, you know, numbers aside, that's what it comes down to. And so we want a browser that protects our privacy. Just personally, that's the browser I want to use. I want a browser that preserves my battery. I want a browser that I can use without

slowing down my system. And we're always going to prioritize the user when we make these types of product decisions. And as we kind of think about what we're going to to prioritize the user when we make these types of product decisions and as we kind of think about what we're going to do in the future it's really as simple as that it might be marketing but it's on the marketing page so it might be marketing but you say we built Safari to be the best browser for your Mac, iPhone and iPad now that makes sense because you often build software

to compat very well with your hardware totally makes sense but you've got you know other safe browsers not to like brave and chrome has been you know has issues we've since moved to brave or other browsers to do that too but I've always seen safari as this privacy focused

safe focus but it hadn't been as clear as you just put it that as a mission of the company not just simply the product of safari but you two as folks behind it, making it work, being so privacy focused. Yeah, I mean, absolutely. Go ahead, Beth. Oh, I was just going to say, I don't even remember what I was going to say after definitely.

I was maybe just like agreeing. You echo that. Well, I mean, you know, I'd used Chrome for a while, as Jared mentioned before, Safari not being the primary developer target as a browser. And so when I would develop for the web and do different things, the browser I tended to focus on when it came to does it work first pass was Chrome. Dev tools, other things we could talk about are in the mix there that may be different, not so much lacking, but just definitely different in Safari.

And at one point, you all shared some similarities when it came to WebKit prior to the move to what was it called, Jared? Blink. Blink, yeah. So there's been some similarities in the past, but for some reason, web developers keep choosing Chrome, I think because its concern is bleeding edge, bleeding edge tech, pushing the web forward in those ways. Whereas Safari's focus has been really around

the browser you want to use rather than just simply the edge pusher. I think there is something to that. And I think that we do care deeply about developers too. And we care deeply about developers, too. And we care deeply about standards. And so we participate very actively in the standards processes. And we definitely think it's the better APIs come out because of it. And we care deeply about developers.

We do want to know what APIs you want to implement. And we don't want people to feel like we aren't listening, even though that can be the mood on Twitter sometimes, like you were saying. But we really welcome new feature requests, especially when you have a specific use case that you're trying to do, something you really want to achieve.

That's super interesting to us, and you should definitely file requests for APIs that you want to see. And while we're talking about developer tools, I do want to plug you to give a try to the Safari Web Inspector if you haven't tried it recently. We do have a session this week at WWDC about what's new in the Web Inspector in Safari.

And there's a bunch of great stuff this year, a ton to get into. One of the bigger things that we're pretty excited about is local overrides, which we think is going to be really useful when you're developing kind of something, a bit of a more complicated system, lets you intercept and replace response content that's loaded over the network in a nice way, and it will all stay stored nice in the Web Inspector. So we have a session all about that. The web inspector also has a nice new look that uses the space a little better. So if you haven't checked it out in a while

you should. And we really develop the web inspector in Safari Technology Preview, which is our every two weeks release of Safari. And our developer tools team really views that as their vehicle to ship things. They don't so much think of the annual release or the software updates. They're thinking about Safari technology preview.

So that's really where you want to go if you want to check out how the inspector is doing these days. Is there any sort of content out there from that team that people can follow? Like, how do you keep, if you want to pay close attention, how do you pay close attention? That's great. So yes, at webkit.org, we have a lot of blog posts there. And we do tend to post a good number about the inspector. And we also have the web inspector reference guide

on webkit.org, which is pretty thorough documentation. And we've also been at the WebKit Twitter account, we've been trying to post tips and tricks for the web inspector specifically. And I know that the inspector team and our evangelists have been working together to pull those together. So I concur the web inspector reference is quite comprehensive. You got search there, you got filters there, you got lots of different stuff from the console down to,

as you mentioned, local overrides for networking sources, etc. So it's, there's a lot there to dig into. We'll, we'll drop that link in the show notes for the listeners. Cool. Is the team that works on web inspector? Inspector, is that like Safari proper team? I'm always curious how these things work inside of an organization. I also want to know how you do Safari for iOS and Safari for macOS and if there's any shared infrastructure or code or if they're just completely bifurcated. So this is a huge question. But is the Web Inspector team just like they sit next to everybody else working on consumer products? Or is it just like separate? How does it work?

We're all one big happy team. Really? How many folks? Geez, I don't even know. But we all really sit together when we get to work from the office from Apple Park. In fact, there's an inspector engineer like two doors down from me. So we really, that is one of the things that I think is unique about our team, I think, compared to other browsers. Like the JavaScript core team is part of our team too. And I know other browsers there, whatever their JavaScript engine is, is sort of a separate situation. But we all work very closely together.

We work on all platforms. We collaborate on everything. So there's one Safari team across all operating systems. That's right. I've written code for iOS, WatchOS, MacOS, Mac Catalyst. One of the things I have to add is, we have this big releases here, and it's been pretty amazing to watch the team pull the release together amidst everything that's going on.

To see them continue to work together and deliver such a huge release has been pretty amazing. How do you know how you orchestrate something like that, especially across, specifically I think of iOS to macOS, because those safaris seem to be pretty different, except for the rendering engine. I'm sure there's a bunch of shared code. But is there some technical infrastructure,

some magic that y'all are doing to make those things merge at the right times? Or is there feature flags? How does it shake out? Mostly we try to do really thoughtful abstractions in terms of sharing as much code as possible. And yeah, of course, at the WebKit layer, that's most things.

But there are still some interesting diversions too. And you can see all of that in open source. We use the WebKit open source project. That's where we actively develop for all of our platforms. So in terms of WebKit, it's all just kind of out in the open. And yeah, Safari, they are different apps for sure. But when it's similar concepts, we try to just have really thoughtful abstractions to share as much code as possible one of the things uh mentioned in the keynote and beth you

got a nice feature in that keynote congratulations thank you i was hoping that you could make this call as part of that because i was like oh that's beth cool um run like you mentioned making a browser you want to use i would imagine a browser you want to use renders pages super fast, so page loading is faster, JavaScript is faster. What was some of the behind-the-scenes to sort of test and make sure JavaScript was faster

or page loading was faster? Obviously, I think it's unanimous across Apple when they release anything. This version is always the next big thing or the next best version, so it's common, it's cool, and it would make sense to be faster. Y'all should come out one time and say,

this is actually worse than last version but we've got to release it because we ran out of time. That would win some authenticity points. That's right. But what are the behind the scenes of actually making some of these things faster? Sure, so we have a bunch of the details around our testing on the website.

If you scroll down, you can take a look at that. But the idea behind the performance improvements this year was that we really wanted to improve performance of the things that you do every day. Of course, JavaScript is prevalent across the web. But loading sites that you load all the time, we want to make that super fast. And so we picked a set of representative sites, some with tons of JavaScript, the variety of sites that we thought represented what the types of sites users to commonly visit. And we spent a ton of time, the team spent a ton of time optimizing page load

to make that a really great experience. And even in this first seed, it feels really great. So we're not done yet, but we're super excited about how performance is looking this year. It's going to be great. We're pretty relentless about performance too. We have a number of benchmarks that we run internally, including all of the public ones. And we measure, we optimize, and we fix regressions. And it's just a never-ending cycle. We always have at least a zero regression policy, which is why you won't see us coming out and saying that it's slower than last year because we're constantly measuring. Going back to something that you said, Adam, about building Safari for users on Mac and iPhone and iPad. The other thing that we have a real

luxury, we're not building a browser that has to target every platform. We get to optimize Safari for Apple devices and Apple hardware. You see that. You see it as you use it. We do a lot in the product along those lines. For example, we use core animation to animate what you see on the web. We use native APIs that help us achieve that performance. We take a lot of pride in the craftsmanship that we put into Safari and taking advantage of the hardware APIs that have been heavily optimized to deliver that great

performance. I was thinking about market share when Adam was talking about what you're optimizing for. And I was thinking if they wanted the biggest audience, they would be Safari for Android and Safari for Windows. Then I thought, well there was a Safari for Windows at one point, wasn't there? There sure was. Is that thing still floating around? No, I think we stopped shipping it several years ago.

We did experiment with it and I actually think that we learned a lot from doing that. I think one of the things that we did learn was that we just had more fun when we were able to focus on our platforms and take advantage of what our platforms had to offer. And we focused on that since. And speaking of how we are one team, I also wrote code for Windows.

I was going to say, also core competencies. Stick to what you're good at. She can speak to this directly. Context menus. I did it. That's awesome. What do you say to home screen web apps? We talk about this ecosystem of platform.

We've got this scenario where you have apps installed, and obviously you're a fan of apps because there's an app for that. But then you've got this home screen web apps. What's the state of that for Safari and for iOS? Pretty much from the beginning on iOS you've been able to save a website to your home screen. In fact, that was the original app model on iPhone before we had third-party native apps.

The idea was that you could save a website to your home screen and get to it with just a tap. So it's something that we've supported. And of course, on the Mac, you can always just drag a site into the dock to get to it. So having access to your favorite web content is possible right from the dock or the home screen today. So we've been focused on that and also delivering great browsing experience inside the browser itself. We think that's something that users appreciate and use.

I would imagine Face ID and Touch ID brings those experiences a little closer. It doesn't give you quite login to the American Express or Bank of America app with your face, same experience, but you're sort of giving some of the credence that you've put in apps into the web. And that's kind of where I'm going at. We've talked about that to some degree,

but is there more behind the scenes of the adventure we'll have when it comes to home screen apps or web developers getting to appreciate the full web app experience? Well, I mean, I think you've seen us bring technologies to the web that do help deliver a great experience and take advantage of native technologies. Things like Apple Pay, being able to Apple Pay on a website.

Yeah, I love that personally. You mentioned authentication using sign-in with Apple on the web. And so I do think that we brought a lot of those capabilities to the web for web developers to take advantage of. They're experiences that I love to use personally, so I'm super excited about what we've done and potentially what we could do in the future. We'll see.

Do you all believe that web apps can compete with native apps on a level playing field on iOS on the long term? Or are they always be behind, always be hamstrung by the technology access? We love both native apps and web apps. That's why we have such a talented Safari team, really good-sized team that comes in every day trying to build the best web experience possible

for our users. It's why we do things like add amazing extension support, try to support the key standards out there on the web, build a browser that delivers great performance so users want to use the web more. I think that developers can build great web apps. And certainly our users are using them because we hear from them that they spend a lot of time

in Safari browsing the web, using web apps. So it seems like there are great apps being written and used out there on our platforms and in our browser. The reason I ask that is because it seems like when I look at the web technologies that y'all are usually slower to add or haven't added yet, it makes total sense that you're going for the power, the performance, and the privacy.

I think that's a nice killer three-piece. Adam and I both already memorized it, so you have a nice trio there. Even us louts can memorize that one. You add things that make sense. You've recently added lazy loading images. That's one that we've all been waiting for because that's performance.

That's great for websites. WebP was one that maybe you thought had some performance problems. I'm just assuming things happen. You're adding WebP, HTTP3. These are things that are being added or have been added in Safari 14. But it's the platform features like Web Bluetooth, Web VR, Web GPU,

where it's really like, hey, let's make the web a platform for apps that Safari doesn't support. And I think a cynical black box view of that, and I've seen it expressed out there as well, because you guys are not incentivized to do that because you have this native app platform and that would compete with your native app platform. And from the outside I can see where that's the conclusion made, but y'all are on the inside, so that's why I asked the questions. First of all, thanks so much for talking to us. This is awesome. What do you think of

that particular angle at why these particular features don't make it in the Safari? particular angle at why these particular features don't make it in the Safari. I don't think that's it. I think it's more that it goes back to something that we said earlier in the conversation, that we're incredibly thoughtful as we think about these standards that we add to Safari. One of the things that we've talked about a lot so far is privacy. As we think about these standards and the idea that somebody could get a link and go to a website that's asking to do a Bluetooth scan, that's something that we think about a lot. That's our job, to

protect our users and to think about privacy and to think about all the potential uses of these standards. And so we're going to continue to be really thoughtful about what we add to Safari. And we're going to always continue to put the user first as we think about these things. Yeah, I think one way to think about it, too, is that like a difference between the web and apps is that the web, you can stumble anywhere by accident. And we want that to be a safe place for you to end up. You can mistype a URL, somebody can send you a link and you don't know where it's pointing. With apps, if you've gone out of your way to download it, then there's maybe a little bit more intention behind it.

So the fact that it definitely is scanning for Bluetooth, maybe more thought got put into that. If you're just stumbling across the internet and there are all of these potential traps that you don't want to fall into, we want to really think that through. The web should be safe. You shouldn't be afraid to click a link.

There shouldn't be consequences if you go to the wrong site. So we're getting close to our time here. Is there anything on your list where you're like, I can't believe Adam and Jared didn't ask us about X. We've been waiting for them to ask and they haven't asked. What have we missed so far? There's lots to talk about, so it's hard to catch it all. I think we covered a lot of the highlights. This was a really good conversation. Good questions. Awesome. Well, we certainly appreciate you all sitting down with us and sharing such deep insight to a browser we all love and sharing similar desires for privacy.

Same desires, not similar, same, exactly. Because that's what I love most about Apple's direction at its core. And in particular with this conversation, Safari. So Beth, Ronick, thank you so much for your time today. It's been awesome. Thank you so much.

This is great. Thanks so much. This was fun. I don't know about you, but Jared and I were super excited to have Beth and Ronick on the show to share what Apple has to say about their big updates coming in Safari 14. Head to the show notes and click discuss on ChangeLog News. We'd love to hear from you.

And one of the best ways you can help us is by sharing this episode with a friend. You can tweet it. You can Instagram it. You can share a blog post with your favorite podcast and include us in it. Or you can even give us a rating or review in Apple Podcasts. And huge thanks to Linda for making this episode interruption-free. Also, thanks to Breakmaster Cylinder for making all those awesome beats for us. And last but not least, you can subscribe to all of our podcasts in one single feed.

Head to changelog.com slash master or search for Changelog Master in your favorite podcast app and subscribe. You'll find us. Thanks again for tuning in. We'll see you next week you Bye.