Can someone explain the security of this? Obviously I doubt that my facial data would be shared with the website, but how does it remain secure?
You have an abstract software or hardware 'thing' which performs authentication, called an "Authenticator", which can prove either user presence and consent, or perform user verification (e.g. local authentication). Since authentication is basically proving that you are the same party as seen previously, it is done by creating and later using public-private key cryptography. This is the same technology that say a Yubikey has supported for many years - a modern USB security key is another supported type of Authenticator.
You as a user will register your phone with a site either on registration or while logged in - which shares a new, unique public key with the site. When you try to log in later the authenticator is invoked (aka a local FaceID or passcode check), which releases the use of the private key to 'prove' it is the same person to the web site. This is all done using a W3C standard called the Web Authentication API.
Native apps support this in much the same way, but the API is vendor specific. A native app will usually only be able to request this for websites where the site administrator has opted-in an app, to prevent phishing.
The public key is unique to the registration, and the authenticator by default is anonymized (e.g. they know it was an apple device, potentially down to make and model of phone, but not that it is a specific phone). As a result, the same phone can be used to authenticate across the internet without different websites being able to correlate and track you.
Because the authentication happens at the browser/platform level rather than via site javascript, it privates a strong phishing protection - it is basically impossible (without the platform, browser, or site being compromised) for someone to 'trick' you to authenticate into a fake site, then turn around and leverage that to get into your real account.
For example, Google announced a few years ago that when they had employees go to this model (using hardware security keys at the time) they had their phishing-related security incidents drop to zero.
https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/
So your biometric data never leaves your phone, instead it works in terms of dynamically generated public/private keys.
The two big things today are:
1. Support for synchronizing the private keys and site registrations the same way that the platform-implemented password managers synchronize passwords for sites today. On Apple platforms, this is done atop iCloud Keychain. So, if I set this up on my phone it will automatically work later when I try to go to that site on my Mac, using the Mac's TouchID.
2. Support for use of cell phones as authenticators across platforms. So if I have an android phone and set that up with a site, I have a way to my android phone to log into a site while on my Mac.
Would website devs need to drastically change how they code websites or would the phone handle the translation between the website asking for a password and the user just being able to scan their face?
This is a different, more secure mechanism than passwords. So the site needs to have code that can handle the public/private key cryptography, to store it, and to handle the authentication request/response messages that leverage them.
The site will also need some javascript on the page to request this be used, typically behind an additional login option button. There is code out there to help with this, typically with both back-end server and front-end web framework components. For many sites, they will want to add more logic to support and promote this - for instance, to allow for multiple registrations (e.g. my iPhone and my Windows desktop can both work to sign in to a site), and possibly to edge people toward deleting any legacy password option.
There is separate ongoing work, outside what was announced today, to try to optimize the overall user experience. The addition of a new login option button means the user needs to have education on what that does. It would be far better if (as a few websites already do) you just had a prompt from the site - "Would you like to use FaceID/TouchID to sign in going forward?". Then, when you return to the web site in the future, your browser itself handles surfacing that as a potential login option.
