I met with the UIKit team last week and discussed this briefly. They explained some of the challenges that led to this decision, and that they didn’t make it lightly. I might’ve been more receptive to this change had the messaging been better. For instance, if it were explicitly mentioned in a WWDC session or, ideally, at last year’s WWDC—a year before the removal of support. They thought it was mentioned in the release notes this year, but I haven’t found it. What did they say? I'd love to know why unarchiving a nib became too much of a burden all of a sudden, to the point where they couldn't even give proper notice before removal. I don't have a Catalyst app that loads the menu bar from a nib but so many changes in recent years pulls us back instead of pushing us forward. Remember when you could just set restoration identifiers on view controllers and UIKit would restore your entire view controller hierarchy? Now why didn't they apply that same approach to scene based apps? I mean I did it but they're supposed to be the geniuses why are they making every developer repeat that code? Now they want us to type nibs by hand. What are they going to take away next?

How is the alert presented in the second UIWindow? Is it the root view controller, or is presented on the root view controller? Not sure if this works but did you try implementing the AppDelegate method: (UIInterfaceOrientationMask)application:(UIApplication *)application supportedInterfaceOrientationsForWindow:(nullable UIWindow *)window API_AVAILABLE(ios(6.0)) API_UNAVAILABLE(tvos); I heard UIApplicationDelegate is on the chopping block so even if it does work who knows how long it'll work for (IMO AppDelegate still has useful APIs that scene delegates don't cover and certain things are really quirky to do in a scene delegate) . I use a separate UIWindow to display some critical alerts too because injecting alerts in the UIViewController hierarchy can lead to some nasty bugs, especially if you run a network operation and get an error, the user might have hit a button and presented or pushed another view controller on screen in the in between but you really want to display that error. Separate UIWindow avoids a lot of potential problems about presenting on detached view controllers, interfering with the state of view controllers the error alert know nothing about, etc. ..But I let my alerts rotate. Consider whether you really need to do this. Usually you should allow rotation in both windows but if you really can't you can try implementing the method above but note on iPad with resizable windows the concept of orientation doesn't make sense if you're not full screen. If you're feeling really hacky I guess you could respond to the rotation in the alert window and just move everything where you want it to make it look like it's not rotating but I don't think I'd do that.

Interface Builder has fallen out of favor at Apple which really is a shame. Are they throwing an exception or just logging a warning? If they are throwing an exception IMO that’s really unacceptable to kill something so core to an app’s functionality without giving a depreciation notice and at least a year (ideally two) years to migrate. So nice to have to spend a month rewriting my app after WWDC each year. Re-creating a complex menu hierarchy in code is exactly what I wanted to do. Ugh. yea it’s getting old. Rewrite this. Rewrite that. get nothing in return. Swiftui swiftui swiftui. I think they are more likely to drive veteran developers to a third party frameworks than invest in their new “goodness”

I also have a Mac App Store app that uses the 'Mac style' group I'm going to update. I'm looking for advice on how I should proceed. Xcode nudged me to toggle "Register app groups" and now I have the old identifier listed in "app groups" for all target and it is in red text. So if I hit the + and make a new identifier with the group. prefix, am I supposed to duplicate the old preferences to new container? NSUserDefaults *oldGroupPrefs = [[NSUserDefaults alloc]initWithSuiteName:@"oldcontainerid"]; NSUserDefaults *newGroupPrefs = [[NSUserDefaults alloc]initWithSuiteName:@"newcontainerid"]; // save the values from oldGroupPrefs to new? Documentation states: Format the identifier as follows: group. Apple ensures that the group name you choose is unique when you register the app group on the Apple Developer website. For more information, see Register an app group. In macOS, you can also create app groups or add apps to existing app groups using this identifier format: . You don’t need to register app groups that use this format on the Apple Developer website. So I'm confused. Docs state using the old format is okay.. In the App Groups working towards harmony post: Without that, you can’t submit an app that claims both styles of app group ID to the Mac App Store. [...] It is possible to work around this limitation, but it requires ‘heroic’ measures. The trick is to split your code into a main app and a helper, with the main app only claiming the iOS-style app group ID and the helper only claiming the macOS-style one. Your main app can then call on the helper to do the necessary work, for example, to access the app group container for the macOS-style app group ID. I don't want to do this. I don't have a Catalyst app and I only need one group to write shared preferences in. So I don't really need to do this....unless it is going to be enforced policy. Migrating data from a container is annoying enough but having to migrate from a helper tool seems kind of insane.

So I just read this. >Even outside of the Mac App Store, the presence of the macOS-style app group ID causes problems. It is possible to work around this limitation, but it requires ‘heroic’ measures. The trick is to split your code into a main app and a helper, with the main app only claiming the iOS-style app group ID and the helper only claiming the macOS-style one. Your main app can then call on the helper to do the necessary work, for example, to access the app group container for the macOS-style app group ID. This helper can be an XPC service or an embedded helper tool. Overall, this isn’t a lot of fun [1], and if you’re in this situation you might want to wait for a fix to FB16664827. [1] Unless, like me, you revel in implementing wacky workarounds (-: I have an outside the MAS app that claims both style containers. I only added the group. prefix because I just updated to Xcode 16.3 and it nagged me to. What kind of issues can I run into here? I'm not actually writing to the new "group." container prefix yet but I did claim it.. I'm about to push the outside the Mac App Store app out..(already notarized...seems to be working fine) should I not go forward with it and take away the "group." from all targets?

FB17671405

Appears to have been some sort of code signing issue. No useful errors from Xcode. The action extension would show up in the list and just wouldn't work when you tried to use it. So I tried toggling various code signing settings ...from automatic to manual etc and back again. For whatever reason when I set code signing back to automatic Xcode didn't complain but the extension didn't work. Would be great if the code signing issues were caught at compile time and displayed instead of letting me sign and notarize a nonworking extension. I ended up just deleting the entire Action Extension target and making a new one, adding all the same compile sources and it works. Butt... NSTextView shows action extensions via the rollover button but the menu items are disabled (FB17449863)! Seems action extension with NSExtensionActivationSupportsText set to yes only work in Safari.... any workarounds to that?

In this app I have shared preferences for the main app, an Action Extension, a Helper app, and an XPC service. I do have another app that has an XPC service that writes files inside the group container. When the XPC service is done the main app accesses the files. From App Groups: macOS vs iOS: Working Towards Harmony. On 21 Feb 2025 we rolled out a change to the Developer website that completes the support for iOS-style app group IDs on the Mac. Specifically, it’s now possible to create a Mac provisioning profile that authorises the use of an iOS-style app group ID. I'm sure there is a reason but I wonder why existing group container ids can't be registered and why making a new group with a "group." prefix is required.

I ended up refactoring my code so I can handle the possibility of performing the intent action before the main window controller is loaded even if it isn't possible (I wouldn't want to instantiate it in the intent handler action because I don't want to interfere with certain logic in app launch). Probably should have designed it this way from the beginning anyway, the action doesn't need to be tied to the window controller. Still would like to know about app lifecycle here out of curiosity

Years later and NSProgressIndicator usesThreadedAnimation defaults to YES and it doesn't seem work properly when used this way (I have it in a sheet). Had to set usesThreadedAnimation to NO to actually have it redraw when updating its properties. Kind of annoying that there is no way to set usesThreadedAnimation in Interface Builder

So clearly Shortcuts app wasn't responding to my app being built with changes made to the .intentdefinition file. I tried taking the built app out of Derived data and moving it. Still no juice. Finally was able to get it to work by moving the built app out of Derived Data to my Applications folder and restarting my Mac.

So I got one to show up..not sure how. I temporarily added a parameter (but my shortcut shouldn't take any parameters). I also tried adding it via: [[INVoiceShortcutCenter sharedCenter] setShortcutSuggestions:@[shortCut1]]; So I'm not sure if adding the parameter or using -setShortcutSuggestions: did it. Now I removed the parameter in the .intentdefinition. AND I cleared INVoiceShortcutCenter like so: [[INVoiceShortcutCenter sharedCenter] setShortcutSuggestions:@[]]; // empty array And rebuilt the app. And now I'm having the problem in reverse (it remains in Shortcuts app list and I can't get it to be removed). Also added a second shortcut (I need two)...and the first one stubbornly won't go away and the second one won't show up....

Meh. Somehow I must've done something (or there is some Xcode bug) but I got Xcode to generate another .entitlement file for the extension without realizing it.....it was called something like: MyEntitlement.release.entitlements....and it was set to Release mode. The group container ID was only getting added to the release mode entitlement file, not the .entitlement file being used in debug mode. Fixed that.

Nearly ten years later I'm having the same problem. Forgot I even made this post (found it by searching). Main app writes the preference but the extension isn't getting the updated value. FWIW main app is not sandboxed but the Finder extension is (because it has to be). But I'm pretty sure I've gotten this to work before...not sure what's goin on

I filed FB17554847