I’m seeing a regression in macOS 27 beta when using SwiftUI LocalAuthenticationView. When an LAContext is attached to LocalAuthenticationView, subsequent policy evaluation fails immediately with: Error Domain=com.apple.LocalAuthentication Code=-1007 NSDebugDescription="Caller is not Apple signed." NSLocalizedDescription="Authentication denied." The same policies work when evaluated on a plain LAContext that has not been attached to LocalAuthenticationView. Minimal shape of the failing path: @State private var context = LAContext() LocalAuthenticationView(context: context) { EmptyView() } context.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: "Unlock") { success, error in print(success, error as Any) } This affects Touch ID unlock in our macOS app. We currently work around it by detecting LAErrorDomain / -1007, removing LocalAuthenticationView, and asking the user to manually start Touch ID with a fresh LAContext. Filed as Feedback: FB23262713 Could someone from the beta / LocalAuthentication team confirm whether this is an intended restriction for LocalAuthenticationView, or a macOS 27 beta regression?

I am building a Vision OS app that includes a File Provider and File Provider UI extension. Both work great in simulator. When uploading to TestFlight, this message is shown: Unsupported Platform. The extension bundle [...]/PlugIns/File ProviderUI.appex is not supported for this platform. If I exclude the File Provider UI extension from the build, it is accepted. If I even include a hello-world File Provider UI extension, the error shown above is returned by ASC. There is contradicting documentation on this subject: https://developer.apple.com/documentation/technologyoverviews/app-extensions states that File Provider UI extension is not supported on Vision OS, so that explains ASC behavior https://developer.apple.com/documentation/FileProviderUI (and all other framework docs) states that File Provider UI extension is supported on Vision OS, so that explains why it works on simulator. Now, which of these two is correct? My best guess at this point is that ASC's logic follows the first document linked above, while the OS and framework actually follow the second. The same discrepancy seems to hold for macOS, but I'm currently focusing on Vision OS. Ideas? Anybody using a File Provider UI extension on Vision OS?

Here is a simple view to demonstrate the issue struct ContentView: View { @State private var isPresented = false var body: some View { VStack { Button("Test") { isPresented = true } } .alert("Test", isPresented: $isPresented, actions: { Button("Delete All", role: .destructive) {} }, message: { Text("Are You Sure?") }) .padding() } }``` Which results in ![example alert]("https://developer.apple.com/forums/content/attachment/c6210120-d82e-4df5-a01a-fc5cb168e1bf" "title=Screenshot 2025-09-08 at 08.57.21.png;width=546;height=442") The destructive button is almost unreadable. WCAG score is 1.4, far below the minimum recommended 4.5. I found [this post](https://stackoverflow.com/q/66448869) on SO going back to Big Sur, but not on this forum. Any known workarounds (except for building my own dialogs, which I am trying to avoid)? Using confirmationDialog instead of alert does not make a difference.