While sorting through this issue, I realized that if you have the System Preference "General -> Close Windows when quitting app" set "On" that the system removes the previously saved sessions and creates a new session when starting the app. Of course, this makes sense for a document based app (and probably many others). However, it is a change from the older state restoration mechanism where the information about the view controller hierarchy was available regardless of this System Preference. It is easy enough to have your own mechanism for saving state that can be used in the case that the previous session is removed for apps that it makes sense for.Hopefully that helps anyone that comes across this thread.Cheers,Greg

I've been encountering this same issue. I've got the situation where I have an older test user (from a different app) showing up automaically in the credentials and whe I enter a known valid test user for this app I get the "Your Apple ID or password is incorrect." message.That made me think that somehow the sign in was trying to reference this older app. To test this theory I created a new user on my Mac and built the app as that user. When I tried to run it, the sign in popup came up empty and when I entered the test user that I had been trying previously it worked correctly.When I went back to my normal accont on my Mac I still got the "Your Apple ID or password is incorrect." message with those same credentials.That makes me think that something is baked into my normal acount that is somehow directly the sign in to the wrong App Store Connect account. I image if I could find where this prefiled Apple ID is coming from I could correct the issue. Does anyone have any idea where this informaton is stored?Thanks,Greg

On the Mac you need to use the machine's mac address instead of the identifierForVendor as you do on iPhone/iPad. Take a look at: https://developer.apple.com/library/archive/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateLocally.html#//apple_ref/doc/uid/TP40010573-CH1-SW10You can use the "copy_mac_address()" code on this page to replace the identifierForVendor when building up the expectedHash in the macCatalyst case.

I enabled the restoration debugging keys:UserDefaults.standard.set(true, forKey: "UIStateRestorationDebugLogging") UserDefaults.standard.set(true, forKey: "UIStateRestorationDeveloperMode")Then I ran the app under both macCatalyst and iPadOS 13. The process was the same up to when +[_UICanvasUserActivityManager _knownSceneSessionMap] returned. Then the iPad app proceeded to call -[_UICanvasUserActivityManager initWithScene:] with the discovered identfier.However, in the macCatalyst case -[_UICanvasUserActivityManager initWithScene:] is not called but instead calls: +[_UICanvasUserActivityManager _updatePersistedSceneSession:]_block_invoke: Adding SceneSession for persistent identifierwith a completely different identifier to the one returned from _knownSceneSessionMap and ultimately calls -[_UICanvasUserActivityManager initWithScene:] with this new identifier. Prior to this point that identifer is not reported in the debug log.Hopefully that provides a clue for someone smarter than me :-)

I'm seeing the same issue. The UISceneDelegate based stateRestoration works correctly when run on iOS 13, but the same code run on macCatalyst behaves differently.I looked at the session.stateRestorationActivity in scene(_:willConnectTo:options:) and in the iOS 13 case the userActivity.userInfo contains the correct information. However in macCatalyst session.stateRestorationActivity is nil.On macCatalyst (but not iOS 13) the application(_:didDiscardSceneSessions:) is called shortly after the scene(_:willConnectTo:options:) is called and the set contain only one session and when I inspect the stateRestorationActivity it is the correct one that was saved in the previous run of the app.It is clear that the userActivity data is available to the new run of the app, but it is not being used for some reason. I've tried the Apple supplied sample code and I get the same behavior. It seems that some environmental condition is wrong, but I have no idea what it might be.As a side note, I've noticed that initial window sizing is not maintained if I have the "multiple windows" plist entry turned on but if I turn that off the initial window size is preserved (no effect on the stateRestorationActivity though).Hopefully someone has managed to get this to work and can shed some light on the subject.