Thanks a lot for your reply. I don't have any code that listens for the UISceneDidDisconnectNotification though.

I just tried manually posting a UISceneDidDisconnectNotification just to be sure,  UIWindowScene *windowScene = self.view.window.windowScene; [[NSNotificationCenter defaultCenter]postNotificationName:UISceneDidDisconnectNotification object:windowScene userInfo:nil]; Didn't cause anything to happen

After three years this issue has resurfaced. Huh.. it's very hard to reproduce. My best guess is there is some code path in UITableView that removes a header view after a delay, perhaps batched updates/animation etc. and if the data source is mutated this code path that cleans up the header view isn't being reached, and thus I'm left with an abandoned header view inside my table view. I verified that the header view is in the view hierarchy but its not in UITableView's reuse queue...it's scrolling in there but isn't associated with any of the table view's existing sections. Only workaround I can think of is to gather all UITableViewHeaderFooterView added to the the table view's hierarchy... -(void)didAddSubview:(UIView*)subview {     [super didAddSubview:subview];     if ([subview isKindOfClass:[UITableViewHeaderFooterView class]])     {         [self.theHeaderViewStash addObject:(UITableViewHeaderFooterView*)subview];     } } -(void)willRemoveSubview:(UIView*)subview {     [super willRemoveSubview:subview];     if ([subview isKindOfClass:[UITableViewHeaderFooterView class]])     {         [self.theHeaderViewStash removeObject:(UITableViewHeaderFooterView*)subview];     } } Then at some point clean up: -(void)cleanHeaderViewsLeftStranded { if (self.theHeaderViewStash.count == 0) { return; } NSSet *visibleHeaderViews = //gather any existing header view returned from UITableView' -headerViewForSection: //Remove NSMutableSet *localStash = [self.theHeaderViewStash mutableCopy]; [localStash minusSet:visibleHeaderViews];  for (UITableViewHeaderFooterView *aHeader in localStash)   { [aHeader removeFromSuperview]; } } I'd rather pound sand than have to do this...that's a lot of ugly code but I that's all I got...this bug has been lingering in UITableView for years... not sure when I should call the cleanHeaderViewsLeftStranded perhaps in a -layoutSubview override.

I also have the same issue on iOS15.7. I don't know the cause, but the number of crash reports is increasing. Did adding it to UISceneDidDisconnectNotification not reduce the number of crashes? Ya, the crashes have been piling up since iOS 15.7, even on older builds that were fine before and I released well before iOS 15.7. I don't know what you mean by "Adding it to UISceneDidDisconnectNotification"? Taking a look into this a bit deeper I discovered the four following objects listen to UISceneDidDisconnectNotification (three are private API). UIScreen UIEventEnvironment _UIRemoteKeyboards _UIObjectPerCanvas

I just manually posted the notification to try to tease out the issue per @andyl_'s suggestion that I had registered an observer for UISceneDidDisconnectNotification with an invalid selector...so I manually tried posting the notification to trigger the crash (but as a mentioned, I do not have any code that listens for this notification). All observers of UISceneDidDisconnectNotification are owned by the system.  I just submitted the crash-fixed version for review and am waiting for the review to be completed. In my multiple apps, there are apps that crash on iOS15.7 and apps that do not crash. I found the difference and took countermeasures. Can you share your solution? I can't reproduce the crash in my test environment at all. It probably doesn't help that Apple didn't ship iOS 15.7 SDK simulator runtime to developers.

This behavior has been around for years. Pretty sure I filed a bug on this years ago and they closed it as “works as intended” and basically told me to pound sand. I recall a related issue where if your app was set to “Launch at login” launch services would sometimes launch an app build in Xcode archives at login. I think it’s possible to workaround the issue by unregistering the app with lsregister…I never tried. I manually zip my Xcode archives to avoid this issue..been doing it forever. Even if there is a workaround it’s absurd default behavior. Pretty sure Apple has known about it for a very long time.

I decided to just live with the safeAreaInset bottom value of 20.0 even when the external window scene is presented like this. Adjusted a few things to make it look better in my UI but not worth comparing the frame of the window vs the frame of the screen to detect this state, as that code is too fragile. I still think the safeAreaInset bottom should be 0 when the window scene is presented in this style.

https://developer.apple.com/forums/thread/670068 This answers my question. A new "Xcode Extension" project right out of the box does not have "XcodeKit" set to Embed and Sign, which seems like a bug to me.

I opened a thread on this issue here: https://developer.apple.com/forums/thread/716151 Still haven't been able to find a workaround (or even reproduce the issue on my iPad running iOS 15.7). But I'm def. getting loads of crashes for this.

Attempting to use Catalyst for the first time. I just switched on "Optimize for Mac" and got this on launch. Some compiler warnings for this would be nice.... I'm supposed to just run the app and find forbidden objects for the "Mac idiom" by trial and error?

How is Basic going for you? Did it get any better? I started a Basic campaign recently. After the first day it seems Apple just stopped serving the ads for my Basic campaign. I also tried increasing the CPI but that hasn't been successful yet (I'm going to give it a little more time). What's weird is I can only find the Ad in the App Store on a direct search of my app name. My concern of course with that is Apple charging me for installs on a direct search of my app by name (since they place the Ad over the organic result). If the ad is being served as a result of other search queries, I haven't been able to find it. Of course if Search Ads starts getting my app valuable installs all is forgiven but I haven't really seen Basic do anything so far.

Whaaat I can't delete a keyword. It's 2022 this thread was created six years ago? Thanks for caring Apple.

The separator snaps into place after I resize the window....anyway I can programmatically force the window to relayout the separator? The request geometry update method isn't released yet (I guess it will be released when iPadOS 16 comes out?)

I think if figured out what's going on. On launch my app needs to determine whether or not it should show onboarding UI based on a few conditions. While my app is making this determination, I overlay a separate UIWindow in the UIWindowScene that shows a UIActivityIndicatorView. Then if I do in fact have to show the onboarding UI, this overlayed window shows the onboarding view controller by presenting it modally. Underneath this overlayed window is my standard UIWindow. In that window hierarchy underneath there is a UINavigationController with navigation bar. It appears UIKit on macOS draws this separator line underneath the navigation bar when the window is in certain states...but the separator is bleeding through from the UIWindow that's offscreen. That UIWindow should be completely offscreen while the overlay window is the key window (and it is, except for the line separator bleeding through and causing this glitch). So if I do this: #if TARGET_OS_MACCATALYST     [self setNavigationBarHidden:YES animated:NO];     #endif The line separator issue goes away.

I did open a feedback on this: FB11681351 duplicating the information I provided in this thread.