[Feedback] It's unclear how use wake an iOS app when a multi-part file upload in a background session finishes

[ptwobrussell]

Page: /sdk/storage/transfer-utility/q/platform/ios

Feedback:

It's unclear how to accomplish the functionality described in https://docs.amplify.aws/sdk/storage/transfer-utility/q/platform/ios#background-transfers with Amplify.Storage.

Here's a link to my observations in Discord as I attempted to figure this out.

https://discord.com/channels/705853757799399426/707328996995760179/780961944743837696

I'm really confused about how to wake the iOS app when a multi-part file upload in a background session occurs with Amplify. Storage. I can't figure out how to do it, and I can't find any docs to it, so maybe it's just not possible? But that wouldn't really make sense because it's such a core use case and since the Amplify docs are so insistent about switching over to Amplify for all new app development, so I must be missing something?

[ptwobrussell]

Just to circle back on this, I have figured out the solution.

1 - In terms of the code itself, you'll just drop in something to this effect into your AppDelegate.swift file. What makes it a bit non-obvious is that you're importing AWSS3 directly and there are no references to Amplify.

import Foundation
import UIKit
import AWSS3
import os.log


// Needed to handle completion of background sessions for file uploads
// If you're working on a new project with SwiftUI and iOS13+ you'll have to go out of your way to wire up `AppDelegate` through
// the @UIApplicationDelegateAdaptor property wrapper
class AppDelegate: NSObject, UIApplicationDelegate {
       
    func application(_ application: UIApplication, handleEventsForBackgroundURLSession identifier: String, completionHandler: @escaping () -> Void) {
        os_log("handleEventsForBackgroundUrlSession: %{public}@", log: OSLog.fileupload, type: .debug, identifier)
        AWSS3TransferUtility.interceptApplication(application, handleEventsForBackgroundURLSession: identifier, completionHandler: completionHandler)
    }
    
}

2 - Here's the part that was really at the root of most of my troubles: in iOS 13+, it's possible that your iOS Settings can be inadvertently configured so that iOS never resumes/relaunches your app, which can be incredibly confusing and send you on lots of wild goose chases if you don't already know about this. See https://developer.apple.com/forums/thread/124265?answerId=388440022#388440022

This was a fairly painful and confusing debugging process to get to to the bottom of this. Given how common a use case it is to upload large files, I hope this is helpful to someone else.

[ptwobrussell]

Although the approach in my previous comment seems to work for the "wake a suspended iOS app that's still in memory" use case, I've since discovered that the value for identifier that's passed into application:handleEventsForBackgroundURLSession may not be the same value that the underlying AWSS3TransferUtility singleton that's used internal to Amplify.Storage is using.

If it's not the same identifier, the potential impact is that it might make it impossible to use Amplify.Storage for a robust implementation of multi-part file uploads use case on iOS because the "app was terminated by iOS" (not a force quit by the user) use case requires the underlying transfer utility to properly reconnect to the appropriate URLSession.

Since my last comment, I've taken an alternate path and am using AWSS3TransferUtility directly to better isolate the issue and have a bit more control because Amplify.Storage doesn't provide a public interface to get its AWSS3TransferUtility instance or configure it. Along the way, I've experienced this bug that would impact Amplify.Storage - aws-amplify/aws-sdk-ios#3173 - which might be impacting my ability to debug.

I'll report back once I know more.

[yusuftor]

@ptwobrussell Did you ever find out whether this was possible?

[palpatim]

@ptwobrussell

I've since discovered that the value for identifier that's passed into application:handleEventsForBackgroundURLSession may not be the same value that the underlying AWSS3TransferUtility singleton that's used internal to Amplify.Storage is using

We would expect the identifier to be based on the key used to register the AWSTransferUtility instance (specifically, a concatenation of a static prefix and the key value), or a default identifier if no key was provided. In what cases do you see that the identifier is different?

The comment about the background interception is very helpful though--we'll take that on as a doc enhancement for now, and as an Amplify Storage enhancement longer term.

[palpatim]

Amplify Storage doesn't currently support background transfers. The existing SDK docs are sufficient for the TransferUtility case.

We are tracking support for background operations in Amplify.Storage in aws-amplify/amplify-swift#1102