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

So instead of deactivating the audio session in my pause method I just leave it active and wait this: // Listen for UIApplicationWillResignActiveNotification -(void)appWillResignActive:(NSNotification*)notification { // player node paused? if (self.amIPaused) // { // Then we must audio engine pause. [self.audioEngine pause]; // Then we must deactivate the audio session. [self runOperationToDeactivateAudioSession]; } }

So I think the playback time issue (audio being skipped) when I pause both the playerNode and the audio engine is that when resuming the playback...I call a helper method that does something like this: -(void)resume { if (!self.playerNode.isPlaying) { [self _startAudioEngineIfNotRunningAndConnectPlayerNodeToMainMixer]; } else { // Already playing. } } Which has a check like -(BOOL)_startAudioEngineIfNotRunningAndConnectPlayerNodeToMainMixer if (!self.audioEngine.isRunning) { // connect the player node to the main mixer node and start the engine.. //code here... } else { // engine already running... return YES; } If I modify the _startAudioEngineIfNotRunningAndConnectPlayerNodeToMainMixer to include this check: NSArray<AVAudioConnectionPoint *> *connections = [engine outputConnectionPointsForNode:playerNode outputBus:0]; if (connections.count > 0) { // player node already connected... only need to start the engine } else{ // connect the player node... } Playback position isn't lost on resume. So that's good. When I deactivated the audio session and got that AVAudioSessionErrorCodeIsBusy error perhaps the system paused the audio session and returned that error to tell me about my "incorrect API use." In regards to my initial issue regarding the MPRemoteCommandCenter I think what I'm going to do is this: Only pause the player node in my -pause method and keep the audio session running if my app is in the foreground. When/if my app is moved to the background if my player node is paused I'll pause the audio engine as well and deactivate the audio session for the sake of getting the 'now playing center' to update the toggle play-pause button image. Since this is async and in a background task I have to hope it runs and updates the now playing center button before the user can see it I'm still thinking about this: I don't think this is currently possible...but I'm not sure if there is ever a situation where my app can be on screen at the same time as the "Now Playing Center" in a multi-window situation. If so the play-pause toggle button will have the wrong image until my app is backgrounded. So there is that, if that's even possible but I don't think I have any other options? -- Perhaps my thinking is naive but I think this could be a lot easier if the system just read the MPNowPlayingInfoCenter.playbackState property on iOS instead of inferring it from AVAudioSession. If I don't own the now playing center who cares what I set the .playbackState property to? Feels like the system is in a better position to make a decision of whether or not my audio session should be deactivated than I am. But I have to explicitly deactivate my audio session when my app is backgrounded every time (if my audio is paused).