We've implemented AutoFill Credential Provider within our macOS App now that it's available in Big Sur as mentioned in AutoFill Everywhere - https://developer.apple.com/videos/play/wwdc2020/10115/ from WWDC20. We've followed the instructions in the documentation for ASCredentialProviderViewController - https://developer.apple.com/documentation/authenticationservices/ascredentialproviderviewcontroller?language=objc which mentions adding the AutoFill Credential Provider Entitlement - https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_authentication-services_autofill-credential-provider?language=objc to both the extension and the containing app as the first step. Add the AutoFill Credential Provider Entitlement to both the extension and its containing app. Once we attempt to validate our App for the Mac App Store, we receive a validation error: Invalid Code Signing Entitlements. Your application's bundle signature contains code signing entitlements which are not supported on macOS. Specifically, key 'com.apple.developer.authentication-services.autofill-credential-provider' in [App] is not supported. One thing which may be related is that the documentation for ASCredentialProviderViewController references availability for macOS 11.0+, but the AutoFill Credential Provider entitlement doesn't reference any such availability. With Big Sur being released, how do we submit/release our App with AutoFill Credential Provider support?

When embedding a framework in an iOS application I noticed some differing behavior when running on an actual device and simulator which I couldn't find an explanation for anywhere in the documentation. The embedded frameworks are loaded from outside (adjacent) to the app package when running on simulator whereas they are loaded from within the app package, within the Frameworks directory when running on an actual device. Here's a link to an example project which logs the path at which the dylib within the framework is loaded: https://github.com/R4N/simulatorLoadFrameworkExample The sample outputs are as follows: On simulator: /Users/username/Library/Developer/Xcode/DerivedData/simulatorLoadFrameworkExample-gmxyfcrvpmdfgqepjbbysebvysmh/Build/Products/Debug-iphonesimulator/libsimple.dylib On device: /private/var/containers/Bundle/Application/9D22C144-848A-4E40-B5B3-707B1CFD3151/simulatorLoadFrameworkExample.app/Frameworks/libsimple.dylib Is this the correct/expected behavior and if so is there any documentation which references this? These are the documentation pages which I've reviewed so far trying to find an answer/explanation: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/CreationGuidelines.html https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW1 https://developer.apple.com/library/archive/technotes/tn2435/_index.html

We have an (non-scene) application which uses a splitViewController on iPad. We use a blocker view to obscure sensitive information when the application resigns active (i.e. double tap the home button/swipe up on devices with no home button). This works great in general, but now we're moving on to supporting iPad Multitasking and there seems to be a "blocker view" created by the system when transitioning from collapsed -> expanded (showing a blur of sorts with the application icon in the center). Because appWillResignActive is also called when transitioning, we end up with a mishmash of both our own blocker view and the system's blocker view which doesn't look too great. These are the splitViewController collapse/separate methods I'm referring to below: https://developer.apple.com/documentation/uikit/uisplitviewcontrollerdelegate/1623184-splitviewcontroller?language=objc https://developer.apple.com/documentation/uikit/uisplitviewcontrollerdelegate/1623189-splitviewcontroller?language=objc My question is: Is there someway to suppress the system's blocker view when transitioning to different iPad multitasking collapsed/expanded sizes? If the answer to that is no, then is there some way to detect that the application is resigning active because of the transition? What I've discovered so far: applicationWillResignActive is called prior to the splitViewController's collapse/separate methods The splitViewController's collapse/separate methods are called after the system's blocker view is displayed so it doesn't help to remove our own app's blocker view in those methods willTransitionToTraitCollection is also called after the system shows it's blocker view so it's too late to remove our own blocker view there as well What I've tried: Move obscuring our sensitive data using the blocker view to applicationDidEnterBackground: << This is not ideal as it doesn't obscure the sensitive data when the user double taps the home button or swipes up which is the scenario we're trying to use the blocker view to obscure Change the blocker view to a VisualEffectView with blur << Again not ideal as it doesn't look great when obscuring the view and we're not transitioning Thank you.

Goal Use NSPasteboard's canReadObjectForClasses:options: within a custom toolbar item's - (void)validate to determine the toolbar's enabled state. Issue When using NSPasteboard pasteboardWithName and then calling canReadObjectForClasses:options: within the toolbar item's - (void)validate method it causes the Leak Profiler to detect leaks. Stack Trace of detected leak 0 libsystem_malloc.dylib _malloc_zone_calloc 1 Foundation -[NSConcreteMapTable initWithKeyOptions:valueOptions:capacity:] 2 AppKit -[_NSPasteboardTypeCache init] 3 AppKit -[NSPasteboard _updateTypeCacheIfNeeded] 4 AppKit -[NSPasteboard _cachedTypeNameUnion] 5 AppKit -[NSPasteboard(NSTypeConversion) _conformingTypes] 6 AppKit -[NSPasteboard canReadObjectForClasses:options:] 7 testingPasteboardLeak -[TestToolbarItem validate] ~/Documents/Code/tests/testingPasteboardLeak/testingPasteboardLeak/TestToolbarItem.m:14 8 AppKit -[NSToolbarItemViewer configureForLayoutInDisplayMode:andSizeMode:inToolbarView:] 9 AppKit -[NSToolbarView _layoutDirtyItemViewersAndTileToolbar] 10 AppKit -[NSToolbarView _syncItemSetAndUpdateItemViewersWithSEL:setNeedsModeConfiguration:sizeToFit:setNeedsDisplay:updateKeyLoop:] 11 AppKit -[NSToolbarView _noteToolbarLayoutChanged] 12 AppKit -[NSView _setWindow:] 13 AppKit -[NSView addSubview:] 14 AppKit -[NSThemeFrame addTitlebarSubview:] 15 AppKit -[NSThemeFrame _showHideToolbar:resizeWindow:animate:] 16 AppKit -[NSWindow _showToolbar:animate:] 17 AppKit -[NSToolbar _show:animate:] 18 CoreFoundation -[NSSet makeObjectsPerformSelector:] 19 AppKit -[NSIBObjectData nibInstantiateWithOwner:options:topLevelObjects:] 20 AppKit -[NSNib _instantiateNibWithExternalNameTable:options:] 21 AppKit -[NSNib _instantiateWithOwner:options:topLevelObjects:] 22 AppKit -[NSStoryboard _instantiateControllerWithIdentifier:creator:storyboardSegueTemplate:sender:] 23 AppKit NSApplicationMain 24 libdyld.dylib start Example Code Custom Toolbar item's validate method: - (void)validate { NSPasteboard *myPasteboard = [NSPasteboard pasteboardWithName:@"TestPasteboardName"]; BOOL isValid = [myPasteboard canReadObjectForClasses:@[[NSString class], [NSURL class]] options:nil]; } WindowController which is a delegate to the toolbar: - (NSArray *)toolbarDefaultItemIdentifiers:(NSToolbar *)aToolbar { return @[@"test"]; } - (NSArray *)toolbarAllowedItemIdentifiers:(NSToolbar *)aToolbar { return @[@"test"]; } - (nullable NSToolbarItem *)toolbar:(NSToolbar *)toolbar itemForItemIdentifier:(NSToolbarItemIdentifier)itemIdentifier willBeInsertedIntoToolbar:(BOOL)flag { TestToolbarItem *item = [[TestToolbarItem alloc] initWithItemIdentifier:itemIdentifier]; [item setTitle:@"TestToolbar"]; return item; } What I've tried so far Use NSPasteboard releaseGlobally when closing the window -- leak still present. Wrap the pasteboard check in @autoreleasepool -- leak still present. Using releaseGlobally directly after the pasteboard check gets rid of the leak, but obviously also clears out the pasteboard. So is there a way to use a private pasteboard's canReadObjectForClasses:options: within a custom toolbar item's validate method without causing a leak?