The question is, does originalAppVersion return the version or the build number? If it's the latter (which would be the case if the documentation is correct), then this is a problem. A new Xcode feature automatically manages the build number when uploading new builds. Xcode always starts with 1 as build number for each new version and counts upwards with new builds. So you have V1.0 B1, V1.0 B2, V1.1 B1, V2.0 B1 etc. Which means the build number is not unique and therefore is useless.

I've opened a bug report, however I was not able to reproduce this bug in a "simple" project. The bug occurs in my real App, which is rather complex, and I can even reproduce it when I strip down the WKWebView in my App to the raw basic (no delegates, no observers, no script message handlers etc), so it's impossible to use the WKWebView object in any way that is not supposed to. And the fact that there's no issue in all older iOS releases indicates, that there's a new problem within WKWebView.

OK; I've finally found a way to trigger this bug even with a simple project, however it can take a little longer until the bug shows up. But eventually it does show up, always when being patient enough ;-) Bug: FB15553776

Nevertheless, if anyone has experienced this bug and even knows a workaround, please let me know. I know this bug is hard to debug, because it is so unreliable, and based on the experiences of my other bug reports, I don't expect a fix soon. So some kind of workaround would be great.

Bug report FB16607985

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.

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

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.

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)

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.

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.

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

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.

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

Done. FB19332453