Hi, thank you for your answer. I tested with an URL and this is indeed working well. I think this is a nice workaround but that means I will have to somehow encode my WidgetConfigurationIntent to the URL before sending it. While this is a nice workaround I would like to know what is the purpose of userActivity.widgetConfigurationIntent(). Is it broken ? I made a small sample here with two commits: First commit is using the WidgetConfigurationIntent, we can see it's working when the app is already running. Second commit is using the widgetURL we can see it's working well but it is also breaking the userActivity.widgetConfigurationIntent() https://github.com/PhilippeWeidmann/ContinueUserActivityWidget

Indeed in the example the properties are let so they cannot change at all. In my project it's a bit more complicated but the principle stays the same, properties are only passed once in the view constructor. Thank you for the linked article.

I can confirm that I'm still experiencing high CPU usage coming from the Spotlight process launched by the simulator. I'm on M1, Xcode 13 App Store release (13A233), macOS 11.6

Thank you for those answers they are very helpful 😊 We are working on a cloud base fileprovider app and we were expecting a lot (maybe too much) from this API. I will fill a bug report and in the meantime we will refactor our code to use default session whenever possible to upload / download files.

The hybrid way seems to be a decent approach. I tried using background NSURLSession in the foreground but it looks like the rate limiter is still somehow active. There is a thread - https://developer.apple.com/forums/thread/124450 about this bug and someone advises to use normal session when possible. As the thread is a year old, is it still a good solution ?