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.

Bug report FB16607985

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.

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

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.

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.