So I pushed an App update that uses the check above in layout subviews to block myself from accessing visibleCells during layoutSubviews (in my testing that wasn't showing to be occurring but since this crash is so rare I figured it might be the cause under some rare circumstances) so figured it was worth a shot. I've been using the app for two days now with the new update (quite a bit). I finally hit the crash again. Crash reports show that my call to the visibleCells getter is that last part of my code being called. Then it goes to system code and then I crash (here's the call stack after I call the visibleCells getter) 0 CoreFoundation 0x19c789e48 __exceptionPreprocess + 164 1 libobjc.A.dylib 0x195a5b8d8 objc_exception_throw + 60 2 Foundation 0x19704a94c _userInfoForFileAndLine + 0 3 UIKitCore 0x19eaa0888 -[UITableView _createPreparedCellForGlobalRow:withIndexPath:willDisplay:] + 572 4 UIKitCore 0x19ea744cc -[UITableView _updateVisibleCellsForRanges:createIfNecessary:] + 596 5 UIKitCore 0x19e9adb28 -[UITableView _updateVisibleCellsNow:] + 1088 6 UIKitCore 0x19e9785e8 -[UITableView _visibleCellsUsingPresentationValues:] + 340 Anyone at Apple know what exception is being thrown here down this code path (or possible exceptions, if more than one is possible)? That'd at least point me in some kind of direction as to what (if anything) I can do to avoid this. Thanks in advance.

I tried overriding -layoutSubviews in the table view subclass to see if I'm accessing visibleCells in the middle of table view layout: -(void)layoutSubviews { self.isBuildingCellsInProgress = YES; [super layoutSubviews]; self.isBuildingCellsInProgress = NO; } Then in my checkIfLoadingCellIsIsVisible method I check if isBuildingCellsInProgress property is YES on the table view, and if it is, return out and don't call the visibleCells getter. Unfortunately the isBuildingCellsInProgress is never YES when the checkIfLoadingCellIsIsVisible method is called. Haven't been able to isolate the issue. The only thing I can say for sure is that it started happening every so often since the iOS 16.2 update. I do have a few of these tables views inside UITabBarController tabs. I'm thinking the issue may be triggered when this code is hit on a table view not currently in the window (the user is on another tab), but I can't say for sure because I'm unable to reproduce the issue when my app is attached to the debugger. When the "loading" cell is visible and the table view is not in the window my app just empties the data and reloads it on the next -viewDidAppear: call so enumerating the visibleCells when the table view is not in the window still provides value.

Hmm just hit it again. Slightly different code path this time before the -checkIfLoadingCellIsIsVisible method is called. This time after an object was removed from the model: ** Last Exception Backtrace: 0 CoreFoundation 0x19c789e48 __exceptionPreprocess + 164 1 libobjc.A.dylib 0x195a5b8d8 objc_exception_throw + 60 2 Foundation 0x19704a94c _userInfoForFileAndLine + 0 3 UIKitCore 0x19eaa0888 -[UITableView _createPreparedCellForGlobalRow:withIndexPath:willDisplay:] + 572 4 UIKitCore 0x19ea744cc -[UITableView _updateVisibleCellsForRanges:createIfNecessary:] + 596 5 UIKitCore 0x19e9adb28 -[UITableView _updateVisibleCellsNow:] + 1088 6 UIKitCore 0x19e9785e8 -[UITableView _visibleCellsUsingPresentationValues:] + 34 7 MyApp           0x103125120 -[MyTableViewSubclass checkIfLoadingCellIsIsVisible] My App 0x1045b4380 -[MyTableViewControllerClass processRemovedObjectsNotification:] + 1573760 ** The -processRemovedObjectsNotification: method removes objects from the data source and reloads the table view (via -reloadData call). Then after reloading the table view it calls -checkIfLoadingCellIsIsVisible which enumerates the visibleCells to see if a loading more placeholder is in the visible region of the table view. Definitely feels like something changed in UITableView in iOS 16.2 because I've been using this app for so long and it would seem highly unlikely for this to just be a coincidence. I still have a device on iOS 15. I haven't hit this crash on that device. But since going from iOS 16 to 16.2 on my iPhone I hit this like once or twice a day now.

Thanks again for the reply (for some reason I didn't get an email notification for your Comment even though I'm "Watching" this thread." I just hit the crash again. I haven't hit it in a couple days (it isn't easy to reproduce). Exact same crash report as before just now: ** Last Exception Backtrace: 0 CoreFoundation 0x19c789e48 __exceptionPreprocess + 164 1 libobjc.A.dylib 0x195a5b8d8 objc_exception_throw + 60 2 Foundation 0x19704a94c _userInfoForFileAndLine + 0 3 UIKitCore 0x19eaa0888 -[UITableView _createPreparedCellForGlobalRow:withIndexPath:willDisplay:] + 572 4 UIKitCore 0x19ea744cc -[UITableView _updateVisibleCellsForRanges:createIfNecessary:] + 596 5 UIKitCore 0x19e9adb28 -[UITableView _updateVisibleCellsNow:] + 1088 6 UIKitCore 0x19e9785e8 -[UITableView _visibleCellsUsingPresentationValues:] + 34 7 MyApp           0x103125120 -[MyTableViewSubclass checkIfLoadingCellIsIsVisible]** I don't see anywhere in my -tableView:celForRowAtIndexPath: method the possibility of my app returning nil unless for some strange reason UITableView -dequeueReusableCellWithIdentifier:forIndexPath: returned nil in some odd circumstance to me. I've been using my app for a long time on daily basis and this didn't start happening until after I updated to iOS 16.2, not sure if that's related though.

Using the image property on NSToolbarItem and passing in a SF symbol image does not create a toolbar item that matches the size of the other items created through UIBarButtonItem. The image toolbar item is clearly bigger than the ones created with UIBarButtonItem APi. Setting the bordered property to YES (which means only bordered on highlight these days) did the trick.

Thanks for the reply. That's not my post on Stackoverflow but I'm experiencing a similar crash that percolates up to -_createPreparedCellForGlobalRow:withIndexPath:willDisplay The crash report for my app doesn't actually get to -tableView:cellForRowAtIndexPath: Instead I can see it all starts from my app checking the .visibleCells property on the table view: 0   CoreFoundation                       0x19c789e48 __exceptionPreprocess + 164 1   libobjc.A.dylib                      0x195a5b8d8 objc_exception_throw + 60 2   Foundation                           0x19704a94c _userInfoForFileAndLine + 0 3   UIKitCore                            0x19eaa0888 -[UITableView _createPreparedCellForGlobalRow:withIndexPath:willDisplay:] + 572 4   UIKitCore                            0x19ea744cc -[UITableView _updateVisibleCellsForRanges:createIfNecessary:] + 596 5   UIKitCore                            0x19e9adb28 -[UITableView _updateVisibleCellsNow:] + 1088 6   UIKitCore                            0x19e9785e8 -[UITableView _visibleCellsUsingPresentationValues:] + 340 7   MyApp                      0x103125120 -[MyTableViewSubclass checkIfLoadingCellIsIsVisible] The checkIfLoadingCellIsIsVisible just enumerates the .visibleCells property on the table view, looking to see if a "loading more" cell is in the visible region of the table view. I've been unable to reliably reproduce the crash. Haven't managed to reproduce it at all when attached to the debugger. I picked up two of these crash reports today since I updated to iOS 16.2.

FB11889554

I usually don't do this, but I wonder if not enough developers are providing feedback so I'm going to go on a short tangent. Just to go back to my snippet of what I consider to be “normal API”: windowController.window.frame = initialRect; windowController.modelData = modelObject; [windowController showWindow:sender]; This coding style has essentially been “abstracted away” in Catalyst underneath this: NSUserActivity *newWindowActivity = [[NSUserActivity alloc]initWithActivityType:@“my.new.window.activitytype”]; //Our options to pass data to the new window are the following: //Option 1) Write methods to convert a model object to and from one of the types NSUserActivity's userInfo accepts. //Option 2) Make the model object conform to NSSecureCoding and convert it to and from NSData and stuff the NSData in the activity). //Option 3) Pass a "database identifier" and query for the model object on the other end from a singleton and/or database. //In this sample I'm using option 1 because that's the "easiest." Not always possible though. NSArray *modelAsPlist = [modelData propertyListRepresentation]; NSDictionary *modelDictionary = @{@"NewWindowModelData":modelAsPlist}; [newWindowActivity addUserInfoEntriesFromDictionary:modelDictionary]; UISceneActivationRequestOptions *activationOptions = [[UISceneActivationRequestOptions alloc]init]; activationOptions.requestingScene = self.view.window.windowScene; UIApplication *application = [UIApplication sharedApplication]; [application requestSceneSessionActivation:nil userActivity:newWindowActivity options:activationOptions errorHandler:^(NSError * _Nonnull error) { //Whoops the system didn't give me a window. Tough luck. What kind of error handling are application developers expected to do here? }]; And we still haven't achieved the three lines of the "normal API" yet. The controller that needs the model object still hasn't gotten it yet. And the initial frame for the window isn't set. Now on the other end in the UIWindowSceneDelegate: -(void)scene:(UIWindowScene*)scene willConnectToSession:(UISceneSession*)session options:(UISceneConnectionOptions*)connectionOptions { //connectionOptions can have more than 1 activity...we gotta dig for our model object and that's the bottom line because the System says so. NSUserActivity *activityToConfigureWith = nil; for (NSUserActivity *aActivity in connectionOptions.userActivities) { if (aActivity.activityType isEqualToString:@"my.new.window.activitytype"]) { activityToConfigureWith = aActivity; break; } } if (activityToConfigureWith != nil) { NSArray *topLevelModelPlist = activityToConfigureWith.userInfo[@"NewWindowModelData"]; ModelData *model = [ModelData makeWithPropertyList:topLevelModelPlist]; MyViewController *myVC = [[MyViewController alloc]initWithModel:model]; self.window = [[UIWindow alloc]initWithWindowScene:scene]; self.window.rootViewController = myVC; [self.window makeKeyAndVisible]; } else { //Not found. Maybe we have a state restoration activity to configure.. //Or maybe not. Maybe we are just on app launch. We have to sort our way through this pile of user activities just to get started here..it's kind of a mess. } CGRect systemFrame = scene.effectiveGeometry.systemFrame; CGRect newFrame = systemFrame; newFrame.size.width = DEFAULT_WIDTH; newFrame.size.height = DEFAULT_HEIGHT; UIWindowSceneGeometryPreferencesMac *geometryPrefs = [[UIWindowSceneGeometryPreferencesMac alloc]initWithSystemFrame:newFrame]; [scene requestGeometryUpdateWithPreferences:geometryPrefs errorHandler:^(NSError * _Nonnull error) { //Error setting frame. Tough luck! What kind of error handling are application developers expected to do here? }]; } Now in my real app a lot of this code I silo in categories because the amount of code required for such simple tasks is kind of absurd. All we did is 1) create a window 2) set its initial frame and model object and 3) show it on screen. Not sure how this was decided on but IMHO the abstraction is 10x more complex than the internal implementation. At the very least creating and passing data to a new window shouldn't be any harder than creating a new view controller programmatically or using storyboards with -prepareForSegue: But it is a lot harder. And requires lots more boilerplate. This doesn't include the code required to workaround the issue described in FB11885144. If you want to make it easy to port iOS apps to the Mac maybe just expose a NSViewController subclass in the public API that embeds a UIKit view hierarchy inside of it and let developers use them in NSWindows directly? Maybe?

YES IT IS POSSIBLE! EXCELLENT! Here's something that might be a Catalyst bug, but who knows what they'll say really. My UIActivityItemSource wasn't handling the Messages situation properly because -activityViewController:itemForActivityType: passes in @"com.apple.share.Messages.window" on Catalyst when the Messages activity is selected. This does not match the UIActivityTypeMessage constant, which is @"com.apple.UIKit.activity.Message".

I filed FB11885144

I can't even try setting the frame from the call site with this API:  [application requestSceneSessionActivation:nil                            userActivity:theActivity                                options:activationOptions                           errorHandler:^(NSError * _Nonnull error)     {     }]; } Because there is an error handler but I don't get back the created UIWindowScene on success.... Is it really necessary to have an error handler on opening a window? An error handler on setting a window's frame? Why is everything hard to do? Passing data to a new window has to be done through these absurd NSUserActivity objects.... Like why isn't there a normal API? windowController.window.frame = initialRect; windowController.modelData = modelObject; [windowController showWindow:sender]; I need an error handler to set a frame and to open a window? Am I making a network request? And if I get an error on set frame how exactly am I supposed to handle the error? Set the frame again and hope that it works?

I filed FB11884759

So basically what I'm trying to do is this: //Position the window in the center of the screen, initially. UIScreen *targetScreen = scene.screen;  CGRect initialWindowRect = CGRectMake((targetScreen.bounds.size.width/2.0)-(DEFAULT_SIZE.width/2.0),                                      targetScreen.bounds.size.height/2.0-(DEFAULT_SIZE.height/2.0),                                      DEFAULT_SIZE.width,                                      DEFAULT_SIZE.height); Sometimes the origin is ignored (depending whether or not another window is opened, the system adds a default space between open windows. Typically this is how "New Document" windows open on Mac but you wouldn't always want this behavior (for example the "Welcome to Xcode" window always positions itself in the center of the screen when opening). Also is there a way I can compute NSScreen's visibleFrame property from the Mac Catalyst environment so I can position the window relative to the visible frame (the area not including the menu bar and the dock)? UIScreen.bounds property is  (origin = (x = 0, y = 0), size = (width = 1440, height = 900)) but really I'd like to compute the initial window frame relative to NSScreen's .visibleFrame property which would be {{0, 95}, {1440, 780}}

So the -requestGeometryUpdateWithPreferences:errorHandler: does actually respect the origin if I call the method after a bit of a delay in scene:willConnectToSession:options: I know Catalyst automatically handles the window frame during stare restoration so I need to figure out if there's a way I can ensure my initial frame request won't be called after the system sets the frame on state restoration... because I don't want to break that. Only thing I can think of off the top of my head is maybe saving and restoring the window frame myself in a user activity, though I'm not sure if -requestGeometryUpdateWithPreferences:errorHandler: will respect my requested origin in -scene:restoreInteractionStateWithUserActivity: or if the request is too early their too. I don't really feel like doing this since the user could be on a different display (could close a laptop and connect an external monitor) between save and restored state and I don't feel like implementing frame translation code.

I have a couple submenus with children I'd like to group together in the context menu. Apparently wrapping them in parent menu like this is how you create a separator:  UIMenu *wrapperMenu = [UIMenu menuWithTitle:@"" image:nil identifier:nil options:UIMenuOptionsDisplayInline children:childrenToWrap]; Pretty convoluted but at least it's possible 👍🏻 Tried this earlier and it wasn't working because I think I was hitting the issue where Xcode wasn't compiling the latest code until I cleaned the build folder.