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?