AlertBridge is not a class of mine. Strangely, the stack trace reported by Crashlytics does not have any of my code. Here is the complete stack trace. Again, none of the classes seen in the stack trace are mine. 0	SwiftUI												0x1c9bf3ae8 AlertBridge.preferencesDidChange(_:) + 2604 1	SwiftUI												0x1c97eb474 _UIHostingView.preferencesDidChange() + 412 2	SwiftUI												0x1c98b92cc ViewGraph.updateOutputs(at:) + 180 3	SwiftUI												0x1c9b58e10 closure #1 in closure #1 in ViewRendererHost.render(interval:updateDisplayList:) + 816 4	SwiftUI												0x1c9b582b0 closure #1 in ViewRendererHost.render(interval:updateDisplayList:) + 524 5	SwiftUI												0x1c9b4f1b8 ViewRendererHost.render(interval:updateDisplayList:) + 316 6	SwiftUI												0x1c9c75748 _UIHostingView.layoutSubviews() + 160 7	SwiftUI												0x1c9c75774 @objc _UIHostingView.layoutSubviews() + 24 8	UIKitCore											0x195f657fc -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2144 9	QuartzCore										 0x198509494 -[CALayer layoutSublayers] + 284 10 QuartzCore										 0x19850f5ec CA::Layer::layout_if_needed(CA::Transaction*) + 468 11 QuartzCore										 0x19851a128 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 140 12 QuartzCore										 0x198462b44 CA::Context::commit_transaction(CA::Transaction*, double) + 296 13 QuartzCore										 0x19848c4e4 CA::Transaction::commit() + 676 14 UIKitCore											0x195ada9d0 _afterCACommitHandler + 140 15 CoreFoundation								 0x19197af2c CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION + 32 16 CoreFoundation								 0x191975e20 __CFRunLoopDoObservers + 420 17 CoreFoundation								 0x19197629c __CFRunLoopRun + 968 18 CoreFoundation								 0x191975ba8 CFRunLoopRunSpecific + 424 19 GraphicsServices							 0x19baec344 GSEventRunModal + 160 20 UIKitCore											0x195ab13e4 UIApplicationMain + 1932 21 Kevo													 0x1029d1418 main + 17 (main.m:17) 22 libdyld.dylib									0x1917fd8f0 start + 4

Using Xcode 12.2 and this still happens. Xcode crashes if i tick another language.

Mattes, i have the exact same problem although my intents are implemented using in-App Intent Handling (new in iOS 14). i learned that if i turn the Show When Run option OFF for the shortcut, Siri will no longer speak the custom success responses, it will only say things like "Done" or "OK". Turning the Show When Run option ON makes Siri speak the custom success responses. This behavior is acceptable if the intents are performing an action and "Done" or "OK" will suffice to let the user know that the request was competed. However, it defeats the purpose if your intent is returning information that the user requested. e.g. "When will my package be delivered?"

i would strongly caution against proceeding full-on with SwiftUI, it is just plain broken in a lot of places. The list of things that don't work in SwiftUI seem to grow the more you use it. For instance, SwiftUI does not offer a pull to refresh feature (a deal breaker for me). SwiftUI provides no way of customizing the return key type on a keyboard. Keyboard support in general is just lacking, there is no way to set a first responder and no way to resign a first responder. Using UIHostingController to bridge UIKit code to SwiftUI leads to other issues like Lists not behaving as they should (NavigationLinks will remain highlighted after you return from the Detail View). And the list goes on and on.

InstantInteractive, it is easy to get around not being able to customize the return key type on a keyboard: You simply create a UIViewRepresentable that wraps the good old UITextField we have come to know and love; it sucks to have to do it this way but at least there is a workaround. For some of the other issues i mentioned in my initial reply, there is no workaround. Don't get me wrong, SwiftUI is here to stay and is indeed the future and when things work, it's magic. i can understand it having bugs when it was first released in iOS 13, but glaring issues and feature omissions remain in iOS 14 as well.

It is both bizarre and disappointing to see Apple make a splashy announcement in the Keynote (and the session on Wallet) on Home Keys without providing any documentation to developers.

Thanks for the reply! That makes a lot of sense. After some testing i can confirm this is indeed the behavior: Given an uninterrupted WiFi connection, the currentPath remains .unsatisfied after the App is launched until the first invocation of pathUpdateHandler (which happens right away); it then transitions to .satisfied. The first invocation seems more like the initial state vs. a changed state. i.e. the first invocation it is not an indication that network availability has truly changed (which was my initial assumption).

This is still happening in Xcode 13.2.1. i have 2 intents generating a total of 80 warnings all of the "Multiple declarations found and ignored" variety. Can someone else on this thread confirm?

@denrase: i meant to post the solution here sooner, i finally got it to work late last night. Take a look at the code below. This appears to be an issue with LocalizedStringResource and string interpolation (i think). When the DisplayRepresentation sets the title to "\(title)", it causes the resulting shortcut to have a %@ in its title. Changing it to use a LocalizedStringResource with a default value gets around the issue. struct BookEntity: AppEntity { static let defaultQuery = BookQuery() static let typeDisplayRepresentation = TypeDisplayRepresentation(name: "Book") let id: UUID let title: String var displayRepresentation: DisplayRepresentation { // DisplayRepresentation(title: "\(title)") // This causes the %@ to appear in the shortcut title DisplayRepresentation(title: LocalizedStringResource("%@", defaultValue: String.LocalizationValue(title))) // This works     } } i don't have a Localizable.strings file in my project, so using just "\(title)" should work. Will log a feedback on this issue.

For my App, CFBundleDisplayName is in Info.plist but SiriTipView (the SwiftUI equivalent) will not show the App name, and as others have mentioned, the App name is also missing when using ShortcutsLink. Both of these are annoying bugs i hope will be addressed in 16.1. Note: When running 16.1 Beta 4 on a real device, SiriTipView does show the App name like it's supposed to, but alas the ShortcutsLink still shows "shortcuts".

For an iOS App offering Sign-in-with-Apple, it remains unclear whether triggering Account Deletion from within the App is also expected to call the Revoke Token endpoint. At the moment, the access and refresh tokens (which are obtained by calling the Generate and Validate tokens endpoint) are NOT stored by the App or our backend; this call is never made. When deleting the account from the iOS App, is the App or our backend expected to call the Revoke Token endpoint? or is it sufficient to instruct the user to Stop using their Apple ID with the App in iPhone settings?

@DelawareMathGuy Thanks for the detailed reply. Although i could nil-coalesce every single access to a Core Data property in the SwiftUI views, doing so for more than a handful of properties seems impractical. A lot of the properties are not marked optional (model and class), making this approach more challenging. i could change the NSManagedObject subclasses so properties are optional, but there is a sizable non-UI portion of the App that makes heavy use of Core Data; changing the optionality of properties would result in a lot of re-work. Again, thanks for the reply. i will checkout the App you linked to, it might give me insights that prove helpful.

@ekalaivan if you are using iOS 17, i'm afraid parametrized shortcuts and Siri are broken. Shortcuts that were working on iOS 16 - and have been since iOS 16 was released - are now broken when using Siri on iOS 17. You can say the phrase exactly as you're expected to, and Siri does understand it, but it will fail to run. There is nothing you can do but wait for the next beta to correct it (hopefully). For us, it's especially troubling as we have customers who are using our App and absolutely love the fact they can carry out many actions using Siri without ever opening the App. My hope is that this is just a beta thing and will get corrected in future betas.

@ekalaivan it's not obvious what the issue is from looking at your code. Do your shortcuts work in the Shortcuts App? i.e. are you able to run them without using Siri? The Automatic shortcuts should show up in the Shortcuts App with different permutations of search type. if your shortcuts are working in the Shortcuts App but fail with Siri, it's hard to diagnose the root cause. Sometimes you can view a sysdiagnose and glean what may be causing the failure but outside of that, Siri is a black box. Your only recourse here is to file a Feedback. if your shortcuts are NOT working in the Shortcuts App, here are some things you can try: Don't set an OptionsProvider. My intents don't have that (yet) and the shortcuts are able to provide options when needed using suggestedEntities(). This may not be the correct thing to do but letting you know what works on my end. Add a shortcut phrase that only has the applicationName and see if this works. Regards, noKey

Unfortunately, the changes you are seeing are permanent. We had no choice but to remove the feature that relied on CoreMotion from our Apps.