Hi, thank you for your answer.
This seems to be exactly the issue.
As written in your post, I will try to contact the people that gave us the default mail client entitlement.
I hope they will be able to provide it also for ad-hoc distribution else we wont be able to use Xcode Cloud since it requires the 3 distribution modes to be working :(
immortal79
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
23 hours ago
User for
8 years
Post
Replies
Boosts
Views
Activity
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 ?