My observations with Xcode 15 and iOS 17, 17.01, and 17.02: Background: We recently completed development of a complete re-write of our App. The App is lean by design and has an installed size of 32 MB for a Debug Build. Release builds have an installed size of 9 MB, and the IPA size (compressed) is just 3.2 MB. Launching an App from Xcode 15 to an iOS 17 device now takes minutes. The longest timed launch was a little over 3 minutes. Even then, the App would become unresponsive to taps and froze temporarily any time the keyboard was summoned. Whether the device was connected by a physical cable or not had no bearing on these symptoms. Using the debugger and have it actually stop at a breakpoint took an inordinate amount of time. Using a device with iOS 16.6 or 16.7, and keeping everything else the same (and using a cable), results in a 3-4 second launch. This is typical for the App. Different Macs with varying configurations all exhibit the same exact behavior: things work great on iOS 16 but come to a screeching halt on iOS 17. This leads us to believe there is something fundamentally broken in iOS 17. Perhaps it's the new architecture that Quinn mentioned, but that is just conjecture. As an organization, we have halted the use of iOS 17 devices for development, and reverted to iOS 16 devices for the time being. Being a small outfit, we simply can't afford the time (and patience) needed to develop and debug on iOS 17 devices at this time. Lastly, we started experiencing App launch issues towards the end of the Xcode 15 and iOS 17 beta period, the initial betas did not exhibit these issues. This post may not be a constructive one, but i wanted to share my experience and hopefully a temporary workaround (the use of iOS 16) for an issue so many of us are facing. i do plan on opening a feedback using the steps Quinn outlined as soon as my schedule permits.

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

@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

@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.

@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.

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?

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".

@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.

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?

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).

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.

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.

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.

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?"

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