When displaying an NSAlert in the AutoFill Credential Provider extension context on macOS 11 Big Sur, the App Icon is not properly displayed. Instead, a Ghostbusters-esque cross-out graphic is displayed over the icon. This is currently present in Xcode 12 beta 6 on macOS Big Sur beta 6. Does anybody know how to fix this? I've filed a bug report: FB8689228. To reproduce: add an AutoFill Credential Provider extension to your Mac App project. On viewDidAppear, attempt to display an NSAlert.

Hi there, We have been unable to update Big Sur on our DTK unit, hasn't completed Software Update successfully since we got it. We have run the latest Beta Access Utility (again) from the Universal program download page, - https://developer.apple.com/download/universal/ and it's currently trying to install Big Sur 11.0.1 RC 2, but it appears to be frozen at the same place (the progress bar is at ~20%) it froze every other time we attempted to run an update available in Software Update. Doesn't matter if we let it run overnight, it never completes. What to do? How to test the latest Big Sur RC 2 on the DTK? At this point I think my only option is to force reboot, give up, and test on whatever version of Big Sur shipped on this guy (build number seems to correspond with Beta 3). Thanks for any help!

Hello, We first noticed this on iOS 15 beta 4, and it is also happening on beta 5: after presenting a Touch ID prompt in our iOS app (and a fresh demonstration UIKit app) on an iPhone or iPad device with Touch ID enabled and running iOS 15 beta, about two minutes later we receive an additional UIApplicationWillResignNotification while the application is still active. It then happens again, another ~2 minutes later. As a result, any application that uses this notification to prepare for state restoration or to conceal or lock the UI will interrupt the user to prepare for resigning active, while the application is still active, two minutes after prompting the user for Touch ID authentication. I have filed a report in Feedback Assistant (FB9457094), but I thought I would post here as well in case anybody else is seeing the same behavior and has a work-around. Feedback Assistant tells me there are currently no other similar reports. Sample project to show the bug: https://github.com/billymeltdown/resign-active-test/ The SceneDelegate logs a message when the application resigns active. When the Touch ID prompt is presented, the app resigns active as expected, that's not a bug. Then wait two minutes -- it will happen again! (And then again, two minutes after that.) (Not demonstrable on Simulator -- so far I've only seen the bug after prompting for Touch ID which requires running on a Touch ID enabled device.)

Hello, Our application's Password AutoFill extension can no longer present its view when enabled in System Preferences panel for Extensions, or when selected in Safari's autofill menu, though it still appears there. Instead, an error from a private API is logged: +[NSExtensionContext _allowedItemPayloadClasses] not implemented. Setting the allowed payload classes to <private> If there's been any updates to the documentation about what our autofill extension is required to provide in terms of a list of allowed classes, I haven't found it yet. Does anybody know what's going on there, or have any suggestions? Thanks!

Hello, Our macOS app includes a Password AutoFill extension and both the host app and extension have the entitlement for AutoFill Credential Provider. We have found that in Xcode 13 RC, when we attempt to archive our app using xcodebuild we receive this error: Cannot create Developer ID provisioning profile for "our.app.ID" The AutoFill Credential Provider capability is not available for Developer ID provisioning profiles. Disable this feature and try again. And a similar message for our extension's app id. We believe this to be a bug as building/archiving/submitting using Xcode 12 worked fine with this same entitlement. Otherwise, are non-Mac App Store apps now being excluded from including Password AutoFill capability? We've been shipping this feature to our customers in our Developer ID signed app since it first became available in macOS Big Sur. We'd appreciate it if someone could look into this right away, we have filed a feedback report: FB9634952.

Hello, Recently our customers have reported experiencing an infinite loop in the App Store app on macOS when they follow a link to our Mac app's page in the store. We can confirm this behavior: Safari redirects the user to the App Store app which then repeatedly animates the page into view until an alert appears stating "Cannot Connect to App Store" and then the App Store app beachballs and has to be force quit. I have filed a report in Feedback Assistant (FB9703736) which demonstrates the behavior with a screen capture video. I wonder if this is affecting other Mac App Store apps as well, or is it something specific to our app or account? I have searched the forum and haven't found any recent posts that appear related. Cheers, Billy Update: Additional Info This appears to happen when using the "universal" link to our app in the store, which we prefer for our international customers. When we use the link that only goes to the US store, the problem does not occur.

Similar to what appears to have happened last year, the Sandbox verifyReceipt endpoint is returning the 21007 status code that should only be returned by the production URL and indicates that the receipt in question should instead be sent ... to the sandbox URL. Here's the documentation: Verify your receipt first with the production URL; proceed to verify with the sandbox URL if you receive a 21007 status code. Following this approach ensures that you do not have to switch between URLs while your application is tested, reviewed by App Review, or live in the App Store. We are sending a valid sandbox receipt (validated locally on device already), along with the shared secret / password parameter, and not getting any receipt info back, just this bogus status that should only be returned by the production URL. We could mitigate this by returning something like a failure status to our own client's request, but how are we supposed to test our code for parsing the response object when a receipt is valid? What's going on?