Post not yet marked as solved
Did you ever solve this issue? In my testing the @available annotation for the AppShortCutsProvider is totally ignored. I have AppShortCuts appearing on IOS 16 that are only compatible with iOS 17 and also lead to crashes.
A simple use case is a backup application (e.g. for backing up to a NAS), where the user has the choice to only backup the personal library, only the shared library or both.
I filled a feedback (It's still open) for such an enhancement around iOS 16 beta times. It's however still relevant as such a feature (and therefore API extension) has also been requested by numerous of our users since the Shared Library was introduced in iOS 16.1.
Please have a look at: FB10577368
Post not yet marked as solved
Any news on this issue now that iOS 16.1 is released?
We had already some customers asking for "Importing into the Shared Library" and "Filtering between all photos, shared library and personal library".
Post not yet marked as solved
Filled FB10577529 for this issue.
Post not yet marked as solved
Thanks for the feedback. I just noticed that the same issue applies to the includehiddenassets of PHFetchOptions.: https://developer.apple.com/documentation/photokit/phfetchoptions/1624780-includehiddenassets?language=objc
In this case the documentation was not updated for iOS 16, yet the includehiddenassets property seems to be ignored, if the user has turned on to require authorisation for hidden assets.
Also it changes the behaviour of existing apps without a way to work around it.
Makes it sense to fill a feedback on this? If it's not feasible to provide authorisation within apps for access, at least a property to check if the user has enabled authorisation would be useful.
Post not yet marked as solved
Same issue here: Notarisation from command from command line not working at all
First complained about unable to find metadata.xml, on subsequent runs can't find the actual dmg to be notarised.
xcrun swinfo --version is 1.18.850
Would be amazing, if this could get fixed swiftly!
Did anyone receive any feedback on the missing API to check the network permission?
The design here seems inconsistent compared to how any other privacy permission (location, photos etc) works on iOS - all have APIs to check the status upfront. There are lots of use cases where this needs to be done upfront to display an appropriate warning and avoid customer confusion/complaints.
The network privacy permission is appreciated from a privacy perspective, but we need to be able to handle it in a way that the user experience is not worsened.
Post not yet marked as solved
We are seeing the same behavior on recent iOS versions. More details here: https://developer.apple.com/forums/thread/654355
I don't think that this is intended behavior as for a background task only two conditions should be possible by definition/documentation:
If the background work is done, you mark the task yourself as completed using:
func setTaskCompleted(success: Bool)
If the task is not marked for completion, the system will eventually kill the app according to the documentation.
2. In case that the background work takes longer than the system allows under current conditions, the task will run into the expiration handler set by
var expirationHandler: (() -> Void)? { get set }
If no expiration handler is set, the system will mark the task itself as completed according to the documentation.
This is also the behavior we saw at least up to iOS 13.3 or even iOS 13.4.
That a background tasks goes into suspended state itself makes no logical sense from my perspective.
@jpsoward Could you ever resolve the issue or do yo have more information on it?
@dmitriy131 : You marked the question/answer as resolved. Is the issue resolved for your app(s)? In our case it's not resolved.
We have the same issue for one of our apps. Reported as FB7900811.
Post not yet marked as solved
Issue is not resolved for new subscriptions in our case. Subscriptions still appear without free trial (though they have) and users are charged immediately.
