İOS 26 beta battery %1

I'm looking to implement USB monitoring for FIDO2 authentication through a custom Authorization Plugin, specifically for the below ones. This plugin applies to the following macOS authorization mechanisms: system.login.console — login window authentication system.login.screensaver — screensaver unlock authentication The goal is to build a GUI AuthPlugin, an authorization plugin that presents a custom window prompting the user to Insert your FIDO key”. Additionally, the plugin should detect when the FIDO2 device is removed and respond accordingly. Additional Info: We have already developed a custom authorization plugin which is a primary authentication using OTP at login and Lock Screen. We are now extending to include FIDO2 support as a primary. Our custom authorization plugin is designed to replace the default loginwindow:login mechanism with a custom implementation. Question: Is there a reliable approach to achieve the USB monitoring functionality through a custom authorization plugin? Any guidance

Hi, I am developing a iOS app with Packet Tunnel Provider Network Extension. I manage signing manually. I created a distribution provisioning profile. Then when I archive and click validate I get this error: Your application bundle's signature contains code signing entitlements that are not supported on iOS. Specifically, value 'url-filter-provider' for key 'com.apple.developer.networking.networkextension' So I run security cms -D -i profiles/vpn_distribution.mobileprovision and I see there Entitlements com.apple.developer.networking.networkextension app-proxy-provider content-filter-provider packet-tunnel-provider dns-proxy dns-settings relay url-filter-provider hotspot-provider Where are those coming from. My entitlement file has com.apple.developer.networking.networkextension packet-tunnel-provider com.apple.security.application-groups group.my-app-group What is happening here. How can I get a provisioning profile that only has the entitlements that I actually need?

HI, I am currently developing an app that utilizes Wi-Fi Aware. According to the Wi-Fi Aware framework examples and the WWDC25 session on Wi-Fi Aware, discovery is handled using DevicePairingView and DevicePicker from the DeviceDiscoveryUI module. However, these SwiftUI views present their connection UI modally when tapped. My app's design requires the ability to control the presentation of this UI programmatically, rather than relying on a user tap. While inspecting the DeviceDiscoveryUI module, I found DDDevicePairingViewController and DDDevicePickerViewController, which appear to be the UIViewController counterparts to the SwiftUI views. The initializer for DDDevicePairingViewController accepts a ListenerProvider, so it seems I can pass the same ListenerProvider instance that is used with the DevicePairingView. However, the initializer for DDDevicePickerViewController requires an NWBrowser.Descriptor, which seems incompatible with the parameters used for the SwiftUI DevicePicker. I have two main questions:

I am developing a program on my chip and attempting to establish a connection with the WiFi Aware demo app launched by iOS 26. Currently, I am encountering an issue during the pairing phase. If I am the subscriber of the service and successfully complete the follow-up frame exchange of pairing bootstrapping, I see the PIN code displayed by iOS. Question 1: How should I use this PIN code? Question 2: Subsequently, I need to negotiate keys with iOS through PASN. What should I use as the password for the PASN SAE process? If I am the subscriber of the service and successfully complete the follow-up frame exchange of pairing bootstrapping, I should display the PIN code. Question 3: How do I generate this PIN code? Question 4: Subsequently, I need to negotiate keys with iOS through PASN. What should I use as the password for the PASN SAE process?

Since upgrading my iPhone 13 Pro Max to iOS 26, apps have become nearly impossible to debug. The recent update to iOS 26.1 has made this even worse. Going from app start to a fully rendered & responding screen takes <1 second on a Debug build when no debugger is attached, but with the debugger attached I get these times (measured manually with a stopwatch): First render: <1 second without debugger 5 seconds on USB debugger 30 seconds on wireless debugger Data loaded from webserver and UI responding: <1 second without debugger 19 seconds on USB debugger 5 minutes on wireless debugger! Doing an online speed test reports 55 Mbps for the phone and 60 Mbps on the MacBook, so I doubt it's my WiFi. Having a debugger attached used to make minimal difference on iOS 18, but the performance has tanked completely since the last major release. What happened?