Actually MapKit_JS also supports polylines, annotations etc, the API is very similar to the native MapKit. So MapKit_JS could be a solution because it can almost do everything the local MapKit can do. However unlike the local MapKit, MapKit_JS ist not necessarily free. There is a usage quota. If you do not reach it, it's free, otherwise you need to pay a price (Apple does provide public information about the price tiers, so you need to contact Apple if you expect to be over the quota).

No, not really. This is actually my App and is actually using MapKit_JS via WKWebView to load maps. Unlike the native MKMapView which won't work in QuickLook extensions anymore, WKWebView still works. And because there are map services available via Web (including Apple Maps via MapKit_JS), you can load the maps this way. It's much less convenient and also has some limits (there's a usage quota and there are fees when you need more).

If I understand it correctly, MapKit did work fine in a QuickLook extension before MacOS "Sequoia". So this seems to be a bug.

How does blocking internet access of MapKit protect the user? MapKit does't allow random internet access and can not be used to abuse the users data. All internet access that is happening here is going to the Apple Maps server and this traffic is fully controlled by the system. So no danger at all for the user. Whereas WebKit is working just fine in QuickLook (the macOS comes with QuickLook extensions for URLs and web locations) and here random unrestricted internet access is possible.

Also which object do you release? And when exactly? In general the script message handlers should be set once when creating the WebView and released only before releasing the WebView itself. The JavaScript code is running completely independently from the swift code of your App, so it can be tricky to find the correct time to release the message handler and being sure that it is no longer in use by the JavaScript code.

How does your JavaScript code look like? I guess if the message you post from your JavaScript code can not be converted into a swift-compatible object (like a string, dictionary etc), the "body" might be nil (though according to the API, body is not an optional and therefore can not be nil). This would be a bug in the iOS, however you should be able to make sure that this bug is never triggered: Just make sure your JavaScript code only posts valid objects through the message handler.

Thank you very much for the clarification. However I think this needs some official documentation. Also it is unclear why this only covers the "App Limits" section of Screen Time and not the very similar content-based restrictions. In both cases the limits are based on the URLs of web sites, so there's no logical difference. If you expose these errors to Apps, they really needs to be documented and "stable". Apps need to know the reason for errors in order to be able to respond correctly.

Unfortunytely simply building and uploading the App again might not always work - at least not without some extensive testing and maybe some changes. This is because we now use a new version of Xcode, new Frameworks, new mandatory keys for the Info-plist, etc. Depending of the age of the last App release, there can be a lot of changes which may need attention.

Done. FB19332453

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

Yes and no. When creating the button programatically you can actually tap on sections to select them and this does indeed work fine. However, if you do not tap, but instead drag the selection (which will the show a glass element which is then dragged), then in most cases a “ghost selection” is shown on top of the first segment (regardless of the section you are coming from and to where you are going to). Though this seems to be just a visual glitch and doesn’t result in a wrong result.

I can not confirm this. On my devices the segmented control does never work, when created via storyboard or xib/nib files.

Unfortunately, segmented buttons defined via storyboard do not work on real devices. A simple project without any code, just putting a segmented control into a view in the default storyboard, will already show the error on real devices (tested on an iPad Pro 11” M4 with iPadOS 26 beta 3). it looks like the issues does not occur if the segmented control is created programmatically. I’d did not find a single instance where it worked with storyboards or nib/xib files.

Setting frames and bounds is still supported. But you need to make sure the property "translatesAutoresizingMaskIntoConstraints" of the views is set currently. This property tells the iOS wether you want to use constraints (false) or the frames/bounds and autoresizing masks (true) to do the layout.

My issue is the sidebar itself and its appearance, not the content underneath the sidebar. As BabyJ has commented, this might be a limitation of the UITableView API and I should use UICollection View instead (though I need to drop support for older iOS releases then)