Post not yet marked as solved
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.
Post not yet marked as solved
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).
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
Same here. Really need a fix as it's slowing down development tremendously.
I'm seeing this with Xcode 14 beta 6 as well with a Catalyst app. The full text I'm getting is:
This bundle is invalid. Apple is not currently accepting applications built with this version of Xcode. (ID: 5247ff4d-2c7f-4bea-b17b-959c52b4e792)
Post not yet marked as solved
The problem seems to be fixed in macOS Ventura 13.1 Beta 2. Thank you Apple engineers for taking care of this!
Post not yet marked as solved
If your UI use UINavigationController (which of course contain UINavigationBars) then you are likely seeing the NavigationBar-in-NSToolbar hosting that is done by default for iOS 16 linked apps. If you want to disable this then you need to set the preferredBehavioralStyle of each UINavigationBar to .pad
Unfortunately, setting preferredBehavioralStyle to .pad will show the title bar under Ventura, even if the title bar should be hidden. Below are screenshots from a quick demo project I created, the first is built against the Xcode 14 and Catalyst 15, the second is built under Xcode 14.1 and Catalyst 16 with preferredBehavioralStyle set to .pad:
This is a problem if you are hosting everything inside of a UISplitViewController and want to run the secondary view all the way to the top of the UI. Before, you could even do this with navigation controllers by setting additionalSafeAreaInsets.top to a negative value matching the height allotted for the title bar, but doing so under Catalyst 16 with preferredBehavioralStyl set to .pad gives you this instead, where you can see the navigation bar hidden under the title bar that is supposed to be disabled:
The only workable solution I have found (beyond building against Catalyst 15, which precludes newer features) is to use the leadingItemGroups, centerItemGroups, and trailingItemGroups properties of UINavigationItem when running under Ventura instead of leftBarButtonItem, titleView, and rightBarButtonItem.
This works (mostly), but makes maintaining the codebase for backward compatibility more difficult by adding conditionals every time you need to deal with a navigation item. Yes, you can abstract this out, but even then, for a large codebase it adds additional risk of breaking previously working behavior.
Also, there seems to be a problem with clipping the hosted view. If you look at the example below, you can see the segmented control in the center has its border clipped along the top and sides:
Ideally, setting preferredBehavioralStyle set to .pad would give the prior behavior across the board, making everything much easier to maintain for backward compatibility purposes. I think this is particular important on the Mac as, at least in our case, we have found our Mac customers tend to upgrade their OS and hardware at a much, much slower rate than with iOS. And with subscription-based software, it is important to make newer features in the app itself available to these users.
Post not yet marked as solved
I've run into this same problem, particular when the main view is hosted by a UISplitViewController. An empty title bar is always shown above the secondary pane, when building under Xcode 14 (14.0 and the 14.1 beta) and running under Ventura. The problem is resolved when building under Xcode 13, but that locks out new features.
As it is now, we are likely going to have to fork the code and build the Mac version under Xcode 13 and continue with iOS/iPadOS under Xcode 14.
@pistoleta – It's been a while since I asked this question. Over that time, I've been developing the app using CloudKit. It's in beta now, due for release in March, and we haven't run into any limit issues with using private CloudKit storage, so long as the user has enough storage in their account and the application properly handles service unavailable and rate limit messages. Hope this helps.
Feedback FB8880428 filed for this bug.
