I have a custom object which gets passed back to the main app from XPC. I whitelist it like so: NSSet *expectedClass = [NSSet setWithObjects:[NSArray class], [MyCustomClass class], nil]; [interface setClasses:expectedClass forSelector:@selector(myMethodNameHere:withCompletion:) argumentIndex:0 ofReply:YES]; Now my custom class conforms to NSSecureCoding. It does have an array property of another custom class. @property (nonatomic,readonly) NSArray *arraypropertyOfOtherClass; Which is decoded in -initWithCoder: using: -decodeArrayOfObjectsOfClasses:forKey: Now on macOS Tahoe this is all walking fine. But I just tested on macOS Monterey and I get the following error: Exception: decodeObjectForKey: too many nested collections when explicitly decoding a single collection. How should I handle this for earlier versions of macOS?

I noticed that I cannot even tell that an NSBox is being used on macOS Tahoe when the system is in light mode. The 'box' background can't be seen so it makes it appear that the subviews in the box aren't positioned correctly (because they are inset from the subview outside the box). There is no visual indicator that that subviews inside this box are grouped together because well, you can't see the box at all. In Interface Builder the box looks fine at Design Time in "Light Mode". In Dark Mode the box looks fine at design time and at run time. Just figured I'd throw that out there.

In NSFileManager there is this method to move files to and from iCloud:- (BOOL)setUbiquitous:(BOOL)flag itemAtURL:(NSURL *)url destinationURL:(NSURL *)destinationURL error:(NSError **)errorOutAll the samples and information I'm able to find seem to be related to using NSDocument, which my app isn't using. I have a little view in my app that allows users to move an image out from the iCloud container and into a local directory. It seems that simply using NSFileManager moveItemAtURL:toURL:error: works fine both to move a file in and out of the iCloud container on OS X without wrapping everything in a file coordinator block. Is it still necessary to use a file coordinator to move files out of iCloud on the Mac. When I put a file in the iCloud container, the system automatically starts uploading it..even though I'm not using a file coordinator...and my related file presenter still is detecting a change.Both methods seem to be working the same, I'm just wondering if I should be using a coordinator because it's a good amount of code I can get rid of if it's not necessary.Thanks.

Showing a popover from a status bar item. Sometimes results in this being logged out:Error: this application, or a library it uses, has passed an invalid numeric value (NaN, or not-a-number) to CoreGraphics API and this value is being ignored.Please fix this problem.When this happens, the popover appears at 0.0,0.0 (lower left) of the screen for a second... before snapping to the proper position.Code: NSStatusBarButton *statusButton = _statusItem.button; [_popover showRelativeToRect:statusButton.bounds ofView:statusButton preferredEdge:NSMinYEdge];The user can add or remove the status item in this app...the issue I notice usually happens the second time the popover gets presented. Looks like the popover can be trying to present before the status item button's position is set?

Simple UIActivityViewController configured like this:NSArray *activityItems = @[linkURL]; //<--linkURL is an NSURL. UIActivityViewController *activityViewController = [[UIActivityViewController alloc]initWithActivityItems:activityItems applicationActivities:nil];Then I present it:[self presentViewController:activityViewController animated:YES completion:nil];If I select the Mail or Messages activity the activity works as expected. But if I select the "Reminders" or "Notes" activity the view controller for those activities present briefly before automatically dismissing and logging out:: SLRemoteComposeViewController: (this may be harmless) viewServiceDidTerminateWithError: Error Domain=_UIViewServiceInterfaceErrorDomain Code=3 "(null)" UserInfo={Message=Service Connection Interrupted}Anyone know the potential cause / workaround? The completionWithItemsHandler block does not return me an error.

After updating my app, I'm now getting crashes when the app is brought to the foreground. On initial launch all appears to be fine. But when I background/foreground the app I get this: Window container should not be nil. Unfortunately this is only happening on production release and I cannot reproduce the issue in the debug environment. I updated GoogleMobileAds to the latest version. I think the framework may be responsible. Curious to know if anyone else has experienced this and knows what could possible be the cause.

I'm currently using a StoreKit configuration file to test auto renewable subscriptions. On my device I am subscribed to subscription with a duration set to weekly. The subscription renewal rate is set to "Monthly Renewal Every 15 Minutes." This all works fine for awhile. The subscription auto renews. But after a few hours suddenly my app detects that the subscription has expired and the app UI behaves accordingly. My app does the following: Looks at the in app purchase receipts and finds the one with the latest expiration date. If the current date is later than the expiration date of this receipt my app acts like the subscription has expired. I even add a bit of extra time on the expiration date in case an auto renewable transaction gets held up (in the debug environment I add a couple hours). I don't take any interaction to cancel the subscription in the "Manage StoreKit Transactions" area of Xcode, nor do I do anything programmatically to cancel the subscription. Autorenew just stops working. I noticed this happens when the in app purchase receipt count is high (currently it is at 1776 in app purchase receipts). So I'm wondering if this is a bug in the StoreKit configuration environment that happens when auto renewing subscriptions causes the in app purchase receipts to grow large and it just quits auto renewing the subscription? If I navigate to the area in my user interface and resubscribe to the weekly plan it works again for awhile. The issue then will reoccur after a few hours again, forcing me to "resubscribe" to the plan I've never unsubscribed for. Is StoreKit testing discarding in app purchase receipts when the receipt gets large but instead of discarding the oldest receipt it removes the in app purchase receipt that is not yet expired, thus forcing me to resubscribe? Anyone else experience this issue with StoreKit testing? Seems like it's an issue with the testing environment but naturally can't be sure.

I'm getting some Crash Reports for an app of mine that's on the Mac App Store. A few details: -All the crash reports are on ARM-64 Macs. -The call stack shows my app calling NSURL's -getResourceValue:forKey: method with NSURLLocalizedNameKey, which is the last call made by my app before the crash. After that crash logs look like this: **Thread 0 Crashed: 0   libobjc.A.dylib               0x00000001a623c4b0 objc_retain + 16 1   LaunchServices                0x00000001a6954f68 -[FSNode(PathAndName) nameWithError:] + 72 2   LaunchServices                0x00000001a6a36278 +[_LSDisplayNameConstructor(ConstructForAnyFile) displayNameConstructorWithContextIfNeeded:bundle:bundleClass:node:preferredLocalizations:error:] + 2732 3   LaunchServices                0x00000001a6a357ac +[_LSDisplayNameConstructor(ConstructForAnyFile) displayNameConstructorWithContextIfNeeded:node:error:] + 44 4   LaunchServices                0x00000001a6ae5b20 LaunchServices::URLPropertyProvider::getDisplayNameConstructor(LaunchServices::Database::Context&, FSNode*, LaunchServices::URLPropertyProvider::State*, NSError* __autoreleasing*) + 88 5   LaunchServices                0x00000001a6ae1930 LaunchServices::URLPropertyProvider::prepareLocalizedNameValue(LaunchServices::Database::Context&, FSNode*, __FileCache*, __CFString const*, LaunchServices::URLPropertyProvider::State*, NSError* __autoreleasing*) + 328 6   LaunchServices                0x00000001a6953d6c LaunchServices::URLPropertyProvider::prepareValues(__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**) + 456 7   CoreServicesInternal          0x00000001a8def6f0 prepareValuesForBitmap(__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) + 452 8   CoreServicesInternal          0x00000001a8dec5ec _FSURLCopyResourcePropertyForKeyInternal(__CFURL const*, __CFString const*, void*, void*, __CFError**, unsigned char) + 236 9   CoreFoundation                0x00000001a64546b0 CFURLCopyResourcePropertyForKey + 144 10  CoreFoundation                0x00000001a646b944 -[NSURL getResourceValue:forKey:error:] + 120** -- I haven't been able to reproduce the issue on my ARM-64 Mac. Not sure what's going with _LSDisplayNameConstructor or if there is a way I can workaround/resolve. Some of the crashes have the following lines included: Kernel Triage: VM - Compressor failed a blocking pager_get VM - Compressor failed a blocking pager_get VM - Compressor failed a blocking pager_get VM - Compressor failed a blocking pager_get VM - Compressor failed a blocking pager_get

I know WKWebview is in another process from the main app. My question is is the UIBackgroundModes audio entry in Info.plist required on the main app for WKWebview to play audio/video/airplay in the background? Or is simply setting WKWebViewConfiguration allowsAirPlayForMediaPlayback and allowsPictureInPictureMediaPlayback enough? I recall having issues with background audio from WKWebView on older versions of iOS a couple years ago so I added the audio entry to the Info.plist.... but I just removed the key from the Info.plist and background audio from WKWebview seems to be working fine...maybe audio background mode is not required? Or does it only seem to be working because my app is attached to the debugger? Or is this a bug?

After upgrading to Xcode 14 I cannot submit an update to one of my apps that uses the GoogleMobileAdsSDK. I'm getting the following error when I try to submit to the App Store: Missing or invalid signature. The bundle 'com.firebase.Firebase-nanopb' at bundle path 'Payload/PATH_HERE/nanopb.framework' is not signed using an Apple submission certificate. Anyone else getting this and know of a solution?

When I open a new window via UIWindowSceneActivationAction, the window is shown like a modally presented view controller. I noticed a little layout hiccup when the window is in this state, because the window is reporting a safeAreaInset.bottom value of 20.0 even though the window is nowhere near the Home Indicator. Is there a good way to detect when a window is in this "modal like presentation" state on iPad? Size classes don't provide. I'd hate to have to sniff the frame of the window and compare it to the mainScreen frame (I know UIScreen.mainScreen is deprecated)?

I noticed an Xcode Extension I wrote a couple of years ago isn't showing up in the Editor menu of Xcode. So I opened up the project, ran the Extension and the grayed out version of Xcode shows up but my extension no longer appears in the "Editor" menu. So I just tried to create a brand new Xcode project, with an Xcode extension. Right out of the box, no code changes from the template, and I can't get the new project's Xcode extension to appear in the "Editor menu". In System Preferences the app is checked off under "Xcode Extensions" but still nowhere to be found?

Experimenting with Mac Catalyst a bit. I see sometimes the compiler warns me about an API and suggests this fix:   if (@available(macCatalyst 15.0,*)) { /// Use API for this version of catalyst.... } And when I switch back to run on an iOS device the warning comes back and this time I get the suggestion: if (@available(iOS 15.0, *)) { //iOS 15 } If I just use the @available iOS 15 check and remove the macCatalyst check the compiler stops warning me when I try building on my Mac and on iOS, but the same isn't true the other way around (if I have code inside the macCatalyst version check, switching to build for an iOS device still warns me). I was expecting that code inside the if @available(macCatalyst 15,*) statement would only run on Mac catalyst if the version of macOS supports the API, but would not run on iOS at all (even if the API is available there too) but I still get compiler warnings on iOS and a suggestion for an extra if (@available(iOS 15.0, *)) which produces the following:  if (@available(macCatalyst 15.0,*))     {         if (@available(iOS 15.0, *))         { //do something iOS 15 and later...and macCatalyst 15 and later. } } What do I make of the macCatalyst availability check? It comes up in code completion but just using the iOS check seems like the correct way (it silences compiler warnings but I haven't tested on an older version of macOS to see if using any of this API would produce a crash). I conclude that if (@available(iOS 15.0, )) should be used pretty much always instead of if (@available(macCatalyst 15.0,)) and if I need code only for Mac Catalyst I should check the TARGET_OS_MACCATALYST macro instead:  #if TARGET_OS_MACCATALYST #else //iOS only #endif Is that correct?

Working on a Mac Catalyst version of one of my apps. I noticed making changes on my iPhone (debug environment) aren't being pushed to my Mac (also in debug environment). Then when I quit and relaunch the app and manually force an iCloud sync at launch I get all the changes. At app launch I see the following method is being called on my AppDelegate after I attempt to register remote notifications: -application:didFailToRegisterForRemoteNotificationsWithError: with the error: Notifications are not allowed for this application" UserInfo={NSLocalizedDescription=Notifications are not allowed for this application}. Anyone experience this and have a solution? Under "Signing and Capabilities" I see an entry for Push Notifications for iOS and macOS.

I was wondering if it was possible to use a Settings.bundle just for the Mac Catalyst version of the app? On the iOS version I handle my preferences in app as it is easier to sync with iCloud key value storage, plus doing it in-app has the added convenience of not making the user navigate to the Settings app to manage preferences. On Mac Catalyst however using a Settings.bundle would be nice because I'd get UI for free and the user doesn't have to navigate to a different app to manage preferences. Also I have a few preferences that only apply to the iOS version of the app, and some that only apply to the Mac version of the app (preferences that don't apply to the platform the app is running on should be excluded from the UI). So is there a way to specify a Settings.bundle just for Mac Catalyst? If not, is there a way to specify that a particular preference is "Mac Only" in the plist files inside the Settings bundle?