When onDisappear is called, it might try to cancel a non-existing task when the view body has been re-evaluated between onAppear and onDisappear. Storing the task in a @State fixes this issue.

As showcased in the following video, this fix should now behave like the iOS 15+ task { ... } modifier.

Turn the task generated by the SwiftUI task modifier into a State property, so that it's retained across view updates, and so that the correct task is cancelled if the view disappears before the task has been completed.

Use the withTaskCancellationHandler function to get access to a cancellation handler, within which we can then cancel the underlying URLSessionDataTask that's used to perform the actual network call.

While testing my unit tests (which were working fine on iOS 15) with the back ported version of URLSession.data(for:) from AsyncCompatibilityKit the cancelation test stopped working even though the package implements task cancellation.

So I was analyzing the issue and found, that task cancellations immediately following the task creation were not considered because the URLSessionDataTask was not yet created, therefore the dataTask was nil.

So I've implemented a shouldCancel flag which is set by the onCancel handler and considered before resuming the task.

I hope this is also useful to other library users.

Add download tasks

• Note, though, that unlike the data task, I made the method name distinct (using with rather than for/from).
• Should the data task also use unique names rather than counterfeiting the iOS 15 method names?
• This uses the actor pattern referenced in my other pull request.
• If you approve of this pull request, I'm happy to do an upload task rendition, too.

• The use of the onCancel closure is hiding the fact that the completion handler is @Sendable, whereas onCancel is not.
• If you define onCancel to be @Sendable, it reintroduces the compiler warning.
• I suspect that the closure pattern was used to eliminate the compiler warning, but I believe you are simply eliminating the warning, but not fixing the problem that the compiler was warning us about.
• Instead, use an actor to ensure thread-safe interaction with the URLSessionTask.

I'm trying to use this in a package that needs to be compatible with iOS 12, but simply integrating AsyncCompatibilityKit results in an error:

The fix: Add introduced: 13.0 to the @available statements: This way, consumers can import the package on iOS <13 (where it does nothing).

Thank you for this! I used this in a multiplatform test project. I needed to change a few things for macOS support.

• Change package platforms to support Catalina and above
• Add macOS availability annotation with deprecation for Monterey
• Adjust showView helper for running tests on macOS

I also noticed that some of the tests are flaky with Xcode 13.2 on 11.6.2. It can be reproduced easily with the repeated tests feature in Xcode.

Example:

let subject = PassthroughSubject<Int, Never>()

let valueTask = Task<[Int], Never> {
  var values = [Int]()

  for await value in subject.values {
    values.append(value)
  }

  return values
}

Task {
  subject.send(1)
  subject.send(2)
  subject.send(3)
  subject.send(completion: .finished)
}

let values = await valueTask.value
XCTAssertEqual(values, [1, 2, 3])

Mac (11.6.2) as test platform:

Test Suite 'AsyncCompatibilityKitTests.xctest' failed at 2021-12-22 15:37:33.281.
	 Executed 100 tests, with 20 failures (0 unexpected) in 5.906 (6.114) seconds

It seems that the Task that sends the values and the finish event to the subject might run before the valueTask and then only the completion is received resulting in an empty array. Adding a short Task.sleep before sending the values fixes this as a workaround. I'm still learning how the new swift concurrency works. But I'm not sure about any guarantees for the order of execution of the two Task { } blocks here. The PassthroughSubject will drop values, if there's no subscriber yet.

Testing repeatedly on iOS simulators with iOS 13.7 or 14.5 also fails.