I had this problem in two places.I used the suggestion in the console message to create a symbolic break on UITableViewAlertForCellForRowAtIndexPathAccessDuringUpdate and then clicked on the white bolded references in the (backtrace window, which was the breakpoint navigator before running the simulator). These took me right to the line in my code with the issue.I missed this 'click on the white bolded line in backtrace' previous attempts at debugging this and like this issue.In one case, in the viewForHeaderInSection func, I had some UI element based on the presence of a row for that section or not. I changed that to some other attribute not based on the related formed/forming cell.In the other case, I had similarly put a condition in the canEditRowAt that would test if the `tableView.cellForRow(at:)` was of a certain class. Unhappy form. Replaced it with a condition based on a non-UI element and issue... gone.Nowhere did I use visibleCells explicitly, but I did analyze a visible cell. The point: don't be so literal in interpreting a console message.

I scratched my head about this for a while too. The app bundle and display name found in Xcode and info.plist control what the app displays on the app screen. The App Store portal (now appstoreconnect.apple.com) under App Information > localizable information covers the name and subtitle important for store optimization.