@DTS Engineer I think your explanation is not entirely accurate. Actually the sandbox is already treating different system components differently. Therefore it seems very unlikely that the sandbox can not distinguish between "allowed" and "forbidden" network traffic. MapKit is an encapsulated system component, so it is more or less impossible for a Quicklook extension to send random and uncontrolled network requests. All the network access is completely controlled by the system. So it seems extremely unlikely that there are serious security issues here. BTW: in the past, MapKit did work in Quicklook extensions. On the other hand, WebKit (WKWebView) is(!) working in Quicklook extensions just fine. But unlike MapKit, WebKit is able to do random and uncontrolled network requests, therefore could be a security issue. Which means the sandbox is actually distinguishing between different system components. The harmless one it does block, the "dangerous" one it let pass. I do understand that WebKit is "allowed". There are many extensions which need network access (including many of Apple's own), for example to display web link previews, video/audio streams. So it makes much sense that this is possible. My thoughts: Instead of making the macOS less useful by blocking all kinds of useful Quicklook extensions, maybe it would be better to simply ask the user for permission, like this is done for other security or privacy related things (like accessing photos, calendar, location services etc). So the user can decide. And in practice, the user is already forced to enable each Quicklook extension manually in the settings. So it is already impossible that an extension can be used without the knowledge of the user. Honestly, what is the point in blocking network access of a Quicklook extension, if the Host-App of this extension still has full network access. If an App would do something bad, it does not need its Quicklook extension, it can do this itself and much more. Also because Quicklook extensions are now always part of their "Host" App, it is impossible to have any invisible hidden extensions lying around, which the suer can forget about. If the App is deleted, the extension is gone automatically as well. So if the macOS tries the Quicklook extension as "dangerous" it would also have to treat the host App as dangerous and would have to apply all restrictions to both. But of course, this would make the whole system completely unusable. In the end we must give the user the opportunity to decide. Does the user trust an App to use it, then this should apply to the Apps extensions as well. For and possible danger it is fine to ask the user for permission, but if the user allows anything, the system doesn't need to block this anyways. And at the end Apple can still reject a developer certificate to "kill" the App in case it turns out that the App or developer is doing something bad.

Seems to be finally fixed in the new iOS 27 Beta

The bug is still present in the 26.6 Beta. I wonder what exactly needs investigating so long, it's easy to reproduce and probably easy to fix (especially because it did work before). And this is just one of many many bugs which gets ignored by Apple. Should I bother to report bugs in the future (especially for iOS 27 which is coming soon)? I don't get the impression that Apps cares much. The only exception seems to the the WebKit team which is actually fixing bug. Any other bugs seem to remain open forever...

In iOS 26.4 the bug is still present. It seems the Apple team has forgotten to investigate the issue...

Actually it is even worse in Tahoe than it was in Sequoia: Within the Quicklook extension MKMapKit does no longer draw annotations. Overlays are still drawn, but no longer annotations.

@Engineer Is this really the case? I mean, this is MapKit, a system component which is under full control of the operating system and which is supposed to be "safe" and trustworthy. I would assume that system components like MapKit are able to access the internet to fulfil their main purpose. Just like the macOS does this for URLs and "web location" files where Quicklook has no problems in loading the web pages and displays a preview of these just fine. If you really think that any internet access for QuickLook would be a danger for the user, then you definitely need to stop supporting Quicklook for URLs and web location files. I guess we can agree, that system components like MapKit and WebKit are not a threat to the user and it won't be a risk for these to access the internet.

How exactly do you access the body attribute? And how exactly do you "post" messages to this handler in your JavaScript code? I do not see any issues in my App, which uses the script message handler extensively. So there doesn't seem to be a general problem here, but something specific of your code.

You don't need any special "capabilities", you only need WidgetKit. "Live Activities" are part of the WidgetKit. So use it to create a Widget Extension in which you would then implement the widget for the "live activity". Basically the WidgetConfiguration decides whether the widget is a live activity or a normal widget. Within your App you need to use the "ActivityKit" to communicate with the live activity widget (activate the live activity, tell it which data it should show etc)

Also the email gives the impression, that you could update the age ratings for existing Apps. But this is not possible. You can do this only for new builds. And if you can't provide a new build yet, you wonder what would happen. It should be also possible to update the age rating without submitting a new build. Some Apps (like games) just do not require an update.

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.