Xcode: Version 12.0 (12A7209), Swift 5.3, Big Sur I was running thru test items for an app in submission and notice now - since last build on jan'31, that a snapshot func takeSnapshot(with snapshotConfiguration: WKSnapshotConfiguration?, completionHandler: @escaping (NSImage?, Error?) - Void) is inverted when the view contains a pdf image - loaded via request, now yields an inverted image; both axis are flipped. So looking about I see there's something I hadn't noticed years ago when I wrote this func createPDF(configuration: WKPDFConfiguration = .init(), completionHandler: @escaping (ResultData, Error) - Void) Is this needed now or what's going on?

In my latest app submission, and having installed to verify, my app no longer received actions from Share menu of Safari or Finder. Not seeing so far in release notes or unsure what's different?

I have an app I'm returning to after a several years I'd like to freshen up, but am daunted by the changes since; 2018 WWDC - session 415: behind the scenes of Xcode Build process, points out the many changes just that year.It's Objective-C only, features several sub-projects both private and GitHub, whose .xcodeproj file I'd had dragged in as the then practice, which my main project has as dependencys; all was good.But have few but widespread problems:* IB plugins* framework headers not getting found* sub-builds failing - deprecated or now not viable code* what to do re: BWToolkit which appears stagnant?The 2nd is odd as they build ok invividually.So my question is to whether to continue the sub-project route, or try migration to modernize like envelop them as swift packages. This is not all viable as some have assets, but otherwise, what to do? I think the missing header issue is due to naming:i.e. `import "foo.h"` should now be `import <MyFramework/foo.h>`.But I suspect some moving about is needed intra sub-project - as to path namings, so I was focusing on them first, then tackle the main app.Some of my subs had already adopted swift packages so I'm leaning that way.But some not; notably - core-plot and CocoaAsyncSocket I think these two might stay as subs if I can get their header inclusions to work and address my deprecations. And yes I'm aware of the assets restrictions for packagesAnyway, seeking some guidance thanks.

I have a restored window issue; I supposed an operation order. When a window is normally created, its view controller will add a button to a tableView's cornerView - syntheized as per docs https://developer.apple.com/documentation/appkit/nstableview/1535831-cornerview to have the proper shading etc:// Pin the corner view button to the header and scroll bar views guard let cornerView = playitemTableView.cornerView else { return } cornerView.addSubview(cornerButton) cornerButton.center(cornerView)and normally the cornerView will be there and my button is added. All is good.But when the window is restored on a later run, the guard's is taken and no cornerView then no button?So the above is wrong but why? It seems for a restored window this property is not yet synthesize?

So, picking up someone's old code, it's hitting this in a function's argument using Xcode 11: (id)node if ([node isKindOfClass:[NSArray class]])It appears their intent is to then probe by class. While I can unravel this into a series of overloaded functions, is this really the best way? Is there a way to disable this warning?

If I create, via interface builder, a window with a WKWebView, all is nice. I wire it up, constraints and added drop-n-drop support for asset viewing. But upon loading say a movie for example, the window appears to obtain a scroll view. This is easily triggered when resizing the window and make the window smaller - the video will be resized once vertical size is changed, but the addition of a horizontal scrollbar cannot be removed, unless a resize is large enough for the video to fit.I'd like to hide the scroll views' sliders when the mouse leaves the window, but I first need a way to access the scrollView.I have tried to query the WKWebView's enclosingScrollView - but always nil, and on MacOSX, there is no scrollView as on iOS.Any help appreciated, thanks.

When a magnification is altered from default 1.0 (100%) I'm trying to maintain my orignal layout - set in IB like so: func fit(_ childView: NSView, parentView: NSView) { childView.translatesAutoresizingMaskIntoConstraints = false childView.topAnchor.constraint(equalTo: parentView.topAnchor).isActive = true childView.leadingAnchor.constraint(equalTo: parentView.leadingAnchor).isActive = true childView.trailingAnchor.constraint(equalTo: parentView.trailingAnchor).isActive = true childView.bottomAnchor.constraint(equalTo: parentView.bottomAnchor).isActive = true }where the childView is the webView and its parent container view - fit() called from viewDidLoad(). The result is the view is pegged to top left, nice but I'like the window content to match the now smaller or larger webView - using scroll bars if needbe. Any user attempt to resize window, being to skew the layout until they resume default.Can someone suggestt how to go about supporting magnification ?