I went over everything again and noticed that my developer Team ID was prepended to the app's bundle id for the denial entry in swcutil_show.txt. The documentation (https://developer.apple.com/documentation/xcode/supporting-associated-domains) says the appIDs entry should be in the form of .. I'd assumed Application Identifier Prefix was the Apple ID of the app as I've seen these used interchangeably before. Anyway, I added the Team ID as a prefix and all is working. Not sure if this is an error in the documentation or if app's Apple ID is used in production. As a hedge I added both variants (prefixed by Team ID and prefixed by App ID) to the appIDs entry.

100% agree the current implementation seems half-baked, and that's being generous. It also doesn't fit with some designs so to effectively remove existing behavior in favor for one that isn't workable seems silly. It also breaks some behavior in Catalyst, even though it should not change anything on that side. Not having an opt-out is extremely frustrating and the Feedback system has shown itself to be woefully inadequate in getting things fixed. At the very least an opt-out option allows developers time to figure out how to rework their apps to integrate it properly while still being able to take advantage of other features in iPadOS 18. This is just yet another thing that has me losing faith in Apple and makes me question on whether its a worthwhile platform for future projects.

A quick update. This is caused by the new tab bar for iPadOS. If you have a complicated app that uses UITabBarController in multiple ways, you can end up with a title bar with unwanted tabs that completely breaks your UI. There does not seem to be a way to disable this behavior, which I wish Apple would implements ASAP.

100% agree there needs to be a way to disable this. Having it be automatic with no way to disable it can break more complex UIs and operates under the assumption that it is a better approach, which it may not be for a given app. It also has some unwanted effects with Catalyst apps, such as forcing a title bar/toolbar at the top of the window containing the tabs from the tab view, even if the app wants to hide the titlebar. Again, I think it is an erroneous assumption that every app should want this and there needs to be an opt out. The accepted solution does not accomplish this. I'm not sure why it was marked as such.

I was told the change in behavior for Catalyst is by design. To me, since it worked before and still works this way on the iPad, this is a regression.

I never heard anything back from Apple on the feedback and wasn't able to find a work around, so I wound up writing my split view host that I used instead of UISplitViewController. This and a number of other regressions that have gone unfixed make me question whether Apple is putting any effort into Catalyst.

I repeatedly get this problem for an app I'm developing Xcode (yes, the app is signed with a developer certificate). The message keeps appearing every few minutes to every few seconds. Even after a reboot, I'm greeted by this message. It has killed the user experience. At the very least, this alert should have a checkbox for "don't show me this again for this app – ever". Yes, yes, I know: file a feedback. But, I've completely lost faith in the feedback system when it comes to getting problems fixed with macOS. The last few major issues I've run into, I've had to file a DTS request to get them to look at it and confirm the bug to finally get attention for a feedback filing.

This seems to have been fixed in macOS 14.4 Beta 5.

Update: It appears Apple is working on a fix. Fingers crossed it makes it in for the release version of macOS 14.4.

This problem still exists in Beta 4 of macOS 14.4.

I've found this type of thing to be the norm with filing Feedbacks as well. IF (and that's a freaking huge if), you get any kind of response at all, it quickly becomes clear that whoever is looking at the issue never bothered to try the sample project and half the time seems like they are responding to a completely different problem. And that's if you don't end up with the generic response that tells you to re-verify if the bug still exists and attach a SysDiagnose. That last one manages to combine being impersonal, dismissive, and lazy all rolled up into one. It's kind of impressive in a weird way. Infuriating and unhelpful, but impressive nonetheless. In this past major OS release cycle, after weeks of hearing nothing on several reported bugs that are critical to our product, we opened a developer technical support instance in hopes of raising the visibility or at least coming up with a decent workaround. Literally a month went by with no response. In years prior, we'd hear back in a day or two on DTS requests. When I tried to follow up, they just said they were busy. Long story short, the bugs still exist (we've still heard nothing on the Feedbacks – no surprise) and we had to spend a considerable amount of time and effort on workarounds. Frustratingly enough, this is happening again with Catalyst in the betas of macOS 14.4. Apple can say they care about bugs all they want. Their actions and the entire Feedback systems says otherwise.

In case this helps anyone who stumbles across this, I was able to fix the problem by using the isNavigationBarHidden property instead of the setNavigationBarHidden method (the method failed regardless of whether the animated parameter was set to true or false).

When you commit you should see a Stage All button above the field where you write your commit message. You can click that to stage all changes for clicking the commit button. You can also select Stage All Changes from the Integrate menu. Personally, I much prefer the approach taken by Xcode 14.

Created feedback FB13289026 for this in case anyone at Apple is interested in looking at this (please?).

In case this helps anyone, I was able to get Settings in the iPhone 14 Pro simulator with iOS 17 to work, just not the iPhone 15 Pro. I just needed to select Manage Run Destinations and switch the iPhone 14 Pro's Show Run Destination from Automatic to Always.