Xcode console print from autofill extension on MacOS

Question

Created 1w

Replies 3

Boosts 0

Participants 2

On iOS when I run my Autofill extension target from Xcode and attach to Safari, Swift print() statements appear in the Xcode console log. If I run the same extension on MacOS Sequoia, no log messages appear. The header strip in the debugger area remains blank. Anyone know how to see these log messages?

In both cases, the scheme is set to Debug build, and "Debug Executable" is not selected. In fact, for iOS the "Debug Executable" is grayed out. When I set Debug Executable on the MacOS run, I get failure to attach with a warning about permission to debug Safari.

Answered by DTS Engineer in 858745022

The more obscure your app or system extension, the more important it is to lean into the system log. Logging to stdout is fine for simple things, but once you start building a complex product you usually run into some case where you can’t see such output. Moreover, you can never see such output once you ship your product, which makes it much harder to debug problems that only show up in the field.

So, my advice here is that you use this as an opportunity to switch over to the system log. It’s easy to use, has many great features, and your log entries will be visible regardless of the context.

See Your Friend the System Log for lots of hints and tips on this front.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

1w

Accepted Answer

Recommended

The more obscure your app or system extension, the more important it is to lean into the system log. Logging to stdout is fine for simple things, but once you start building a complex product you usually run into some case where you can’t see such output. Moreover, you can never see such output once you ship your product, which makes it much harder to debug problems that only show up in the field.

So, my advice here is that you use this as an opportunity to switch over to the system log. It’s easy to use, has many great features, and your log entries will be visible regardless of the context.

See Your Friend the System Log for lots of hints and tips on this front.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1

Answer 2

timsm OP

1w

Thanks, I should have mentioned that I also tried OSLog and could not see any output in the console app. All I did was:

let logger = Logger()
logger.error("authFill some text")

Now, I am realizing the outward behavior is a little different on MacOS, so possibly

prepareInterface(forPasskeyRegistration registrationRequest: any ASCredentialRequest)

is not executing on MacOS (Designed for iPad). On both systems, it is popping "Create a passkey" dialog and letting me choose my provider and continue. But on MacOS it then displays my CredentialProviderViewController view. That never appears on iOS. I just get the desired callback to prepareInterface. I will investigate further.

At this point, I am just trying to understand the webauthn/fido flow and implement my own key management and signing. I guess I can do that just as well on iOS, and worry about MacOS later.

0

Answer 3

timsm OP

1w

Getting the system log working solved my root problem with a helpful message from com.apple.AuthenticationServices.Helper that my ASPasskeyRegistrationCredential was missing a required flag. Setting Backup Eligible and Backup State authData flags to 1 allowed my registration to succeed.

Note sure why I didn't find anything on my first look at System Log. Originally, my AutoFill extension was attached to a Made for iPad StoryBoard app, but that was not entirely functional on the Mac. After I attached to a container app for native Mac it worked correctly and I found the log message, though some generated within my extension still seemed to be missing and some parts were redacted.

Other point that threw me off was the iOS version was not showing my UI after I hit the Continue button. I didn't care because the data dumps I was interested in were in the prepareInterface call. Eventually, I realized that tap Continue a second time would prepareInterface again and then show my extension view. I think maybe this is a timing issue related to debugger attaching. About 1 in 10 times it would go to the view with a single Continue tap. This is all proof of concept right now, so probably can fix if need be. Or, maybe just goes away in release.

0