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 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.

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

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 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

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

Aha. The problem was I forgot to assign the configuration property on the content view! 🤦‍♂️ -(nonnull __kindof UIView<UIContentView>*)makeContentView { CustomContentView *customContentView = [[CustomContentView alloc]init]; customContentView.configuration = self; return customContentView; }

This bug is new in iOS 16.... running the app on iOS 15 and I get the expected behavior.

Heh this weird size is also passed to iPhone 13 Pro Max (even on IOS 15) but I didn't notice before because I also update the hidden property in -viewDidLayoutSubviews if landscape/iPhone combination is detected and on iOS 15 -viewDidLayoutSubviews is called after -viewWillTransitionToSize:withTransitionCoordinator: What makes this an issue in my app on iOS 16 is UIKit is now making an extra call to -viewWillTransitionToSize:withTransitionCoordinator: after viewDidLayoutSubviews (with the bogus size), so the call to hide the view in -viewWillTransitionToSize:withTransitionCoordinator: ends up winning. Another potential workaround is to move this code out of -viewWIllTransitionToSize:withTransitionCoordinator and into -viewWillLayoutSubviews OR use -willTransitionToTraitCollection:withTransitionCoordinator: -(void)willTransitionToTraitCollection:(UITraitCollection*)newCollection withTransitionCoordinator:(id<UIViewControllerTransitionCoordinator>)coordinator { //iPhone going landscape...translate the size class abstraction into normal terms.     if (newCollection.userInterfaceIdiom == UIUserInterfaceIdiomPhone         && newCollection.verticalSizeClass == UIUserInterfaceSizeClassCompact)     { //do it.     } [super willTransitionToTraitCollection:newCollection                  withTransitionCoordinator:coordinator]; } Looks like iOS may have stopped passing in the final destination size to -viewWillTransitionToSize:withTransitionCoordinator: in iOS 15, for unknown reasons. This is all from within a view controller presented modally.

Potential workaround:  [coordinator animateAlongsideTransition:^(id<UIViewControllerTransitionCoordinatorContext>  _Nonnull context)     {         UIView *container = context.containerView;         CGRect containerFrame = container.frame;         CGSize authenticSize = containerFrame.size; //use the size from the container view to workaround bogus size.     }     completion:nil]; Also tried moving this code to -traitCollectionDidChange: but it looks better if the view gets hidden before the rotation, not after.

I opened FB11580679

Changing my snapshot code to use UIGraphicsImageRenderer appears to have fixed the issue:   UIGraphicsImageRenderer *imageRenderer = [[UIGraphicsImageRenderer alloc]initWithBounds:snapShotView.bounds]; UIImage *snapShotImage = [imageRenderer imageWithActions:^(UIGraphicsImageRendererContext *rendererContext)     {         CGContextRef cgContext = rendererContext.CGContext;         [snapShotView.layer renderInContext:cgContext];     }]; Not sure why UIGraphicsBeginImageContextWithOptions API was generating a clipped image only in the landscape orientation on certain iPhone models like iPhone 14 Pro. For whatever it's worth the view being "snapshotted" is offscreen (not in a UIWindow). Migrating to the newer API works for me (I should have been using UIGraphicsImageRenderer in the first place anyway).

I filed a feedback: FB11573728

Huh when I added an updated copy of GoogleMobileAdsSDK somehow the .xcframeworks got added to the "Embed Frameworks" area in Xcode. Not sure if Xcode did that automatically on drag and drop or if I did it by mistake...but after I removed them from the "Embed frameworks" area uploading worked.

I just reported this.....iOS has so many alarmist system logs now devs have no way of controlling.