I have followed the SoupChef example in migrating Custom Intents from SiriKit to AppIntents. However, we only require one iOS release back, so we can require iOS 17. Thus, I eliminated everything that was strictly for backwards compatibility, most notably the SiriKit Extension that required enormous amounts of code to try to coordinate with the real app which worked poorly anyway. I tested for example that an NFC tag Automation created in Shortcuts works to execute an AppIntent while the app is backgrounded. I am now receiving a beta report that indicates someone trying to execute one of our migrated AppIntents from their HomePod is not working, and they say it used to work sometimes (not all the time). I'm sure most such cases used to require the SiriKit Extension in the old SiriKit world. I am terrified that I may need to rebuild that monster once again when the new (to me) AppIntent API seemed so beautiful without it and seemed to work without it. The AppIntent API documentation seems to indicate that SiriKit Extensions are no longer related or required. What is the truth here? Do I need to re-implement everything twice in the SiriKit Extension like a barbarian, or can we live in the new world with AppIntents? Thank you.

Need our app to launch in Full Screen mode. Have reviewed many years of prior solutions for this. All of them seem to be non-functional on modern Catalyst. There are some years where users suggest twiddling methods to use toggleFullScreen in Cocoa. That seems to no longer work in my tests? Then most recently Apple posts from last Summer announced a new key UILaunchToFullScreenByDefaultOnMac, but after reading lots of fine print it has a very strange scenario in which it does not work: Catalyst apps! So only unmodified iPad apps can use it! Very frustrating. So anyway, I have spent many days since last Summer trying again and again to figure out how to launch in Full Screen Mode. I've even tried AppleScript, but as it turns out that doesn't work either as for some reason you need to constantly reset the privacy permissions. Another feature from last Summer was in the 16.1 SDK, a new willConnectToSession attribute for allowsFullScreen. Unfortunately, that has no apparent effect. Allowing is different from engaging, and the "Enter Full Screen" menu item works fine so it was always allowed. The point is to launch in Full Screen all the time, or at least all the time when the user hasn't overridden something. I feel like there are so many proposed solutions to this, so many people who must need this, that I am surely missing something. What is the correct way to launch in Full Screen for a full-fledged Catalyst app available on the Mac App Store (and thus subject to all relevant restrictions thereof)?

The com.apple.developer.device-information.user-assigned-device-name entitlement works fine on iOS. Added to the exact same app, same Profile, on Catalyst. Build fine, installs fine from Xcode. Upload to App Store Connect. Failed upload due to Provisioning Profile not including com.apple.developer.device-information.user-assigned-device-name. Yet, manually verified that the Provisioning Profile does indeed include that entitlement and so does the App ID. Feels like an App Store Connect bug. Also verified that Ventura does indeed fail to return the name without this entitlement. Thus, this is a critical block.

We have a need for continuous background processing as we are a network listener observing the state of many local network items that have no understanding of anything like push notifications, etc.On iOS this can be solved via Guided Access, thus forcing foreground access on a permanent basis. In our case, users are perfectly fine with that as they purchase the Apple devices specifically for this software.On Catalyst, there is no Guided Access. I had assumed this would be trivial because Cocoa doesn't stop execution for background apps, but Catalyst appears to simulate iOS by trying to stop any app not in the foreground even when the machine does not even have a battery (eg. iMac) and the concept of background tasks framework to save battery makes no sense, and it does so pretty quickly (30 seconds - 3 minutes).In reviewing the new background APIs, all of it seems to ignore these use cases. My real question as per the title is "how do I get continuous background processing time on Catalyst?" As I have asked that fruitlessly for a decade on iOS, in this case I will modify the need to be more realistic, "given reality that Apple does not (yet) recognize network listeners as a valid background activity, what background behavior can I use on Catalyst to ensure as close to permanent background execution as possible?"Note that, while we require continuous background execution, our actual CPU time is essentially zero. We just listen for specific network activity and take actions based on it. So I'm trying to figure out the best heuristic to get the longest lasting execution time, specifically on Catalyst. Thanks for any advice!

We donate our custom intents to SiriKit. Our intents have a couple parameters like: Start Foo in Boo The generic intent title is "Start Things". We need to show the specific title with params and not the generic title in Shortcuts. The problem is that the Shortcuts app does not distinguish our intents so we get tons and tons of "Start Things" suggestions for each different Foo, but each line in Shortcuts Add Action and Suggestions is simply "Start Things" for many pages over time as the user performs actions in our app. I have noticed some other apps are able to customize that title. Find My shows a title as "Show the location of SpecificiPadName". OpenTable shows "Get details for 'specific reservation name'". I have not been able to do the same kind of customization. In Xcode intent definition, the Shortcuts app and Suggestions section for the Intent does not seem to be related to the string used in the actual Shortcuts app. The generic title of the intent is always used in Shortcuts until you open the suggestion at which point you can customize the params. Either we need to disable suggestions altogether to avoid the user having pages of un-distinguished titles, or we need to customize the title to show its parameters. I note that even though we have 2 parameters, the "Key Parameter" menu in the Shortcuts app section of the Intent is disabled – I cannot select a parameter there. Also, the "Summary" in the Shortcuts app section is simply not what is shown in Shortcuts. Anyway, obviously there is some trick to this, but I have not been able to find it. Anyone have any insight into this?

Starting early 2018, everything that has been announced as added to HomeKit such as HomePod, AppleTVs, Airplay 2 devices, and now TVs have not in fact been added to the actual HomeKit APIs. HMAccessoryCategoryTypes.h hasn't changed a bit. Iterating over all accessories of all types does not include any such accessories. So all of those things are not actually part of HomeKit, they seem to be just in the Home app only and not available via the HomeKit API at all.Needless to say, this is to put it gently inconsistent and users of apps that rely on HomeKit do not understand why HomeKit apps cannot access what otherwise seems obviously to be a HomeKit accessory in the Home app, not knowing that all such accessories have not actually been made part of HomeKit.Is anyone aware of some kind of statement or can someone please make a statement regarding what the expectation is here? Given the HomeKit silence at WWDC '18, I feel like it could be better to implement HAP in our app rather than use the HomeKit API at this point if we can't get a clear statement that the HomeKit API will be kept up to date as it is now at least a year visibly out of date with devices that users are incorrectly made to believe are part of HomeKit.