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

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.

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.

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

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).

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.

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

I'm currently looking for the very same thing. I guess you need to request the "com.apple.developer.web-browser.public-key-credential" entitlement for your App, which will then unlock the Webauthn code within WKWebView. The documentation from Apple doesn't tell much at all, unfortunately. At least this seems to be the case on the iOS platform when you have the "com.apple.developer.web-browser" entitlement (this entitlement is iOS only).

At least now it works. For unknown reasons it did not work in my main project yesterday, repeatedly. But since yesterday the code was changed a lot and the Mac was also restarted, so whatever has caused the glitch, it can no longer be reproduced.

A strange thing happened: The rejected items were approved recently, though I did not submit the items for review again. But I won’t complain if it stays this way.

I can experience the same issue and this bug breaks some features of my App as well. But I’ve found some kind of workaround: If you overide WKWebView you can override buildMenu(with builder: UIMenuBuilder) there. Within this method you first call super.buildMenu(with builder: UIMenuBuilder) to let the webview do its menu configuration and then you can do your own menu configuration (for example adding your own menu items). This might not be the most elegant solution, but at least for my project it is an easy workaround and works well.

In the „Capabilities“ secion you need to add the „background modes“ capability and here check the „location updates“ option. And in the „Info.plist“ you have to either add the key NSLocationAlwaysAndWhenInUseUsageDescription or the keys NSLocationAlwaysUsageDescription and NSLocationWhenInUseUsageDescription. The value for these keys must be a string explaining why your App needs the location services.

Without seeing the code, it’s hard tell what exactkly is going on. But I would guess that the Map is simpy embedded into your view with the „safearea“ margins still active, so the system will automatically move the map away from dynamic island and other system elements at the screen borders, so the view is not partly hidden. And if you add your own margins to the view you might get such a big unused area… So no navigation bar needs to be involved here.

Same problem. But it also affects beta releases, so you can't even submit to TestFlight.

Same problem here. Yesterday it did work just fine. Strangely, this also applies to beta releases so I can't even submit an App via TestFlight.