I did discover that by adding css of "display:table;" to the HTML element the DOM inspector and javascript will return the correct page size for iOS (display:block) has no effect. The style is not needed on macOS and neither does it hurt.

A solution for macOS is discussed here that DOES work now (2021). It is the ONLY solution I know of that will print ALL on and offscreen content of a WKWebView. It currently is NOT working on iOS but I am working on that. See this stackoverflow post and the answer marked as correct: https://stackoverflow.com/questions/33319295/how-does-one-print-all-wkwebview-on-and-offscreen-content-osx-and-ios And here is the working code: https://gist.github.com/cribaudo/7e95c26c5d7e8ffe35741cbb3158fb62

Given the deafening silence, presumably this is a bug. Bug report filed here: https://feedbackassistant.apple.com/feedback/9057027

This issue started for me today (5/13/22) IMMEDIATELY after Mac Software Update installed Xcode Command Line Tools 13.4. After that ANY MacOS App running in Xcode under does an Exit(173) due to NOT finding any App Store Receipts. I get this message: “x” is damaged and can’t be opened. Delete “x” and download it again from the App Store. I am not sure why it installed 13.4 before Xcode 13.4 is released but that is what update automatically installed. I'm on MacOS 12.3.1 (M1) and running Xcode 13.3.1. I tried rolling back to the 13.3.1 Command line tools but that didn't fix anything. Only way I can run and develop my mac apps now is to comment out the Receipt check. Bug report filed - FB10017618

Same issue for me. Started immediately after Mac Software Update installed Command Line Tools 13.4. Still running Xcode 13.3.1 and tried rolling back to command tools for 13.3.1. Didn't help :( Apple!!! Dang it

Thanks for the suggested code, but look at the code posted. It crashes (or that is how it looks while trying to write a value it just read from UserDefaults. Look at the code, it reads some counts stored in NSUserDefaults then does some math all in that method and then crashes while updating and attempting to write the updated counts all of which are in variables local to that method. It is only reading and writing values obtained from userDefaults?

Ok, I will follow the angle you are suggesting. As for logging it, I have NEVER actually seen this crash on any device or in testing. I have only seen it via Crash Reports in Organizer. Whatever is going on never seems to happen on my devices or where I can catch it in Xcode.

I spent quite a while logging items, but here again, I have never actually seen this crash in Xcode or on any device or it would have been easier to find. I had a theory that perhaps the more controller or one of the tabs on it was not nilled out but could never prove it. The thing that is puzzling is that the documentation for applicationDidEnterBackground states that that is the place to do quick things like save state. And that is all this method is doing, it is saving the order of the users tabs and the last one selected so that it can remember it for next time. The symbolicated crash log indicates it crashes on the second to last line of saveAppData, the last call to setObject before the synchronize. Anyway darkPaw, thanks for your ideas. These are all good suggestions and they definitely got me thinking in probably the right direction. I don't know yet if they are the "RIGHT" answer but they are good suggestions.

But!! I did find this in the documentation for the tabBarController: In iOS 6 and later, if you assign a value to this view controller’s restorationIdentifier property, it preserves a reference to the view controller in the selected tab. At restore time, it uses the reference to select the tab with the same view controller. My code is older than iOS 6, to give you an idea how long that has been there :)- LOL and I missed the bit about state preservation. Probably I should just let it do it for me and not have my own code for that.

Full log now attached.

Full Log 2022-11-15_14-28-39.6056_-0600-7ef0b8eca13f1281b1b0f3186ff46f5a59e728d2.crash

***** THIS WAS THE REAL PROBLEM and SOLUTION ***** Moving stuff around helped me find a reliable way to produce the crash in Xcode and catch it in the debugger. Then I was able to consistently see way down in the crash report well after my code that each time it was mentioning an observer of NSUserDefaults. The class where all the above code was being used was registering itself as an observer of NSUserDefaults and also some Notifications. I was removing self as observer of NSNotifications but NOT NSUserDefaults. So after this class was released and attempted to persist values in NSUserDefaults that triggered a notification to it just as it was being release leading to -> CRASH!

The root cause of this was that a ViewController that was dismissed by the time the application went into the background was still registered as an Observer of NSUserDefaults and when the app saved state that class was called and -> CRASH!

Yup! I am suddenly seeing a lot of crash reports (over 100 in the last couple of days) and ALL from users on iOS 16.1. This is new and nothing in that part of the App changed. Crashing right after the CoreData is initialized and NSPersistentCloudKitContainer is ready. At that point the controller does a fetchRequest for items in the Table and Crash with some kind of memory error. In my case it is simply making a request for items sorted alphabetically?!

I filed a bug report on this with all the crash logs we are getting in Organizer (FB11875507). And then submitted a TSR for help with a work around. Apples response was that there is no work around and it is there issue. Seeing a lot less crash reports (but still some with the same issue) on iOS 16.2 and now also some from beta users on 16.3, but the numbers are way down and I have been telling customers to upgrade to latest iOS. It helps most.