By my understanding, you have three options: talk to the webauthn.io administrator, use a commercial service, or create your own Relying Party Server. Webauthnio route. You are effectively asking that the site admin permit a strange and untrusted application to write content into their database. I would be very hesitant to do so if asked. Commercial service. There are a number that seem to exist such as Stytch. When I looked several months back, the pricing was prohibitive for small projects but Stytch appears to have a free, low volume option. Create your own. There are a number of libraries available. If you do server-side swift, there are two projects on github that might help: swift-webauthn and webauthn-swift. The first is from the Vapor guys. For our own efforts (and perhaps because the team embraces pain), we ended up writing a Relying Party Server from scratch using grpc-swift to communicate between the Apple clients and server. This is not a good general solution as it doesn't allow web clients. While it has worked great for us, I will advise against this route given the complexity of the Webauthn specification.

If anyone else encounters this, the issue appears to have been environmental - possibly something in the package cache - that survived 'swift package clean' and 'rm -rf .build'. Very frustrating.

I recieved a response on FB13085924: "Investigation complete - Works as currently designed". Not the answer I was hoping to get.

This appears to indicate that too many changes were made to the database without calling ModelContext::save().

I'm not sure how to use CREATE_INFOPLIST_SECTION_IN_BINARY with SPM, but I've found that adding linkerSettings to the Platform.swift file works well. linkerSettings: [ .unsafeFlags([ "-Xlinker", "-sectcreate", "-Xlinker", "__TEXT", "-Xlinker", "__info_plist", "-Xlinker", "Sources/Builder/Info.plist", ]) ]

Add special linker settings to reference Info.plist and define that file. targets: [ .executableTarget( name: "MyProgram", dependencies: [], linkerSettings: [ .unsafeFlags([ "-Xlinker", "-sectcreate", "-Xlinker", "__TEXT", "-Xlinker", "__info_plist", "-Xlinker", "Sources/Resources/Info.plist" ]) ] ), ]

I've submitted FB13085924 and noted that it likely duplicates the issue in FB13034576.

The documentation is far less helpful than one would like. Here's what I've found to work so far. The apple-app-site-association file must reside on a publicly accessible web server with a valid TLS certificate. (see https://jaanus.com/universal-links/). I specified 'web credentials:mydomain.com?mode=developer' in Associated Domains in the Signing & Capabilities tab in Xcode. On the iOS device, enable Associated Domains for development. This is found under Settings > Developer > Universal Links: Associated Domains Development On the Apple Developer website, I have added an identifier for my application with 'Associated Domains' enabled to the Certificates, Identifiers & Profiles list of identifiers.