It appears that the only way to access any information about a cell's corner radius is obtained only via the cell's layer cornerRadius. List cells never get their corner configuration updated in grouped configurations. Further, I have noted that as of Xcode 16.0 Beta 7, accessing .cornerConfiguration on UICollectionView.appearance() causes a segfault (FB20029166).

I think it's failing because you setup your URL scheme in the editor to a bad format. Follow this closely and try using that first. You just setup the scheme and you can parse the query property in the app delegate method. https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app You have your control setup correctly to open the url, but the answer on this Stack is also helpful for parsing and adding query items. You can add that bit of code in your intent / app delegate for parsing and formulating the URL: https://stackoverflow.com/questions/73418995/open-url-scheme-through-widget-tap-ios-16-widget-kit

Hi Dudi, Based on my own testing, I'm not sure if you can reload all controls from inside an AppIntent that is running outside of the App's execution scope. It seems like you can only get a definite reload if you call that from your running app. It would help to know where you are storing your counter value, as that could also affect this.

Really appreciate you clearing that up and ensuring the proper visibility for that feedback. Thank you!

@marudavid I am not able to reproduce your issue using the following sample code. There is a default background color always on both Xcode 15 and Xcode 16.1 Beta. It is possible you are using some type of ViewModifier that is causing this. The following works fine. import SwiftUI struct Icon: Identifiable { var id: String var color: Color } struct ContentView: View { let icons = [ Icon(id: "figure.badminton", color: .red), Icon(id: "figure.fencing", color: .orange), Icon(id: "figure.gymnastics", color: .green), Icon(id: "figure.indoor.cycle", color: .blue), Icon(id: "figure.outdoor.cycle", color: .purple), Icon(id: "figure.rower", color: .indigo), ] @State private var selected: Icon? var body: some View { LazyVGrid(columns: [.init(.adaptive(minimum: 100, maximum: 300))]) { ForEach(icons) { icon in Button { selected = icon } label: { Image(systemName: icon.id) } .foregroundStyle(icon.color.gradient) .font(.system(size: 100)) } } .fullScreenCover(item: $selected, content: { icon in DestinationView(icon: icon, animation: animation) .onTapGesture { selected = nil } }) } } struct DestinationView: View { var icon: Icon var animation: Namespace.ID var body: some View { Image(systemName: icon.id) .font(.system(size: 300)) .foregroundStyle(icon.color.gradient) } } #Preview { ContentView() }

Sadly I don't believe this is possible, as AppShortcutsProvider requires a static array. It also does some ML magic under the hood at compile time that likely precludes an array of dynamic AppShortcuts from being supported. To handle this, if you need to put the AppShortcut in there before the feature is available / enabled, I would do the feature flag check inside of the AppIntent's perform method instead. If the feature is disabled you can return a dialog to indicate that to the user, or run the intended behavior normally if the feature is enabled. Otherwise, I'd leave the AppShortcut out until you are ready for that feature to be live in prod and exist in future versions of your app. AppShortcuts is certainly the easiest and most straightforward way to integrate AppIntents & Siri into your app simultaneously, but for now SiriKit still seems to be supported as well. AppIntents are definitely the future, as they are the API of choice to work with Apple Intelligence. I'd definitely recommend using AppIntents if this is a new feature in your app.

I am not entirely certain of your use case, but based on what you've described it seems like a good case for making a protocol and having two conforming classes / structs, one for the app, and another that lives in the extension. When the protocol's methods are called, they are delegated to the proper one. Another way to do it is to have a protocol and create two extensions: protocol NotificationDelegate { func doNotification() } The first extension lives in a file that has target membership of your main application or framework: extension MyLoggingClass: NotificationDelegate { func doNotification(...) { // will only be called by app, can use UIApplication here } } Then put this one in your extension: extension MyLoggingClass: NotificationDelegate { func doNotification(...) { // will only be called by app extension } }

This question has been posted previously, and the "solution" is posted here: https://developer.apple.com/forums/thread/758637 Right now, for the parent app to open, you need to check the target membership box of your AppIntent file so that it lives in both the parent app and the control extension / widget bundle. Apple has not clarified the reason why this is, and I'd love to more too, but for now this is the only way that seems to work. I hope this behavior is adjusted / fixed before release. Further reading: https://developer.apple.com/forums/thread/759794

[quote='800449022, DTS Engineer, /thread/759160?answerId=800449022#800449022'] However, I want to highlight a subtly here. While an app intent can be in a framework that is dynamically linked (with Mach-O Type set to dynamic in the framework's build settings), those intents which back App Shortcuts cannot be in a framework. That is because the AppShortcutsProvider needs to be in the main app target, and the app intents declared by this provider also need to be in the same target. This is where it's useful to include the intent's source code file into your main app target and into an extension point target (and not a framework target) if you need the intent behind an App Shortcut to also be available from an extension executable. (And enhancement requests are welcome for allowing intents used by App Shortcuts to be placed in a framework.) [/quote] Thank you Ed for the much needed clarification and for your willingness to look into that FB. I would humbly ask that this rather important distinction be reflected in the docs either for AppIntentPackage, AppIntent, AppShortcuts or all of the above. I understand that there's some wizardry that goes on allowing AppShortcutsProvider to work, but given the express support for AppIntentsPackage and AppIntents in frameworks, this seems like a rather large omission. I have filed an enhancement request for this support FB14857658. SiriTipView in SwiftUI and UIKit both require a reference to the singular AppIntent that is already tied to the AppShortcutsProvider. Given the above, it means that the SiriTipView also has to live in the app target or app extension target. This means that any application that hosts its UI-code in a framework cannot support this use case (which is a lot of applications). So I think there's a good case here for usefulness in supporting framework-based AppIntents in Shortcuts.

I went ahead and made a feedback for this as well -- FB14857535. Hoping this can be addressed before RC.

Yes. The compiler is complaining because you haven't specified a title. struct SearchIntent: ShowInAppSearchResultsIntent { static let title: LocalizedStringResource = "Search App" static let searchScopes: [StringSearchScope] = [.general] static var openAppWhenRun: Bool = true @Parameter(title: "Search Text") var criteria: StringSearchCriteria @MainActor func perform() async throws -> some IntentResult { return .result() } } The above should compile for you. To find out how to conform to a protocol, ⌘ + click on the protocol (ShowInAppSearchResultsIntent) to see what is required in the docs.

Regarding static vs dynamic, are you simply referring to the Mach-O Type setting or are you referring to something else? I have the framework target set to Dynamic and compilation still fails. It should be set that way in the sample projected provided in FB14507102. Let me know if there's something else I'm missing here, but this seems like a bug.

This is still an issue as of Xcode 16.1 Beta 1.

This is still an issue as of Xcode 16.1 Beta.

I have filed an enhancement request per OP's forum post: FB14587703. We would love to see this supported by Controls.