@AveD I agree this is wild change in a dot release. Absurd, even given I had to post this to get an acknowledgement. Out of curiosity, where are you seeing the hidden line in the release notes? I didn't see anything about this at all.

@Frameworks Engineer Thanks for the quick reply. I'm having trouble squaring it with what I'm seeing though, and I'd appreciate a little more detail & clarification so I can handle the layout for the Duo correctly in our app. This only happens on the iPhone Duo. On the same iOS 27.1 runtime, the same cell on iPhone and iPad gets nonzero margins. If the default changed to zero for every UIView in 27.1 as you stated, I'd expect it on every device. So it implies a special case for Duo for every cell / view that relies on this. Why am I seeing behavior specific to Duo if all UIView layout margins are expected to be zero? This guidance contradicts longstanding guidance and documentation. The current layoutMargins docs say the following: For other subviews in your view hierarchy, the default layout margins are normally 8 points on each side, but the values may be greater if the view is not fully inside the safe area or if the preservesSuperviewLayoutMargins property is true. If zero is now intended, the docs and release notes don't say this. Further, the previous understanding meant that preserving the superview margins could mean my view inherited greater margins, which is not what I want. 3.. The suggested fix doesn't restore vertical spacing because the superview's margins are also zero. Further, view controller's systemMinimumLayoutMargins are zero on top and bottom on iPhone, so inheriting them with preservesSuperviewLayoutMargins would still give zero vertical margins. Here's the result of the suggested fix. Vertical margins are still zero. Given the above, are we still positive this issue isn't a bug?

FB24520413

The behavior you want should work well with AppShortcuts. Make sure you have configured your AppShortcutProvider correctly and provided a large list of phrases (ways that users can invoke the shortcut). Each phrase must have \(.applicationName) in it. So long as Siri picks up one of your exact invocation phrases it will work. Sometimes the dev environment is a bit flakey, and invoking shortcuts bugs out, but make sure everything is on Beta 3, it's been a slightly better release.

No. Siri won't see any of your non schematized App Intents or entities. The only way to do what you want is to make the first AppIntent that runs an App Shortcut. If you return a partial list of indexedentities in a snippet or something and properly annotate them, Siri should have a limited conversational understanding about which one you want to proceed with on confirmation, but again the initial bit has to be invoked via AppShortcut if it's not schematized. I recommend filing some enhancements since this is quite silly if you ask me!

Not sure why they continue to play coy about this, but the correct answer to your question is no. In the current incarnation of Siri AI and App Intents, the only way to get Siri to invoke your intent or use your AppEntities is if they are schematized. If not, Siri won't do anything new. The "solution" they give to this is AppShortcuts, which run your intent based on a phrase invocation. The claim made by the DTS Engineer is presently false. It does not interpret invocation phrases naturally now, they must still be explicit and exact. Please file some enhancement requests along with me so we can try and get custom schemas that expose IndexedEntities and other intents to the system one day.

Still present as of Xcode 27 beta 3.

I think LongRunningIntent is designed to run in the background. When your app is foregrounded, it can't run tasks that require your app to be in the background. I'd be interested if this works if you call the intent from a widget using that same type of button.

Hi Albert, I appreciate the feedback. Responding to this part: Siri cannot spontaneously read the properties of your BuildingEntity to answer a conversational question like, *"How many accessible entrances does Orton Hall have?" unless you explicitly build an Intent to answer that exact question. When you mark an AppEntity as an IndexedEntity @Parameter(title: "Building") you are giving Siri a list to use for resolution. While this is true conceptually, which I understand, it isn't true in practice. Siri in its current iteration does not gain access to this information, or at least, will not recite it, without these intents being schematized. I guess it's sadly that simple. I wish it worked like you mentioned, but after building this exact setup, it doesn't work. The reason the Apple samples only cover calendar events or music playback is because that's all that works (since those entities can be schematized) Otherwise Siri has very limited semantic understanding of the searchable index.

Same here. Also very flaky invoking app shortcuts by their phrases. Half the time it doesn't work.

I had some provisioning issues I needed to sort out with my developer account, but once I was able to test on device again, I confirmed that this issue seems to only affect the simulator.

Hi Albert, Thank you for your reply. Yes I was able to reproduce this with a sample project and have provided it in a feedback: FB23222130. macOS 26.5.1 (25F80) Xcode 27 Beta 1 27A5194q iOS 27.0 Beta 1 I'm not doing anything out of the ordinary, just did the exact steps shown in the WWDC video on AppIntentsTesting. It runs in a UI test runner that utilizes the main app target, just as shown. Other AppIntentsTesting modalities seem to work fine. Sometimes the above code sample will execute with the error I provided, but I have also seen a crash in it which no specific error information is output. I am running on a sim and will test on device. I will note a separate issue: that because these tests are invisible, you can't witness anything happening on screen, however, Device Hub will be forced as the front window each time a test attempts to execute. I get why this happens but I personally don't love this behavior. I may file a separate feedback on that.

Thank you for the reply. FB23176939 is the feedback which includes a sample project with instructions that reproduces the issue on Xcode 27. I have constructed the AppIntent in a similar way that we have in our main project, so I am not sure if that is contributing to the cause of this bug, but it seems that using any bespoke AppEntity can cause it.

Same issue here. The fix is to either fully reboot your machine or run killall -9 CoreDeviceService in Terminal. Let's keep this thread active for all that experience this, since we shouldn't need a fresh reboot to install Xcode!

Post the whole example. Does the same code work on 18?