For an upcoming update to one of our apps, we are looking to download fairly large directories (as tar.gz) via silent content-available push notifications.It seems like this all works nicely:- The notification is delivered and a background download is initialised usingbackgroundSession.downloadTask(with: urlRequest)- The app delegate method is called once the download has finished to resume the tasksHowever, as soon as we create a replica download session in order to handle the tasks, the request fails with error:"Lost connection to background transfer service".The strange thing is, the completion handler (Internal closures, we are definitely using the delegate for download tasks) that is logging this error to our log file is on the original request controller which made the request, which IMHO, should have been removed from memory when the app entered the background?Is the reason that we're seeing this error, because we are trying to start a second URLSession with the same configuration identifier as the one that is somehow being kept alive with our app in the background? Or is it something else funky we're doing?The original request controller code can be seen here:https://github.com/3sidedcube/ThunderRequest/blob/f1d5e1a3026b095d48bf0ba97bb356a283c6422e/ThunderRequest/RequestController.swift#L633The class we use to handle the events for the background session can be found here:https://github.com/3sidedcube/ThunderRequest/blob/master/ThunderRequest/BackgroundSessionController.swiftAnd the calling code of these two can be found here:https://github.com/3sidedcube/ThunderCloud/blob/8efff2eb21b9062359824c91be39771acbf9f9c3/ThunderCloud/ContentController.swift#L802This is the line which logs our error:https://github.com/3sidedcube/ThunderCloud/blob/8efff2eb21b9062359824c91be39771acbf9f9c3/ThunderCloud/ContentController.swift#L968And this is the extract from our log file:2020-04-07T15:15:27Z [INFO] | com.threesidedcube.ThunderCloud (AppState) | applicationWillResignActive 2020-04-07T15:15:28Z [INFO] | com.threesidedcube.ThunderCloud (AppState) | applicationDidEnterBackground 2020-04-07T15:15:28Z [DEBUG] | com.threesidedcube.ThunderCloud (ContentController) | Scheduling background updates with minimum fetch interval 16238.858587878372 2020-04-07T15:16:17Z [DEBUG] | com.threesidedcube.ThunderCloud (ContentController) | Push notification received, checking if it's a `content-available` push: { "payload" : { "filename" : "https:\/\/s3.amazonaws.com\/dev.arc.cubeapis.com\/bundles\/1\/live\/1369324617_1586180214.tar.gz", "timestamp" : 1685827838 }, "aps" : { "content-available" : 1 } } 2020-04-07T15:16:17Z [DEBUG] | com.threesidedcube.ThunderCloud (ContentController) | content-available == 1 sending notification off to `ContentController` 2020-04-07T15:16:17Z [DEBUG] | com.threesidedcube.ThunderCloud (ContentController) | `appLaunched` called 2020-04-07T15:16:17Z [DEBUG] | com.threesidedcube.ThunderCloud (ContentController) | Checking for app upgrade 2020-04-07T15:16:17Z [DEBUG] | com.threesidedcube.ThunderCloud (ContentController) | Handling content-available notification 2020-04-07T15:16:17Z [DEBUG] | com.threesidedcube.ThunderCloud (ContentController) | Making sure notification bundle isn't after a landmark publish this app shouldn't receive 2020-04-07T15:16:17Z [DEBUG] | com.threesidedcube.ThunderCloud (ContentController) | No landmark timestamp provided in notification 2020-04-07T15:16:17Z [DEBUG] | com.threesidedcube.ThunderCloud (ContentController) | Checking notification timestamp against latest on-disk bundle version 2020-04-07T15:16:17Z [DEBUG] | com.threesidedcube.ThunderCloud (ContentController) | Downloading content-available bundle with timestamp: 1685827838.0 2020-04-07T15:16:17Z [DEBUG] | com.threesidedcube.ThunderCloud (ContentController) | Downloading bundle: https://s3.amazonaws.com/dev.arc.cubeapis.com/bundles/1/live/1369324617_1586180214.tar.gz Destination: file:///var/mobile/Containers/Data/Application/8030474F-6348-4956-984D-41098087C1FC/Library/Application%20Support/StormDeltaBundle/ 2020-04-07T15:16:56Z [DEBUG] | com.threesidedcube.ThunderCloud (ContentController) | Handling events for background url session: 3FF7CD8C-C83D-4285-912B-EAA538F05458-377-00000002B2877B71 2020-04-07T15:16:56Z [DEBUG] | com.threesidedcube.ThunderCloud (ContentController) | Starting background request controller 2020-04-07T15:16:57Z [WARN] | com.threesidedcube.ThunderCloud (ContentController) | Downloading bundle failed: Lost connection to background transfer service

We work for a company that builds and maintains apps for our clients and we had a few questions regarding the new account deletion policy that comes into fruition at the end of June 2022. We have tried to raise this directly with Apple but with no response as of yet. Do any of you know the answers to the following: Does providing the user with an email address to request that their account and data be deleted suffice in 'deleting' their account? We have a few apps that the data is managed by the client and not by us (the app developers), so it is more difficult to remove from our side. For example, we have a client that allow users to create accounts within the app, but the data is stored by them and used across multiple platforms (such as health records), so if we were to allow the user to delete this data entirely, it may cause issues on other platforms. We were wondering if it’s possible that these users send an email in app asking for their account to be removed and we just anonymise the data JUST for the app and continue to store their health record.  Do we need to offer the option of deleting the account if their account is technically created off app and they only have to enter a OTP to be able to access said account? In this example, the user still sees the option to 'Sign up' but they can't do so unless their phone number is already in the database.  Do we need to offer the option of deleting the account if their account is created using social logins (Apple/Google/Facebook etc)?  Do we need to offer the option of deleting the account if users are only able to sign in to the app? Aka, they do not create the account on the app, but elsewhere on a website?  Do we need to offer the option of deleting the account if it isn't technically made on the app, but in an embedded link that leads to the client's website?  Do we need to offer the option of deleting data if we don’t have an account for a user, but store identifiers so we can map users, but don’t retain any personal information about the user? Any help will be greatly appreciated, thank you.