I have an NSWindow that isn't entirely opaque. When presenting a sheet AppKit overlays the window with NSSheetEffectDimmingView. The problem is the entire window frame is used so NSSheetEffectDimmingView overlays the transparent areas of the window and it looks bad. Is there a clean way to inset NSSheetEffectDimmingView or even perhaps disable this behavior completely so I can draw my own? I'm looking for a clean solution (other than modifying the view hierarchy of NSNextStepFrame) or swizzles which I might have to resort to if there is no other way.

I have some buttons. I set the bezelStyle to NSBezelStyleGlass. I'm sometimes experiencing the following issue: Put the system in dark mode. Some glass buttons still draw with the light appearance. One or more of the following actions usually makes the appearance redraw proper: -Clicking the button -Deactivating and then reactivating the window. -Close and then reopen the window. I tried setNeedsDisplay YES etc. but that didn't work The delay is quite noticeable. Everything else is in dark mode except one or two glass buttons. This seems to workaround the issue: BOOL didToggleGlass = NO; if (self.bezelStyle == NSBezelStyleGlass) { // Turn glass off just for a sec. self.bezelStyle = NSBezelStyleToolbar; didToggleGlass = YES; } if (didToggleGlass) { // Put glass back on. self.bezelStyle = NSBezelStyleGlass; } Apparently toggling glass cause the effective appearance to change so you can't use the above workaround in a -viewDidChangeEffectiveAppearance b/c you'll create an infinite loop unless you guard against it.

I have an NSBrowser inside a window. When I start resizing a column I noticed a peculiar behavior: it causes NSWindowWillStartLiveResizeNotification to get posted for the NSWindow the browser is inside (and did end gets posted when column resizing finishes). The browser is not the NSWindow contentView but a descendant of the contentView. I have my reasons for caring (I'm currently listening for these window resize notifications) but my code naively assumes that NSWindowWillStartLiveResizeNotification - NSWindowDidEndLiveResizeNotification indicates a window resizing session, not a column resizing session for the NSBrowser. This is in contrast to NSOutlineView. When resizing columns in NSOutlineView the window resize notifications do not get posted. NSBrowser deliberately kicks it off: -[NSWindow _startLiveResize]; -[NSBrowser _resizeColumn:withEvent:] () So this seems quite intentional but is it necessary in modern macOS? Should I file a bug? I already did FB20298148

I try saving the value of NSURLVolumeURLKey when creating a bookmark. When resolving the bookmark later I pass the bookmark data to +resourceValuesForKeys:fromBookmarkData: but always pull out "file:///" which is wrong. In contrast the value for NSURLVolumeURLForRemountingKey is properly saved and restored using the same method.

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?