We are experiencing the same issue. Tired everything suggested in the thread (reordering test, deleting last screenshot, looking for grey boxes/broken pictures), but the "There are still screenshot uploads in progress." error persists. So it's not possible to submit for review. We reported the issue at: https://feedbackassistant.apple.com/feedback/7785455

The issue still persists for us until today. Our report in the feedback assistant has still the status "Open". It's a very unfortunate situation as "Submitting for review" has been impossible for days now cause of this error. Did anyone got the issue resolved so far?

As this issue remains still unsolved, I managed to work around this bug by these steps: 1) Delete all existing screenshots and previews using "Delete All" for each size/language Note: "Delete All" also has a bug. After executing "Delete All" leave the app page and reenter it. You will eventually see one or two screenshots still present, which you have then to delete manually 2) Use the latest fastlane 2.150.0.rc4 to upload the screenshots (fastlane deliver). Using fastlane makes sure you do not run into any UI bugs and also saves a lot of time (you can just upload all languages with one terminal command ).

We've released an update today and see the same issue. For Products that have an introductionary offer (free trial, reduced price for the first year), the introductionary offer is not granted to the user. Instead the user is charged immediately. This is a pretty serious issue.

Issue is not resolved for new subscriptions in our case. Subscriptions still appear without free trial (though they have) and users are charged immediately.

We have the same issue for one of our apps. Reported as FB7900811.

@dmitriy131 : You marked the question/answer as resolved. Is the issue resolved for your app(s)? In our case it's not resolved.

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?

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.

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!

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.

Filled FB10577529 for this issue.

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".

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

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.