Thanks for the replies.I submitted FB7498558 which a copy of can be viewed publicly here http://www.openradar.me/radar?id=5062792444903424Yes they use a segue and the performSegue method can be seen, however interestingly it doesn't set the selectedRecipe so I was wondering how the method selectedRecipe retrieves the current selection if it uses the table view or if it searches the hierarchy to find it back from the detail controller that was segued to. Using table row selection for state is unreliable because setting editing clears the selection. Also they hook up a key command to an action that favourites the selectedRecipe, so I was wondering if that works on the selected row item or on the item showing the detail controller, in which case why doesn't the detail controller be the one handling the action.Another thing is the selectFirstRecipe method call, it can be seen as the last call in a method and I was wondering it is viewWillAppear which is where I would put it.

Since selected rows are lost during reload first you need to save the selected rows then select them again after the reload. Also because there might be a deselection animation you might need to animateAlongsideTransition and call setNeedsLayout on the cell if it is visible or setNeedsLayout on the tableView if not.This all seems very messy.Has anyone thought about using NSBlockOperation and addExecutionBlock to collect all of the calls and then start it when regaining the window?

I answered it here: https://stackoverflow.com/a/60085063/259521

A cell with a text field that is first responder and is scrolled off-screen is still considered being displayed - which is why didEndDisplayingCell is not called. This allows it to keep its text and still receive keyboard input. When the text field resigns first responder then didEndDisplayingCell is called.

Long standing bug rdar://43522696The workaround is to hide and unhide the nav bar: self.navigationController.navigationBarHidden = YES; self.navigationItem.prompt = @"New Prompt"; self.navigationController.navigationBarHidden = NO;

Lazy is for one-time initialization only. Since upon NSPersistentStoreCoordinatorStoresDidChangeNotification you need to re-initialize the NSFetchedResultsController you can't use lazy and must use something else.

Still an issue in newly released 13.4.My main problem is when a table is in split overlay mode (e.g. by default on iPhone X/XR/11) but hidden the rotation causes UITableView layoutSubviews which throws UITableViewAlertForLayoutOutsideViewHierarchy despite the table not being in the window.Apple please see FB7306484My current workaround involves subclassing UITableView with:#import "TableView.h" @implementation TableView - (void)layoutSubviews{ if(!self.window){ return; } [super layoutSubviews]; } @endBut there are still cases where the issue occurs.I'm thinking about just ignoring this and going back to letting the table view be updated when not in a window too.

Same problem here, my personal Apple ID my Mac and iOS devices are signed in with is different from my developer Apple ID. I tried to add my personal Apple ID as an admin to my developer account but it won't work because a long time ago, before we even had CloudKit, I created a developer account using my personal Apple ID.I just contacted Apple to request they delete my dummy developer account that uses my personal Apple ID then I will first attempt to add my personal Apple ID as an admin to my developer account. If that doesn't work then I may contact Apple to request if they can change my developer Apple ID to my personal one, I think I have tried that a long time ago and it wasn't possible but maybe it is now.If anyone has any other ideas I'd be really interested. It would be a real pain to have to log in and out of Apple IDs just to use CloudKit, especially when working with sync that involves multiple devices.

You shouldn't be editing the snapshot, instead edit the model. I.e. delete the managed Object as follows:- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath { if (editingStyle == UITableViewCellEditingStyleDelete) { NSManagedObjectContext *context = self.managedObjectContext; NSManagedObjectID *objectID = [self itemIdentifierForIndexPath:indexPath]; Event *event = [context objectWithID:objectID]; [context deleteObject:event]; NSError *error = nil; if (![context save:&error]) { // Replace this implementation with code to handle the error appropriately. // abort() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development. NSLog(@"Unresolved error %@, %@", error, error.userInfo); abort(); } } }After deleting the object the didChangeContentWith snapshot object will be called.Note: You need to add a managedObjectContext property to your UITableViewDiffableDataSource subclass.

The snapshot is only for sections and rows not for changes to the data being displayed in those rows. In your cell handler do not configure the cell instead just set the object on it and within a cell subclass observe NSManagedObjectContextObjectsDidChangeNotification notification and update the cell when necessary. Or you could just update all visible cells in the fetched results controller delegate method.Also I noticed another issue. Instead of controllerDidChangeContent you need to use the new delegate method didChangeContentWithSnapshot. That is called during the performFetch with the initial snapshot so there is no need to call applyFetchedDataToDataSource.

After you init self.dataSource to a UITableViewDiffableDataSource (which sets itself to the tableView.dataSource) set the tableView.dataSource back to self, i.e. the UITableViewController subclass. Now in your numberOfSectionsInTableView and numberOfRowsInSection methods forward those to self.dataSource and return its info (this is the composition pattern). Now your UITableViewController just implements its section titles as normal since it is the table's data source.I believe UITableViewDiffableDataSource should not be setting itself as the dataSource if one is already set but I guess they designed it to work in the least error prone way because with UITableViewController added to a storyboard its already set.If you do it this way then it makes sense why the class wasn't open in the early iOS 13 betas.

In the storyboard I selected the split view controller and set a run time user defined attribute of style number 2 (for 3 column mode). Then I disconnected the relation segues and instead set storyboard identifiers on them then in code I instantiated then using the identifiers and used the setViewController forColumnType method for each of the 3 columns. To show a new Secondary you can use the showDetail segue but there doesn’t appear a way to use a segue to the Supplementary column. For that use showColumm and it works both when collapsed and separated. It might also be a better idea to use that method for showing the Secondary. I’m hoping they add storyboard support in beta 2.

init is called on your Document when the + is tapped. When an existing document is opened init(fileWrapper: FileWrapper, contentType: UTType) is called. Remember in SwiftUI the body method is called multiple times to create all the structs but doesn't mean that anything will actually happen, for example if all the structs built are identical then the diff won't detect any changes thus nothing will change.

A warning about a mistake in mtsrodrigues's answer. It will recreate the persistent container every time the struct is recreated. Instead you are supposed to use @StateObject to prevent this.

I think shared record syncing might be next year's new feature.