For Swift packages published as source, say version tags referenced in a Github repository, is there a way to provide such supply chain integrity protections, such as via signature on a git tag? Or are supply chain protections currently only usable when third parties ship binary builds?

Passkeys are WebAuthn. The change is that your Apple account is the authenticator, rather than one piece of hardware.

WebAuthn divides authenticator connections into two categories: Platform authenticators which are provided by the device itself. Passkeys as well as the existing FaceID/TouchID support in Safari fall into this category. You can typically only use these on the same machine as before, although Passkeys is trying to expand these to be synced across devices on your Apple account. Cross-platform authenticators (or "roaming" authenticators), which communicate over some sort of transport like USB, BLE, NFC, etc. These can be used whenever the authenticator is available over that transport and the browser/platform you are on supports them - most Macs are not going to have much luck using NFC to talk to an authenticator. That said, there's nothing saying an authenticator can't be both - that you couldn't use your iPhone as an authenticator for your Windows laptop over USB/BLE/NFC. This is possible today. That said, there are some issues with the bluetooth transport support. One is that you can't be sure you are pairing with the actual device, rather than an intermediary. Another is that the pairing with devices is at the platform level, while often it is the browser which really needs to establish and maintain that pairing. Keeping the bluetooth radio active in case an authentication request is sent is expensive, and trying to increase the reliability and decrease the latency when that message is sent is challenging cross-stack. Google has been experimenting with solutions here, including a project called CaBLE which has been iterating within Chrome. CaBLE uses QR codes to establish a link between two devices rather than using traditional bluetooth pairing, and can synchronize that pairing between computers (for instance, across chrome instances signed into a google account). While I am not privy to Apple's plans, I suspect they would be more inclined to these roaming approaches where other devices could use your phone as an authenticator, rather than letting the secrets be shared to non-Apple devices. Higher security uses such as enterprise and financial login will be paying close attention to the level of protection Apple's platform provides for these secrets when deciding whether to accept Passkeys.

FIDO is accessible on the web from modern Web Authentication API - https://www.w3.org/TR/webauthn/ or on some browsers using the older U2F JavaScript API. I cannot speak for Apple, but the intention of WebAuthn is that the same API can be used for both an external security key and the local platform authentication capabilities. The catches for supporting the Apple platform authenticators will likely be: A site needs to ask for authentication from a user activated event. A site cannot request platform authentication merely from a user loading a page, as the request for authentication will obscure information on the site the user would make to decide whether they want to authenticate or cancel out. Also, repeated attempts to authenticate a user is an abusive user experience. If your site filters which authenticators are usable via attestation, it will need to add support for apple devices. This may include needing to evaluate a new attestation data format - I haven't seen anything from Apple yet on what they are doing here outside the video, which says that this is not yet available in the first betas Like with security keys, only the Web Authentication API is supported. U2F is not available on Safari, although I believe site migration from U2F to WebAuthn is supported as described in the WebAuthn spec.

let dateFormat = DateFormatter.dateFormat (fromTemplate: "j",options:0, locale: Locale.current)Should give you a string back, such as "HH" (for 24 hour time) or "h a" (for 12 hour time with the appropriate AM/PM distinction for the locale)