I’m having the same problem, only with another Lib: This is what the E-Mail from Apple sais about my App: Although delivery was successful, you may want to correct the following issues in your next delivery. Once you've corrected the issues, upload a new binary to App Store Connect. ITMS-90863: Macs with Apple silicon support issue - The app links with libraries that aren’t present in macOS: /usr/lib/swift/libswiftWebKit.dylib And I notice that the App can’t be installed on my Mac via Testflight. The latest AppStore version of the App can be installed on the Mac (from with the AppStore). I’m not sure when exactly the issue has started, but there are other threads in the Apple developer forum where developers have the very same problem: https://developer.apple.com/forums/thread/766061 https://developer.apple.com/forums/thread/756325 https://developer.apple.com/forums/thread/771068

Just a followup: Apple just approved the "com.apple.developer.web-browser.public-key-credential“ entitlement for my App. And the first tests look good. The „Webauthn“ demo pages which failed before do now work fine. So this entitlement seems to be the correct approach.

Which kind of authentication is this? There exist different ways to authenticate: the most common ones are web forms (which use cookies to preserve the login state for example) and HTTP authentication (which would use the URLCredentialStorage so preserve credentials). Cookies are usually stored automatically by the WKWebView, but depending of the configuration, it might not do this. For example if the websiteDataStorage property of the WKWebViewConfiguration is configured to use a non-persistent storage, then cookies won't be stored (for example this is the case when using private tabs in Safari). Also, since iOS 17 it is possible to create your own WKWebsiteDataStore objects and don't need to rely on the "shared" one or the non-persistent one that is provided by the iOS. If you create your own, then you need to make sure you use the correct identifiers, because the identifiers define which of the storages is actually used. When using a random identifier (like a uuid), you would create a completely new storage each time. For HTTP authentication, you usually need to add some code yourself to handle these and make sure that the credentials are stored permanently (see the URLCredentialStorage API).

I have this problem too. But it is way more complicated and weird. This can be seen more easily when the control has more than only 2 segments. First of all, if the very first segment is currently selected, then (and only then), you can successfully tap and select another segment. If the first segment is currently not selected, any tap on any segment will always select the first segment. So you would always need to tap two times on a segment to actually select it. Second, the label of the currently selected segment is almost never visible. The only exception is the falsely selected first segment if you actually tried to select another segment. And the new "liquid glass element" effect when dragging the selection between the segments (instead of just tapping) also almost never works. In my case, the UI is defined via Storyboard. So you can reproduce this issue with no code at all. Just put a UISegmentedControl in the view of the ViewController of a newly created App and keep the App template that was created by Xcode unchanged. I've already send a bug report: FB18336315

I think you only need to set the sourceView/sourceRect or barButtonItem properties for the popoverPresentationController of the UIAlertViewController before presenting it. Until now this was only necessary for the actionSheet style on the iPad, but I think under iOS 26 this can be also used for the alert style to define the anchor point to which the UIAlertViewController is attached to.

Maybe related: I've created a new App and wanted to distribute it via TestFlight to internal testers, but added me first to check out everything. But when opening the invitation email, the TestFlight App tells me that the email address with which I'm currently logged-in in TestFlight (and it names the email address in clear text) is not the one which is associated with the invitation. It also tells me that I should login with my original account and showing me its address (slightly anonymized), which is exactly the same as the one it has found not the right one before. So I assume that right now there's something broken with TestFlight when it checks if it is allowed to install the App. In my case it fails to detect if identical email addresses are indeed identical. Maybe in your cases, the problem is something similar, but because you already have the App in Testflight and don't need an invitation anymore, you don't get an error message. Maybe the problem is also related to the iOS 26 Beta, because I used Xcode 26 and the App was built for iOS 26. But the error message does not indicate anything like that.

My bugreport FB18336315 does include a test project. The bug is still present in iPadOS 26 Beta 4