I am writing a communication app that relies on the INShareFocusStatusIntentHandling protocol. However, it appears this API is not functional, even with the proper permissions and entitlements.
Given the example code here, I am unable to trigger the logs in the INShareFocusStatusIntentHandling extension.
In this code, when enabling or disabling focus, line 33 of IntentHandler.swift never gets logged, even though FocusStatusCenter is authorized for parent app, UserNotifications authorized for parent app (target), and Communication Notifications entitlement has been added to the parent app. I am also unable to hit any breakpoints in the extension. It seems as if the extension is simply never triggered -- maybe even broken at the OS-level.
I have tried both iOS 17 and the latest 18 beta. Other users have reported similar difficulties in these forums.
To replicate, Install the example app. Give the app UserNotifications and FocusStatus permissions. Background the app. Change focus status. Check console. Notice that the extension handler is never triggered/logged.
I am unable to trigger the logs in the INShareFocusStatusIntentHandling extension. [...] I am also unable to hit any breakpoints in the extension.
I just built this sample with Xcode 16 beta 4, and ran it on iOS 18 beta 4, and hit a breakpoint the intent extension. What you're running into here is that you are not attached to the correct process to see the logs, or hit those breakpoints. Debugging SiriKit intents requires you to think in terms of a multi-process architecture, which can be different than the standard debugging workflow when working on your main app.
To setup a debug session correctly, using the Debug > Attach to Process by PID or Name menu is very helpful. The process name you're looking for will be the name of the extension target, which is IntentHandler for the sample code you cited. If you enter that into the dialog box, the debugger will wait for a process with that name to be launched, and when that happens, it will attach to that process so you can hit breakpoints, or see the logs like you're expecting.
SiriKit extension processes are typically short lived, and have time-based deadlines to hit on the order of a few seconds. This is so that customers who invoke an intent through Siri aren't left waiting for an extended time wondering if their request was handled or not. However, this also adds an extra challenge with the Attach by PID workflow — in addition to the system doing the work to launch the process, it needs to do more work to attach to it with LLDB, which consumes some of that time. That's where proper logging technique comes in, so you don't always need to rely on breakpoints.
In this sample project, it logs using a simple Swift print statement. While that's a common way of logging for doing small amounts of iterative debugging work at your desk, you're not going to see a print statement in the Xcode console unless your attached to the process with LLDB. A much better logging approach is to use structured logging through the Logger class. You'll still get those messages in the Xcode console if you attach to the process with LLDB, but additionally, you can view them using the macOS Console app without needing to attach LLDB at all. When configuring your Logger instance, you can declare a subsystem name reflecting your needs, and then use the filtering features in the macOS console app (or Xcode, when attached to process) to filter and only view the logs for that subsystem.
— Ed Ford, DTS Engineer
