“xcode github”

Perhaps ending with that question was a mistake; obviously, I should use a new control. But I have used the zoom/no zoom feature since the birth of MacCat in 2019, ... There are two UISceneWindowDelegate methods didUpdateCoordinateSpace and didUpdateEffectiveGeometry, and by inspection it's possible to infer which of the two states the App should configure itself. The problem is that these methods are both “did” variants, there are no “will” methods. My App should never be in fullscreen. (Note Xcode 26.4.1 is aware of willUpdateEffectiveGeometry, but it was never called - maybe in the future.) The new zoom button control worked fine, by setting the scene’s size restriction minimumSize and maximumSize attributes appropriately. Positioning the new zoom control precisely over the green button didn’t work, the green guy intercepted events. Hovering over the green button posts a dialog showing all 15 possible action variations, none useful to me. But, of course, I had long ago missed windowScene.sizeRestr

Not using Mac Catalyst. Just the iOS app that will run on Apple Silicon Macs. How do I tell Xcode to make sure the key is injected properly during the build process

Thanks, let’s focus on your Designed for iPad issue and error in that target. You said you can’t add any Mac however are you using Mac Catalyst? Xcode attempts to dynamically build the final Info.plist at compile time based on your project settings. When this happens, Xcode often ignores or strips out custom keys that you manually added to the physical Info.plist file, especially when switching the run destination to the Mac. Even though the key shows up under Custom iOS Target Properties in the Xcode UI (which is expected, since Designed for iPad is technically still an iOS build), the dynamic generation process is dropping the BAAppGroupID key when compiling the Mac app bundle. Since you already have a physical Info.plist file with the correct BAAppGroupID key inside it, you can tell Xcode generating the plist, you need to make sure the key is injected properly during the build process. The issue seems a target issue as is working with the target that was designed to work

Thanks for the post. The Background Assets framework is fully supported on the Mac. It is available on macOS 16.0 and later, as well as for iOS apps and Mac Catalyst and shown in the documentation you linked. iOS 16.0+ iPadOS 16.0+ Mac Catalyst 16.0+ The error you are seeing is actually not a limitation of the Apple framework itself. The file AssetPackManager.swift and the specific BAAppGroupID key are not internal to the Background Assets framework. What is your info.plist with key BAAppGroupID? Please look at the documentation https://developer.apple.com/documentation/bundleresources/information-property-list/baappgroupid If you defined the App Group ID in your Xcode Build Settings (often as a User-Defined Build Setting that gets injected into the Info.plist), it might be restricted to iOS. Go to your app target's Build Settings. Search for the variable that populates BAAppGroupID (or search for BAAppGroupID directly if it is in the Info.plist Values section). Click the triangle next to the setting

Hi, I'm using the latest Xcode (26.4.1) and I'm targeting iOS 16.6. Also, make sure that you don't provide parametrized summary - in this case it works correctly. I'm using something like that: static var parameterSummary: some ParameterSummary { Summary(List Items) { .$collections } } The issue occurs only if you have the form view. It's easily reproducible with this configuration. I tried also with an optional array [String]? and it doesn't help. I've found a workaround which in my case is suitable. I added predefined values this way: @Parameter(title: Collections, optionsProvider: CollectionsOptionsProvider()) var collections: [String]? However, it isn't good enough if someone needs a completely custom input.

@maxik Thanks for the post, can you provide more information about the setup of your environment as this issue is not happening currently with the latest release of iOS. It is recommended to ensure that your Xcode project is correctly configured to build against the latest SDKs and that your development environment is up to date. To work around this issue, you can make the parameter optional and remove the argument. This prevents the Shortcuts editor from continuously applying the empty array state over the user's active input. However I don’t see the issue on the latest release and that’s why is so important to provide the details of the iOS version you are targeting and what Xcode are you using. Albert
  Worldwide Developer Relations.

@MiladBigle Great to know, since May 5 the RC can be used to submit apps to the store based on the notes: May 5, 2026 App Store Connect update You can now upload apps built with Xcode 26.5 >RC using the SDK for iOS 26.5 RC, https://developer.apple.com/help/app-store-connect/release-notes/ Albert
  Worldwide Developer Relations.

@DTS Engineer Thanks Albert for the link. I have successfully submitted the app for review on the App Store today using the same Xcode candidate release. Everything went through correctly on my side, and App Store Connect also appears to be updated. It may be because there were no changes in the Xcode version.

Hopefully this is not too late. I've been quite swamped these days... No, I'm still trying to resolve this problem. Thank you for investigating it. Tomorrow, I will be able to check it on a physical device. However, even if this is a workaround, it won't help in my case, because I need to have access to intents from the watch app to check a couple of things and to perform old complications migration from ClockKit to WidgetKit. Also, intents should be shared between the watchOS app and widgets extension. If you don't share it and tap on a widget you get these warnings in the console: Failed to instantiate type ConfigurationAppIntent by name (12WatchWidgets22ConfigurationAppIntentV). The type with this mangled name does not exist in the process’s memory space. [InitializeAction <>] Could not find an intent with identifier ConfigurationAppIntent, mangledTypeName: Optional(12WatchWidgets22ConfigurationAppIntentV) associateAppIntent(forUserActivity:) - Error converting INIntent to App Intent: AppIntents.Perf

That suggests that you’re hitting the issue described in Updating Mac Software, or something like it. That's weird. My apps do include a software updater (Sparkle) for the versions I sell on my website, but for the App Store versions, the updater is not included. I have separate Xcode targets for the two versions, and the App Store target (the one for which Xcode downloads the crash reports) doesn't even link to the updater. And when running the apps locally (including when the only crash on my Mac happened, which wasn't in Xcode, but just launching the debug build from Spotlight), I always run the App Store version.