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)

Unfortunately UICollectionViewCompositionalLayout is only available since iOS 14 and my App still supports older iOS releases. But I guess you're right, the UICollectionView API seems to have the capabilities that are needed here.

I would check other login forms as well. If it is working there, then it might be something special that microsoft is doing (and sometimes I have the impression that MS loves to do unusual things instead of sticking to common standards). It might be a special issue of this site. I do not have any personal experience with MS logins, but on "normal" other sites I do not have issues with the login status in WKWebView

For a new Beta I haven’t received an email with this error message. In the „Build-Metadata“ section it states that the App is compatible with macOS 12 and later. So it seems to be working now, though I’ve not yet submitted a new version for the AppStore.